Бэкэнд-приложение получает телеметрию только для набора сообщений azure IoTHub?

Question

Справочная информация. У меня есть внутреннее приложение, использующее телеметрические сообщения из маршрута «встроенные сообщения / события» на IoTHub. Телеметрия используется путем создания потребителя с помощью EventHubClient с использованием python SDK. Устройства предоставляются iothub программно и получают сертификаты x509 для аутентификации, даты создания / истечения срока действия действительны для сертификатов клиента и CA. В прошлом у меня было несколько устройств, отправляющих в IoThub одновременно и используемых бэкэнд-приложением. Через некоторое время мы настроили потоковую аналитику azure для прослушивания того же бэкэнда / маршрута, что и у существующего бэкэнд-приложения. Перемотка на пару месяцев, теперь мы можем получить только один идентификатор устройства для успешного использования клиентом-слушателем в исходном бэкэнд-приложении.

Симптом - у меня есть 2 устройства, устройство A и устройство B. Устройство устройства A Идентификатор - Боб, а CN на x509 - Боб. Идентификатор устройства устройства B - Sally, а CN в сертификате - Sally. Они оба были предоставлены через службу обеспечения устройств и подписаны одним и тем же центром сертификации, который загружен и проверен как в DPS, так и в iothub. Вся телеметрия, использующая учетные данные для Боба, используется как потоковой аналитикой, так и исходным внутренним приложением. Вся телеметрия, отправленная с использованием учетных данных для Салли, используется только потоковой аналитикой. Мы можем изменить идентификатор устройства и использовать учетные данные Bob на устройстве A или устройстве B, и сообщения потребляются обоими бэкэндами, и если мы используем идентификатор / учетные данные устройства Sally, они всегда обрабатываются только потоковой аналитикой. И потоковая аналитика, и исходное бэкэнд-приложение настроены на группу потребителей $ Default. Я полагаю, что раздел не имеет значения, если я не использую концентратор событий, но потоковая аналитика не имеет поля для идентификатора раздела, а потребитель внутреннего приложения использует раздел 0. Все сообщения доставляются во встроенную конечную точку событий / сообщений. и никакие сообщения не доставляются другим конечным точкам.

Вопрос: почему мое бэкэнд-приложение потребляет только сообщения с идентификатором устройства / учетными данными для Боба?

Я пытался предоставить всю необходимую информацию, но если что-то пропустил, просто дайте мне знать и я могу предоставить более подробную информацию.

правки: я уже пытался полностью отключить потоковую аналитику (и на всякий случай перезапустить бэкэнд-приложение), поэтому только бэкэнд-приложение потребляет сообщения от конечной точки, что не Помогите. Но поскольку после первого ответа я создал новую группу потребителей на конечной точке для потоковой аналитики и изменил группу потребителей для входных данных потоковой аналитики для этой новой группы потребителей. Никаких изменений в «симптомах».

Answer 1

Проблема связана с идентификатором раздела. Я использовал библиотеку azure .eventhub для получения событий из бэкэнда iothub. Эта библиотека была в капитальном ремонте в течение последних 10 месяцев или около того. Мы использовали предварительную версию (я думаю, 5.0.0b4), потому что она включала в себя множество полезных методов и весь пример кода для этого (EventHubClient.create_consumer) указанного раздела «0». Поскольку iothub определяет идентификатор раздела на основе идентификатора устройства, некоторые устройства были отправлены в раздел 1. Переключение идентификатора раздела в методе create_consumer показало проблему. Тогда мы могли видеть только всю телеметрию «Салли» в бэкэнд-приложении, но не «Боб». Поскольку потоковая аналитика не требует ввода идентификатора раздела, я предполагаю, что она использует все разделы, поэтому обрабатывала всю телеметрию.

Решение: сейчас я использую azure .eventhub 5.0.1. и метод EventHubConsumerClient.recieve () для получения сообщений. Кажется, что делает работу для всех разделов. Единственная потенциальная проблема заключается в том, что похоже, что он извлекает пакеты данных из разделов, а не читает концентратор в целом в режиме реального времени. Пока я не отправляю данные с достаточно высокой частотой, чтобы это было проблемой, но с очень высокой частотой выборки я считаю, что он будет читать фрагменты сообщений из каждого раздела, и если очередь будет достаточно большой, это задержит обработку сообщений из других разделов, пока он не заканчивает свою партию. Также требуется, чтобы вы использовали учетную запись хранения для определения местоположения контрольной точки, если вы используете платформу без состояний, например, экземпляр контейнера.

Answer 2

Все ваши нисходящие приложения, в вашем случае ваше исходное фоновое приложение и Azure Stream Analytics, должны использовать свою собственную группу потребителей , иначе они будут в конечном итоге потреблять ожидающие сообщения друг друга.