Мониторинг, диагностика и устранение неполадок подключения устройств к Центру Интернета вещей Azure

Иногда проблемы с подключением устройств Интернета вещей трудно устранить, так как существует множество возможных точек отказа. Логика приложения, физические сети, протоколы, оборудование, Центр Интернета и другие облачные службы вещей могут быть причиной проблем. Очень важно иметь возможность обнаруживать и выявлять источники проблем. Однако крупномасштабное решение Интернета вещей может включать тысячи устройств, поэтому проверка отдельных устройств вручную нецелесообразна. Центр Интернета вещей интегрируется с двумя службами Azure, которые помогают сделать следующее:

• Azure Monitor. Azure Monitor позволяет собирать, анализировать и обрабатывать данные телеметрии из Центра Интернета вещей. Чтобы помочь в обнаружении, диагностике и устранении этих проблем в большом масштабе, используйте возможности мониторинга Центра Интернета вещей с помощью Azure Monitor. Этот подход включает настройку оповещений для активации уведомлений и действий при отключении и настройке журналов, которые можно использовать для обнаружения условий, вызвавших отключение.

• Сетка событий Azure Для критической инфраструктуры и отключений каждого из устройств используйте службу Сетка событий Azure для подписки на события подключения и отключения устройств, формируемые Центром Интернета вещей. Сетка событий Azure позволяет использовать любые из следующих обработчиков событий:

  • Функции Azure
  • Логические приложения
  • Azure Automation
  • WebHooks
  • Хранилище очередей
  • Гибридные подключения
  • Event Hubs

Сетка событий и Azure Monitor

Сетка событий предоставляет решение для мониторинга каждого из устройств с низкой задержкой, которое можно использовать для отслеживания подключений критически важных устройств и инфраструктуры. Azure Monitor предоставляет метрику с именем Подключенные устройства, которые можно использовать для мониторинга количества устройств, подключенных к Центр Интернета вещей, и активировать оповещение, когда это число снижается ниже статического порогового значения.

При выборе того, следует ли использовать сетку событий или Azure Monitor для определенного сценария, учитывайте следующие проблемы:

• Задержка оповещения: события подключения к IoT Hub доставляются гораздо быстрее с помощью службы Сетка событий. Этот факт делает сетку событий лучшим выбором для сценариев, когда быстрое уведомление является желательным.

• Уведомления для каждого устройства. Сетка событий позволяет отслеживать подключения и отключать отдельные устройства. Этот факт делает сетку событий лучшим выбором для сценариев, где необходимо отслеживать подключения для критически важных устройств.

• Упрощенная настройка. Оповещения метрик Azure Monitor поддерживают упрощенную процедуру установки, которая не требует интеграции с другими службами для доставки уведомлений по электронной почте, SMS, Голосовой связи и доставки других видов уведомлений. С помощью службы Сетка событий необходимо интегрироваться с другими службами Azure для доставки уведомлений. Обе службы могут интегрироваться с другими службами для активации более сложных действий.

Сетка событий. Мониторинг событий подключения и отключения

Сетка событий обеспечивает более низкую задержку событий, чем Azure Monitor, и вы можете отслеживать их на каждом устройстве. По этим причинам Сетка событий является предпочтительным методом для мониторинга критически важных устройств и инфраструктуры.

Примечание.

Чтобы отслеживать события подключения и отключения устройств в рабочей среде, рекомендуется подписаться на DeviceConnected и DeviceDisconnected события в Сетке событий для активации предупреждений и мониторинга состояния подключения устройства.

При использовании службы Сетка событий для мониторинга или активации оповещений при отключении устройств убедитесь, что при такой реализации фильтруются периодические отключения, возникающие из-за возобновления токена SAS на устройствах, использующих пакеты SDK для Интернета вещей Azure. Дополнительные сведения см. в разделе Поведение при отключении устройств MQTT, использующих пакеты SDK для Интернета вещей Azure.

Дополнительные сведения о событиях подключения устройства с помощью Сетки событий см. в следующих статьях:

• Общие сведения об использовании Сетки событий с Центром Интернета вещей см. в статье Реагирование на события Центра Интернета вещей с помощью Сетки событий. Обратите особое внимание на ограничения для событий состояния подключения устройства.

• Руководство по упорядочиванию событий подключения устройств см. в статье Порядок событий подключения устройств из Центра Интернета вещей Azure с помощью Azure Cosmos DB.

• Руководство по отправке уведомлений по электронной почте см. в разделе Отправка уведомлений по электронной почте о событиях Центра Интернета вещей Azure с помощью Сетки событий и приложения Logic Apps в документации по службе Сетка событий.

Azure Monitor. Использование журналов для разрешения ошибок подключения

При обнаружении отсоединения устройств с помощью оповещений о метриках Azure Monitor или Сетки событий можно использовать журналы для упрощения устранения причины. В этом разделе описано, как найти распространенные проблемы в журналах Azure Monitor. В этих шагах предполагается, что вы уже создали настройку диагностики, чтобы отправлять журналы подключений IoT Hub в рабочую область Log Analytics.

После создания параметра диагностики для маршрутизации журналов ресурсов IoT Hub в журналы Azure Monitor выполните следующие действия, чтобы просмотреть журналы в портале Azure.

1. Перейдите в Центр Интернета вещей на портале Azure.

2. В разделе Наблюдение на левой панели Центра Интернета вещей выберите Журналы.

3. Чтобы выделить журналы ошибок подключения для Центра Интернета вещей, введите следующий запрос в редакторе запросов, а затем выберите Запустить:

   AzureDiagnostics
   | where ( ResourceType == "IOTHUBS" and Category == "Connections" and Level == "Error")
   

4. В результатах (если они будут) найдите OperationName, ResultType (код ошибки) и ResultDescription (сообщение об ошибке), чтобы получить более подробную информацию.

   

Сведения об устранении наиболее распространенных ошибок см. в следующих руководствах:

• 400027 СоединениеПринудительноЗакрытоНаНовомСоединении

• 404104 ПодключениеУстройстваЗакрытоУдаленно

• 401003 IoTHubНеавторизован

• 409002 LinkCreationConflict

• 500001 ServerError

• 500008 GenericTimeout

Azure Monitor. Использование журналов для наблюдения за подключением к конкретному устройству

Могут возникнуть ситуации, когда вы хотите использовать Azure Monitor для просмотра ошибок подключения и сведений для конкретного устройства. Чтобы изолировать события подключения для устройства, можно выполнить те же действия, что и в предыдущем разделе, но ввести следующий запрос. Замените test-device на имя устройства.

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.DEVICES" and ResourceType == "IOTHUBS"
| where Category == "Connections"
| extend DeviceId = tostring(parse_json(properties_s).deviceId)
| where DeviceId == "test-device"

Запрос возвращает как события об ошибках, так и информационные события для целевого устройства. В следующем примере выходных данных показано информационное событие deviceConnect:

Поведение отключения устройств MQTT в SDK Azure IoT

Пакеты SDK для устройств Интернета вещей Azure отключаются от Центра Интернета вещей, а затем повторно подключаются при обновлении токенов SAS по протоколу MQTT (и MQTT через WebSockets). В журналах это отображается как события информационного отключения и подключения устройства, которые иногда сопровождаются событиями ошибок.

По умолчанию срок действия маркера составляет 60 минут для всех пакетов SDK; однако разработчики могут изменить его в некоторых пакетах SDK. В следующей таблице приведены сведения о сроках существования токена, о продлении токена и о поведении при возобновлении токена для каждого из пакетов SDK.

SDK	Срок существования токена	Продление токена	Поведение при возобновлении
.NET	60 минут, настраивается	85 % срока службы, настраиваемый	Пакет SDK отключается и повторно подключается в течение срока действия токена плюс 10-минутный льготный период. Информационные события и ошибки, созданные в журналах.
Java	60 минут, настраивается	85 % срока существования, не настраивается	Пакет SDK отключается и повторно подключается в течение срока действия токена плюс 10-минутный льготный период. Информационные события и ошибки, созданные в журналах.
Node.js	60 минут, настраивается	настраиваемый	Пакет SDK отключается и повторно подключается при обновлении токена. В журналах создаются только информационные события.
Python	60 минут, настраивается	120 секунд до истечения срока действия	Пакет SDK отключается и повторно подключается в течение срока существования токена.

На следующих снимках экрана показано поведение обновления токена в журналах Azure Monitor для разных пакетов SDK. Срок существования токена и порога его обновления были изменены с настроек по умолчанию, как указано.

• SDK .NET с токеном со сроком действия 1200 секунд (20 минут) и продлением на уровне 90 % от срока действия. отключение происходит каждые 30 минут:

  

• Пакет Java SDK с временным интервалом действия токена 300 секунд (5 минут) и обновлением срока действия по умолчанию на 85 %. отключение происходит каждые 15 минут:

  

• Пакет Node SDK со сроком действия токена 300 секунд (5 минут), и обновление токена должно происходить через 3 минуты. Происходит отключение при обновлении токена. Кроме того, нет ошибок. Выдаются только информационные события подключения и отключения.

  

Для накопления результатов использовался следующий запрос. Запрос извлекает имя и версию пакета SDK из контейнера свойств. Дополнительные сведения см. в разделе Версия пакета SDK в журналах Центра Интернета вещей.

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.DEVICES" and ResourceType == "IOTHUBS"
| where Category == "Connections"
| extend parsed_json = parse_json(properties_s)
| extend SDKVersion = tostring(parsed_json.sdkVersion) , DeviceId = tostring(parsed_json.deviceId) , Protocol =  tostring(parsed_json.protocol)
| distinct TimeGenerated, OperationName, Level, ResultType, ResultDescription, DeviceId, Protocol, SDKVersion

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

Если вы отслеживаете подключения устройств с помощью Центров событий, убедитесь, что вы настроили систему таким образом, чтобы отфильтровывать периодические отключения из-за возобновления действия маркера SAS. Например, не запускайте действия на основе отключений, пока за событием отключения следует событие подключения в течение определенного периода времени.

Примечание.

Центр Интернета вещей поддерживает только одно активное подключение MQTT на устройство. Любое новое подключение MQTT от имени того же идентификатора устройства приводит к тому, что Центр Интернета вещей разрывает существующее подключение.

В журнал IoT-хаба будет записано 400027 ConnectionForcefullyClosedOnNewConnection

Предложенные шаги не помогли устранить проблему

Если предыдущие действия не помогли, попробуйте следующее.

• Если у вас есть доступ к проблемным устройствам физически или удаленно (например, через SSH), выполните инструкции в руководстве по устранению неполадок на стороне устройства, чтобы устранить неполадки.

• Убедитесь, что ваши устройства включены в портале Azure в разделе > ваш Центр IoT > Устройства IoT.

• Если устройство использует протокол MQTT, убедитесь, что порт 8883 открыт. Дополнительные сведения см. в разделе Подключение к Центру Интернета вещей (MQTT).

• Получите помощь на странице Майкрософт с вопросами и ответами о Центре Интернета вещей, в Stack Overflow или в службе поддержки Azure.

Следующие шаги

• Дополнительные сведения об устранении временных проблем см. в статье Обработка временных сбоев.

• Дополнительные сведения о пакетах SDK для устройств Интернета вещей Azure и управлении повторными попытками см. в разделе Шаблоны повторных попыток.