Диагностическое дерево для IoT Edge-модуля, который прекращает работу: reported state, exit code, edgeAgent, restartPolicy, зависимости и безопасный support bundle без утечки данных.
Зафиксируйте lifecycle до перезапуска
Снимите iotedge list, reported properties edgeAgent, runtime status, start time, last exit time, restart count и exit code до ручного restart. Сопоставьте их с UTC-временем, когда поток данных прекратился. Слово stopped не говорит, завершилось ли приложение с кодом 0, было убито по памяти, заменено deployment или потеряло зависимость. Не перезагружайте хост первым действием: это меняет контейнеры, обрывает журналы и лишает вас исходного состояния, хотя временно может вернуть поток.
Читайте edgeAgent и журнал модуля вместе
Журнал пользовательского контейнера показывает ошибку приложения, а edgeAgent — решения о создании, остановке, повторном запуске и применении desired properties. Возьмите одинаковое окно времени и сравните последнюю строку приложения с последующим действием agent. Затем проверьте edgeHub только если модуль зависит от сообщений или соединения. Не включайте debug на длительный срок: подробные журналы быстро растут и могут содержать payload, host names и идентификаторы устройств.
Проверьте restartPolicy и deployment source
В deployment manifest свойства status и restartPolicy определяют, должен ли edgeAgent запускать модуль и что делать после его остановки. Кроме того, automatic deployment может перезаписать ручной набор модулей. Сравните effective desired properties с ожидаемым manifest, приоритеты deployment и время последнего изменения. Политика always способна вернуть контейнер после сбоя, но не устраняет утечку памяти или неверный exit; policy never может сделать штатное завершение похожим на отказ.
Проведите один обратимый эксперимент
После сохранения журналов перезапустите только проблемный модуль и наблюдайте тот же интервал нагрузки. Если причина связана с EdgeHub или сертификатом, проверьте порядок запуска и встроенную retry-логику клиента; если контейнер снова завершается, сравните exit code и ресурсы хоста. Не выполняйте docker system prune и не удаляйте volumes в ходе диагностики: официальная документация относит это к последнему средству и предупреждает о потере данных и очереди без host storage.
Соберите bundle и очистите идентификаторы
iotedge support-bundle объединяет module logs, security manager, container engine и iotedge check, поэтому перед передачей изучите архив. Удалите сообщения приложения, device names, module names, адреса registry и токены; сохраните версии, временные метки, exit code, restart count и ошибки. Укажите deployment type, restartPolicy и результат одиночного restart. Критерий остановки — повторяемый exit либо противоречие desired и reported state. После этого prune и широкая пересборка уменьшают доказательность.
Материал подготовлен самостоятельно с автоматизацией и редакционно проверен 29 июля 2026 года по обезличенному сигналу Microsoft Q&A и официальной документации Azure IoT Edge; device ID, маршруты и сообщения не использовались.
Источники и проверка
- Microsoft Learn — диагностика Azure IoT Edge проверено 2026-07-29
- Microsoft Learn — композиция модулей IoT Edge проверено 2026-07-29
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.