Какой ключ секции используется параметрами диагностики Azure при отправке данных в концентратор событий?
Какой ключ секции используется при публикации сообщений в концентраторе событий при настройке параметров диагностики для ресурса в Azure и настройке этого параметра диагностики для концентратора событий? Или не используется ключ раздела (что приводит к циклическому распределению по разделам)? Я просмотрел документацию Microsoft и не смог найти ответ на этот вопрос.
Конкретный вариант использования, который у нас есть, — это ресурс Application Insights, который имеет диагностический параметр, настроенный для отправки данных в концентратор событий. Затем у нас есть задание потоковой аналитики Azure, использующее этот концентратор событий. Мы пытаемся понять, как данные будут секционироваться в этом концентраторе событий, чтобы мы могли правильно настроить ключ секции для входных данных задания потоковой аналитики.
Вопрос включает в себя конкретный вариант использования сведений о приложениях -> параметры диагностики -> концентратор событий -> аналитика потока Azure. Есть ли конкретная информация, которую, как вы думаете, я могу добавить?
Ключ секции не используется для секционирования данных в концентраторе событий, но его можно использовать для группировки связанных событий в одну секцию. Вы можете указать ключ секции в входной конфигурации задания Stream Analytics.
Концентратор событий имеет несколько разделов в качестве конфигурации. Когда какие-либо данные отправляются в концентратор событий (включая параметры диагностики), существует определенное определение того, в какую секцию эти данные направляются (даже если это циклический процесс, поскольку ключ секции не предоставляется). Я пытаюсь понять, существует ли вообще ключ раздела (избавил бы меня от возможного повторного разделения данных в ASA), и если да, то что это такое? Если нет ключа раздела, это тоже нормально, я просто хотел бы знать. Я также обновил свой исходный пост, чтобы обозначить, что я понимаю, что ключ раздела не является вариантом.
Ответы 2
Параметры диагностики (Azure Monitor) не будут задавать для событий какой-либо ключ раздела, поэтому события будут балансировать нагрузку в циклическом режиме во всех разделах концентратора событий. Вы должны сделать то же самое со стороны Stream Analytics и извлечь данные из всех разделов.
Я согласен с @Jdresc, вы должны сделать это со стороны Stream Analytics.
Перейдите по этой ссылке SO, чтобы получить дополнительную информацию о ключе раздела.
При настройке диагностического параметра для ресурса в Azure и настройке этого диагностического параметра для концентратора событий ключ секции, используемый при публикации сообщений в концентраторе событий, получается из идентификатора ресурса диагностического параметра.
См. этот документ Github. Согласно этому документу,
Класс Event Data имеет свойство Partition Key, которое позволяет отправитель, чтобы указать значение, которое хэшируется для создания раздела назначение. Использование ключа раздела гарантирует, что все события с один и тот же ключ отправляется в один и тот же раздел в концентраторе событий. Общий Ключи разделов включают идентификаторы сеансов пользователей и уникальные идентификаторы отправителей.
- Если вы не укажете значение для ключа раздела, отправленные события распределяются по разделам с использованием модели циклического перебора.
- Спасибо @Jdresc за то, что ведете в правильном направлении. По его словам, сделайте это со стороны потоковой аналитики, поскольку ключ раздела не будет установлен диагностическими настройками для событий. Поэтому вам следует настроить ключ секции для задания Stream Analytics.
Просто интересно, откуда у вас такая информация? это не кажется точным, поскольку, если бы ключ раздела был именем ресурса, это привело бы к тому, что все события попадали бы в один раздел из-за алгоритма назначения раздела концентратора событий. Я только что протестировал несколько ресурсов, отправляющих диагностику в концентратор событий, и раздел всегда пуст, если вы можете предоставить документ, из которого вы нашли эти утверждения, это было бы здорово.
было бы здорово, если бы вы предоставили более подробную информацию, например, о своей настройке и подходе. Тогда отвечать могут только участники сообщества.