Устранение неполадок устройства IoT Edge

Статья
08/25/2022

Область применения: IoT Edge 1.1

Важно!

IoT Edge 1.1 дата окончания поддержки — 13 декабря 2022 г. Чтобы получить сведения о поддержке определенного продукта, службы, технологии или API, перейдите на страницу Политика жизненного цикла поддержки Майкрософт. Дополнительные сведения об обновлении до последней версии IoT Edge см. в разделе Обновление IoT Edge.

Если при запуске Azure IoT Edge в вашей среде возникают проблемы, используйте эту статью как руководство для устранения неполадок и диагностики.

Выполните команду Check

Первым шагом при устранении неполадок в IoT Edge должно быть использование команды check, которая запускает набор тестов конфигурации и подключения для решения распространенных проблем. Команда check доступна в выпуске 1.0.7 и новее.

Примечание

Средство устранения неполадок не может выполнить проверку подключения, если устройство IoT Edge находится за прокси-сервером.

Вы можете выполнить команду check, как показано ниже, или включить флаг --help, чтобы просмотреть полный список параметров:

В Linux

sudo iotedge check

Windows:

iotedge check

Средство устранения неполадок выполняет разные проверки, отсортированные по следующим трем категориям:

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

Средство проверки IoT Edge использует контейнер для выполнения диагностики. Образ контейнера mcr.microsoft.com/azureiotedge-diagnostics:latest доступен в Microsoft Container Registry. Если необходимо выполнить проверку на устройстве без прямого доступа к Интернету, устройствам потребуется доступ к образу контейнера.

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

Сбор отладочной информации с помощью команды support-bundle

Если необходимо собрать журналы из устройства IoT Edge, удобнее всего использовать команду support-bundle. По умолчанию эта команда собирает журналы модуля, диспетчера безопасности IoT Edge и подсистемы контейнеров, выходные данные JSON iotedge check и другие полезные сведения об отладке. Она сжимает их в единый файл для облегчения совместного использования. Команда support-bundle доступна в выпуске 1.0.9 и новее.

Выполните команду support-bundle с флагом --since, чтобы указать, за какой период требуется собрать журналы данных. Например, 6h позволяет собрать журналы за последние шесть часов, 6d – за последние шесть дней, 6m – за последние шесть минут и т. д. Включите флаг --help, чтобы просмотреть полный список параметров.

В Linux

sudo iotedge support-bundle --since 6h

Windows:

iotedge support-bundle --since 6h

По умолчанию команда support-bundle создает ZIP-файл с именем support_bundle.zip в каталоге, в котором вызвана команда. Используйте флаг --output, чтобы указать другой путь или имя файла для выходных данных.

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

iotedge support-bundle --help

Вы также можете использовать встроенный вызов прямого метода UploadSupportBundle, чтобы передать выходные данные команды support-bundle в хранилище BLOB-объектов Azure.

Предупреждение

Выходные данные команды support-bundle могут содержать имена узлов, устройств и модулей, сведения, регистрируемые модулями и т. д. Имейте это в виду при совместном использовании выходных данных на общедоступном форуме.

Проверка метрик, собранных в среде выполнения

Модули среды выполнения IoT Edge создают метрики, помогающие отслеживать и анализировать работоспособность устройств IoT Edge. Добавьте модуль metrics-collector в развертывания, чтобы собрать метрики и отправить их в облако для упрощения мониторинга.

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

Проверьте версию IoT Edge

Если вы используете более раннюю версию IoT Edge, то проблему может устранить обновление. Средство iotedge check проверяет, установлена ли последняя версия управляющей программы безопасности IoT Edge, но не проверяет версии центра IoT Edge и модулей агента. Чтобы проверить версию модулей среды выполнения на устройстве, выполните команды iotedge logs edgeAgent и iotedge logs edgeHub. При запуске модуля в журналах объявляется номер версии.

Инструкции по обновлению устройства см. в статье Обновление управляющей программы безопасности IOT Edge и среды выполнения.

Проверка установки IoT Edge на устройствах

Вы можете проверить установку IoT Edge на устройствах, выполнив мониторинг двойника модуля edgeAgent.

Чтобы получить последнюю версию двойника модуля edgeAgent, выполните следующую команду из Azure Cloud Shell:

az iot hub module-twin show --device-id <edge_device_id> --module-id '$edgeAgent' --hub-name <iot_hub_name>

Эта команда выводит все сообщаемые свойства edgeAgent. Ниже приведены некоторые полезные свойства для мониторинга состояния устройства:

состояние среды выполнения
время запуска среды выполнения
время последнего выхода из среды выполнения
счетчик перезапусков среды выполнения

Проверьте состояние диспетчера безопасности IoT Edge и его журналы

Диспетчер безопасности IoT Edge отвечает за такие операции, как инициализация системы IoT Edge при запуске и подготовке устройств. Если IoT Edge не запускается, полезную информацию можно найти в журналах диспетчера безопасности.

В Linux

Просмотрите состояние диспетчера безопасности IoT Edge:
```
sudo systemctl status iotedge
```
Просмотрите журналы диспетчера безопасности IoT Edge:
```
sudo journalctl -u iotedge -f
```
Просмотрите более подробные сведения журналов диспетчера безопасности IoT Edge:
1. Измените параметры управляющей программы IoT Edge:
```
sudo systemctl edit iotedge.service
```
2. Обновите следующие строки:
```
[Service]
Environment=IOTEDGE_LOG=debug
```
3. Перезапустите управляющую программу безопасности IoT Edge:
```
sudo systemctl cat iotedge.service
sudo systemctl daemon-reload
sudo systemctl restart iotedge
```

Windows:

Просмотрите состояние диспетчера безопасности IoT Edge:
```
Get-Service iotedge
```
Просмотрите журналы диспетчера безопасности IoT Edge:
```
. {Invoke-WebRequest -useb aka.ms/iotedge-win} | Invoke-Expression; Get-IoTEdgeLog
```
Просмотрите журналы диспетчера безопасности IoT Edge за последние 5 минут:
```
. {Invoke-WebRequest -useb aka.ms/iotedge-win} | Invoke-Expression; Get-IoTEdgeLog -StartTime ([datetime]::Now.AddMinutes(-5))
```
Просмотрите более подробные сведения журналов диспетчера безопасности IoT Edge:
1. Добавьте переменную среды системного уровня:
```
[Environment]::SetEnvironmentVariable("IOTEDGE_LOG", "debug", [EnvironmentVariableTarget]::Machine)
```
2. Перезапустите управляющую программу безопасности IoT Edge:
```
Restart-Service iotedge
```

Проверка журналов контейнеров на наличие ошибок

После запуска управляющей программы безопасности IoT Edge проверьте журналы контейнеров на наличие ошибок. Начните с развернутых контейнеров, а затем просмотрите контейнеры, которые составляют среду выполнения edgeAgent и edgeHub. В журналах агента IoT Edge обычно содержатся сведения о жизненном цикле каждого контейнера. В журналах центра IoT Edge содержатся сведения об обмене сообщениями и маршрутизации.

Журналы контейнеров можно получить из нескольких мест:

На устройстве IoT Edge выполните следующую команду, чтобы просмотреть журналы:
```
iotedge logs <container name>
```
На портал Azure используйте встроенное средство устранения неполадок. Мониторинг и устранение неполадок устройств IoT Edge на портале Azure
Используйте прямой метод UploadModuleLogs для отправки журналов модуля в Хранилище BLOB-объектов Azure.

Очистка журналов контейнеров

По умолчанию подсистема контейнеров Moby не устанавливает ограничения размера журнала контейнера. Со временем это может привести к заполнению устройства журналами и исчерпанию дискового пространства. Если большие журналы контейнеров влияют на производительность устройства IoT Edge, используйте следующую команду, чтобы принудительно удалить контейнер вместе с журналами.

Если вы еще не закончили устранение неполадок, перед выполнением этой операции завершите проверку журналов в контейнере.

Предупреждение

Если принудительно удалить контейнер edgeHub при наличии недоставленных сообщений и если хранилище узлов не настроено, недоставленные сообщения будут потеряны.

docker rm --force <container name>

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

Просмотр сообщений, отправляемых через центр IoT Edge

Вы можете просматривать сообщения, отправляемые через центр IoT Edge, и собирать данные аналитики из подробных журналов контейнеров в среде выполнения. Чтобы включить ведение подробных журналов в этих контейнерах, задайте значение RuntimeLogLevel в файле конфигурации YAML. Чтобы открыть этот файл, выполните следующее.

В Linux

sudo nano /etc/iotedge/config.yaml

Windows:

notepad C:\ProgramData\iotedge\config.yaml

По умолчанию элемент agent будет выглядеть, как показано в примере ниже:

agent:
  name: edgeAgent
  type: docker
  env: {}
  config:
    image: mcr.microsoft.com/azureiotedge-agent:1.1
    auth: {}

Вместо env: {} вставьте следующий фрагмент:

env:
  RuntimeLogLevel: debug

Предупреждение

YAML-файлы не могут содержать отступы в виде табуляции. Вместо этого используйте двойные пробелы. Перед элементами верхнего уровня не допускаются начальные пробелы.

Сохраните файл и перезапустите диспетчер безопасности IoT Edge.

Можно также проверить сообщения, передаваемые между центром Интернета вещей и устройствами IoT. Просмотрите эти сообщения с помощью расширения Центр Интернета вещей Azure для Visual Studio Code . Дополнительные сведения см. в записи блога об удобном средстве при разработке с помощью Центра Интернета вещей Azure.

Перезапуск контейнеров

После изучения журналов и сообщений можно попытаться перезапустить контейнеры.

На устройстве IoT Edge используйте следующие команды для перезапуска модулей:

iotedge restart <container name>

Перезапустите контейнеры среды выполнения IoT Edge:

iotedge restart edgeAgent && iotedge restart edgeHub

Также можно перезапустить модули удаленно на портале Azure. Дополнительные сведения см. в статье Мониторинг и устранение неполадок устройств IoT Edge на портале Azure.

Проверьте правила конфигурации брандмауэра и портов

Azure IoT Edge обеспечивает связь локального сервера с облаком Azure с помощью поддерживаемых протоколов Центра Интернета вещей. Дополнительные сведения см. в статье Выбор протокола связи. В целях дополнительной безопасности коммуникационные каналы между Azure IoT Edge и Центром Интернета вещей всегда настроены как исходящие. Эта конфигурация основана на модели связи с поддержкой служб, которая позволяет снизить контактную зону, изучаемую вредоносным объектом. Входящий обмен данными требуется только для определенных сценариев, в которых Центр Интернета вещей Azure необходимо отправлять сообщения на устройство Azure IoT Edge. Сообщения из облака на устройство защищаются с помощью безопасных каналов TLS и могут иметь дополнительную защиту при использовании сертификатов X.509 и модулей устройства TPM. Сведения об установке этой связи с помощью диспетчера безопасности Azure IoT Edge см. в этой статье.

Хотя IoT Edge предоставляет улучшенную конфигурацию для обеспечения безопасности среды выполнения IoT Edge и развернутых модулей, при этом многое по-прежнему зависит от базовой конфигурации компьютера и сети. Поэтому крайне важно убедиться, что для безопасного взаимодействия Edge с облаком настроены соответствующие сетевые правила и правила брандмауэра. Приведенную ниже таблицу можно использовать при настройке правил брандмауэра для основных серверов, на которых размещена среда выполнения Azure IoT Edge:

Протокол	Порт	Входящий	Исходящий	Действие
MQTT	8883	ЗАБЛОКИРОВАННЫЕ (по умолчанию)	ЗАБЛОКИРОВАННЫЕ (по умолчанию)	Исходящие подключения должны быть открыты при использовании MQTT в качестве протокола связи. IoT Edge не поддерживает порт 1883 для MQTT. Входящие подключения должны быть заблокированы.
AMQP	5671	ЗАБЛОКИРОВАННЫЕ (по умолчанию)	ОТКРЫТЫЕ (по умолчанию)	Протокол связи по умолчанию для IoT Edge. Должен быть открыт, если Azure IoT Edge не настроен для других поддерживаемых протоколов или если AMQP является требуемым протоколом связи. IoT Edge не поддерживает порт 5672 для AMQP. Заблокируйте этот порт, если Azure IoT Edge использует другой протокол, поддерживаемый Центром Интернета вещей. Входящие подключения должны быть заблокированы.
HTTPS	443	ЗАБЛОКИРОВАННЫЕ (по умолчанию)	ОТКРЫТЫЕ (по умолчанию)	Исходящие подключения должны быть открыты на порту 443 для подготовки IoT Edge. Эта конфигурация необходима при использовании созданных вручную сценариев или Службы подготовки устройств к добавлению в Центр Интернета вещей Azure. Входящее (входящее) подключение должно быть открыто только для определенных сценариев: Если у вас есть прозрачный шлюз с подчиненными устройствами, которые могут отправлять запросы методов. В этом случае порт 443 не должен быть открыт во внешних сетях для подключения к Центру Интернета вещей или предоставления служб Центра Интернета вещей через Azure IoT Edge. Таким образом, правило для входящего трафика может разрешать открытие только входящего подключения из внутренней сети. Для сценариев передачи данных из облака на устройство (C2D). IoT Edge не поддерживает порт 80 для HTTP. Если на предприятии невозможно настроить протоколы, отличные от HTTP (например, AMQP или MQTT), сообщения могут отправляться через протоколы WebSocket. В этом случае для подключения по WebSocket будет использоваться порт 443.

Последнее средство: остановка и повторное создание всех контейнеров

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

Следующая команда останавливает IoT Edge системе (и, следовательно, всех контейнерах). Для удаления всех контейнеров и томов используются параметры docker prune "all" и "volume". Просмотрите предупреждение о том, что команда выдает ошибку, и подтвердите с y помощью, когда все будет готово.

sudo iotedge system stop
docker system prune --all --volumes

WARNING! This will remove:
  - all stopped containers
  - all networks not used by at least one container
  - all volumes not used by at least one container
  - all images without at least one container associated to them
  - all build cache

Are you sure you want to continue? [y/N]

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

sudo iotedge config apply

Подождите несколько минут и повторите попытку.

sudo iotedge list

Дальнейшие действия

Считаете, что обнаружили ошибку в платформе IoT Edge? Отправьте запрос, чтобы мы как можно скорее устранили неисправность.

Если у вас есть другие вопросы, создайте запрос в службу поддержки для получения справки.

Устранение неполадок устройства IoT Edge

Выполните команду Check

Сбор отладочной информации с помощью команды support-bundle

Проверка метрик, собранных в среде выполнения

Проверьте версию IoT Edge

Проверка установки IoT Edge на устройствах

Проверьте состояние диспетчера безопасности IoT Edge и его журналы

Проверка журналов контейнеров на наличие ошибок

Очистка журналов контейнеров

Просмотр сообщений, отправляемых через центр IoT Edge

Перезапуск контейнеров

Проверьте правила конфигурации брандмауэра и портов

Последнее средство: остановка и повторное создание всех контейнеров

Дальнейшие действия

Дополнительные ресурсы