Анализ логов Node-RED и системных логов Linux

Урок 3 · Датчики и входы: нормализация сигналов · 30 мин · theory

Введение в логирование на контроллерах HI

Логирование (или журналирование) — это процесс систематической записи информации о событиях, происходящих в системе. Для инженера-инсталлятора логи являются основным инструментом для решения широкого круга задач на всех этапах жизненного цикла объекта: от первоначальной пусконаладки и отладки сценариев автоматизации до диагностики нештатных ситуаций во время эксплуатации и подготовки отчетности при сдаче объекта заказчику. Без умения читать и анализировать логи, диагностика превращается в поиск "наугад", что недопустимо в профессиональной деятельности.

На контроллерах HI, работающих под управлением ОС Debian Linux и платформы Node-RED, существует два фундаментальных уровня логирования, каждый из которых отвечает за свою область ответственности.

📋 Ключевые понятия:

Логи уровня приложения (Application Logs): Генерируются непосредственно средой исполнения Node-RED. Они содержат информацию о работе ваших потоков (flows), ошибках в узлах, отладочных сообщениях и предупреждениях. Это ваш "вид изнутри" на логику автоматизации.

Логи уровня операционной системы (System Logs): Генерируются ядром Linux и системными службами. Они содержат информацию о низкоуровневых событиях: работе сетевых интерфейсов, подключении и отключении USB-устройств (например, адаптеров RS-485), ошибках файловой системы, запуске и остановке сервисов. Это "вид снаружи" на состояние контроллера как аппаратной единицы.

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

| Характеристика | Логи Node-RED (`node-red-log`) | Системные логи (`journalctl`) |

| --------------------------- | -------------------------------------------------------------- | ---------------------------------------------------------------- |

| Источник | Среда исполнения Node-RED, узлы (`node`) в потоках. | Ядро Linux, системные службы (`systemd`), драйверы устройств. |

| Основная утилита | `node-red-log` | `journalctl` |

| Что искать? | Ошибки исполнения логики, сбои подключения (MQTT, Modbus), отладочные сообщения (`Debug` node), предупреждения. | Ошибки оборудования, сбои сети, проблемы с USB-портами, статусы запуска/остановки сервисов, нехватка ресурсов. |

| Когда использовать? | Сценарий не работает как задумано, данные не приходят, устройство не реагирует на команду. | Контроллер недоступен по сети, не определяются внешние устройства (RS-485, CAN), Node-RED не запускается. |

| Пример типовой проблемы | `"Cannot read property 'payload' of undefined"` в узле `Function`. | `"device descriptor read/64, error -110"` для `/dev/ttyUSB0`. |

Основной метод работы с логами на контроллере — это подключение по SSH и использование утилит командной строки. `node-red-log` предоставляет удобный интерфейс для просмотра логов именно от Node-RED, в то время как `journalctl` является стандартным мощным инструментом для анализа всех системных сообщений, агрегируемых службой `systemd-journald`. В следующих разделах мы подробно разберем практическое применение обеих утилит.

---

Анализ логов Node-RED с помощью утилиты node-red-log

Утилита `node-red-log` — это специализированный инструмент, который выводит в консоль сообщения, сгенерированные запущенным на контроллере сервисом Node-RED. Это основной источник информации при отладке логики автоматизации.

Чтобы начать просмотр логов в реальном времени, подключитесь к контроллеру по SSH и выполните команду:

node-red-log

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

Структура сообщения в логе:

`[Временная метка] [Уровень] [Источник: Имя ноды] Текст сообщения`

`[Временная метка] [Уровень] [ID ноды] Текст сообщения от Debug`

Временная метка: Например, `24 Oct 14:25:10`. Показывает точное время события.
Уровень: `[info]`, `[warn]`, `[error]`, `[debug]`. Указывает на степень важности сообщения.
Источник: Может быть системным (`[runtime]`, `[flows]`) или исходить от конкретного узла, отображая его имя (`[Modbus-Read]`) или ID.
Текст сообщения: Непосредственно информационное, отладочное или ошибочное сообщение.

> 💡 Подсказка: Присваивайте нодам осмысленные и уникальные имена (например, 'Modbus-Счетчик-ЭЭ-Ввод1' вместо стандартного 'modbus getter'). Это критически важно для быстрой и эффективной фильтрации логов на сложных объектах, так как имя узла будет отображаться в логе.

Практика фильтрации логов

На реальном объекте поток логов может быть очень интенсивным. Для поиска нужной информации используется команда `grep`, которая фильтрует вывод по заданному шаблону.

Пример 1: Поиск ошибок от конкретного узла.

Предположим, у нас есть узел `Modbus-Getter` с именем "Опрос датчика CO2". Мы подозреваем, что с ним есть проблемы.

node-red-log | grep "Опрос датчика CO2"

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

Пример 2: Поиск всех ошибок и предупреждений.

Чтобы получить общую картину проблем в системе, можно отфильтровать сообщения по уровню важности.

node-red-log | grep -E "error|warn"

Флаг `-E` включает поддержку расширенных регулярных выражений, а `|` работает как "ИЛИ". Эта команда выведет все строки, содержащие слово `error` или `warn`.

Пример 3: Поиск по ключевому слову.

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

# Ищем проблемы с подключением к MQTT
node-red-log | grep "connect"

# Ищем таймауты от Modbus-устройств
node-red-log | grep -i "timeout"

Флаг `-i` делает поиск нечувствительным к регистру (`timeout`, `Timeout`, `TIMEOUT`).

Разбор типовых ошибок в логах Node-RED

`"Cannot read property 'payload' of undefined"`

* Лог: `24 Oct 14:30:15 - [error] [function:Обработка данных] TypeError: Cannot read property 'payload' of undefined`

* Причина: Это одна из самых частых ошибок. Она означает, что на вход узла `Function` пришло сообщение `msg`, у которого отсутствует свойство `payload` (например, пришел `null` или пустой объект). Часто это происходит после узла, который может не вернуть сообщение при определенных условиях (например, `Switch` без ветки `otherwise` или узел, который вернул `return null`).

Диагностика: Найдите узел "Обработка данных" (именно поэтому важно давать осмысленные имена!) и проверьте, что предшествующий ему узел всегда* возвращает сообщение с `msg.payload`.

Ошибка подключения к MQTT

* Лог: `24 Oct 14:35:01 - [error] [mqtt-broker:myBroker] Connection failed to broker: mqtt://192.168.1.10:1883`

* Причина: Узел Node-RED не может установить соединение с MQTT-брокером. Проблема может быть в неправильном IP-адресе, порте, ошибках в логине/пароле или сетевой недоступности брокера.

* Диагностика: Проверьте доступность брокера с контроллера командой `ping 192.168.1.10`. Убедитесь в правильности настроек в узле конфигурации `mqtt-broker`.

Сбой в узле Modbus

* Лог: `24 Oct 14:40:22 - [error] [modbus-read:Счетчик Меркурий] Modbus exception 2: Illegal data address`

* Причина: Устройство Modbus ответило, но сообщило об ошибке. Код исключения `2` означает, что вы пытаетесь прочитать регистр по адресу, который не существует на устройстве.

* Диагностика: Как мы рассматривали ранее, это классическая ошибка "off-by-one" или опечатка в адресе регистра. Сверьтесь с картой регистров устройства и конфигурацией узла `modbus-read`.

---

Диагностика системного уровня: работа с journalctl

Если `node-red-log` не показывает никаких ошибок, но система все равно работает некорректно, проблема, скорее всего, находится на более низком уровне — уровне операционной системы. Для ее диагностики используется утилита `journalctl`. Она позволяет просматривать централизованный журнал, куда пишут свои сообщения ядро Linux и все системные службы.

Ключевые команды и флаги

`journalctl` — очень мощный инструмент с множеством опций. Для задач инженера по автоматизации наиболее важны следующие команды:

Просмотр логов в реальном времени (`follow`)

journalctl -f

Эта команда, аналогично `node-red-log`, будет выводить новые сообщения по мере их поступления. Это полезно для наблюдения за реакцией системы на ваши действия в реальном времени (например, при переподключении USB-кабеля).

Фильтрация по сервису (`unit`)

Node-RED запускается на контроллере как системная служба (service) с именем `node-red.service`. Чтобы увидеть все системные логи, относящиеся только к этому сервису (включая сообщения о его запуске, остановке и сбоях), используйте флаг `-u`:

journalctl -u node-red.service

Чтобы смотреть их в реальном времени, можно скомбинировать флаги:

journalctl -fu node-red.service

Фильтрация по времени

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

# Показать логи за последние 15 минут journalctl --since "15 minutes ago" # Показать логи за определенный промежуток времени journalctl --since "2023-10-24 14:00:00" --until "2023-10-24 14:05:00"

Поиск причин сбоев на уровне ОС

Случай 1: Проблемы с USB-адаптером RS-485

Симптом: Устройства Modbus RTU периодически "отваливаются". В логах Node-RED могут быть ошибки `Port not open` или `Timeout`.

Диагностика: Смотрим логи ядра. USB-устройства обычно определяются как `/dev/ttyUSB0`, `/dev/ttyUSB1` и т.д.

    journalctl -f | grep ttyUSB

Если вы видите сообщения вида:

`usb 1-1.2: device descriptor read/64, error -110`

`usb 1-1.2: device not accepting address 5, error -110`

`ftdi_sio ttyUSB0: device disconnected`

Это явный признак аппаратной проблемы: плохой контакт в USB-разъеме, некачественный кабель, проблемы с питанием USB-порта или неисправность самого адаптера. Проблема не в Node-RED, а на физическом уровне.

Случай 2: Проблемы с сетью

Симптом: Контроллер периодически становится недоступен по сети, MQTT-соединение рвется.

Диагностика: Проверяем состояние сетевых интерфейсов (`eth0` для проводного, `wlan0` для Wi-Fi).

    journalctl | grep "eth0"

Сообщения вида `eth0: link is down` и `eth0: link is up` указывают на физическое переподключение кабеля или проблемы с сетевым коммутатором. Если в логах есть сообщения от DHCP-клиента об ошибках получения адреса, это указывает на проблемы в сетевой инфраструктуре объекта.

Случай 3: Анализ загрузки контроллера

Симптом: После перезагрузки по питанию один из сценариев не запускается.

Диагностика: Просмотрим лог последней загрузки системы с помощью флага `-b`.

journalctl -b

Это покажет все сообщения с момента включения контроллера. Прокручивая этот лог, можно увидеть, в какой последовательности стартовали службы, успешно ли был запущен `node-red.service`, не было ли ошибок при монтировании файловых систем или инициализации оборудования. Например, если USB-адаптер не определился при старте системы, вы увидите это здесь.

---

Комплексный подход: корреляция логов Node-RED и Linux

Самые сложные неисправности — те, что находятся на стыке уровней системы. Логика в Node-RED может быть безупречной, но если аппаратная часть под ней работает со сбоями, вся система будет нестабильна. Ключ к решению таких проблем — в корреляции событий, то есть в сопоставлении логов приложения и операционной системы по временным меткам.

> ⚠️ Внимание: Всегда проверяйте, что на контроллере настроена и работает служба синхронизации времени (NTP - Network Time Protocol). Расхождение времени даже на несколько секунд делает сопоставление логов из разных источников практически невозможным и может привести к неверным выводам при диагностике.

Разбор реального кейса: "Устройство Modbus RTU перестало отвечать"

Симптом: Каждые несколько часов перестают поступать данные от счетчика электроэнергии, подключенного по Modbus RTU через USB-адаптер. Через некоторое время связь восстанавливается сама собой. Шаг 1: Анализ логов Node-RED

Подключаемся к контроллеру и смотрим логи приложения, фильтруя их по имени нужного узла.

node-red-log | grep "Счетчик ЭЭ"

В выводе мы видим повторяющуюся картину примерно в 15:32:

24 Oct 15:32:10 - [error] [modbus-getter:Счетчик ЭЭ] Modbus-Read failed: Port not open
24 Oct 15:32:25 - [error] [modbus-getter:Счетчик ЭЭ] Modbus-Read failed: Port not open
...
24 Oct 15:35:01 - [info] [modbus-getter:Счетчик ЭЭ] Modbus-Read successful

Первичный вывод: Узел Modbus не может получить доступ к COM-порту (`/dev/ttyUSB0`), к которому подключен адаптер. Это может быть программная ошибка в Node-RED или что-то еще. Запоминаем время сбоя: около `15:32`. Шаг 2: Анализ системных логов

Теперь ищем события в системном журнале за тот же промежуток времени, уделяя особое внимание USB.

journalctl --since "2023-10-24 15:30:00" --until "2023-10-24 15:35:00"

Изучив вывод, мы находим следующие строки:

Oct 24 15:32:08 HI-Controller kernel: usb 1-1.3: USB disconnect, device number 6
Oct 24 15:32:08 HI-Controller kernel: ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
...
Oct 24 15:34:58 HI-Controller kernel: usb 1-1.3: new full-speed USB device number 7 using ehci-platform
Oct 24 15:34:59 HI-Controller kernel: ftdi_sio 1-1.3:1.0: FTDI USB Serial Device converter detected
Oct 24 15:34:59 HI-Controller kernel: usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB0

Шаг 3: Сопоставление и окончательный вывод

Картина становится ясной:

В `15:32:08` ядро Linux зафиксировало физическое отключение USB-устройства. Операционная система "потеряла" порт `/dev/ttyUSB0`.

Сразу после этого, в `15:32:10`, Node-RED попытался опросить счетчик через этот порт и получил ошибку `Port not open`, так как порта больше не существовало в системе.

В `15:34:59` ядро зафиксировало переподключение устройства и создало порт `/dev/ttyUSB0` заново.

В `15:35:01` следующий опрос из Node-RED прошел успешно.

Вывод: Проблема не в логике Node-RED и не в настройках Modbus. Проблема носит аппаратный или физический характер. Необходимо проверить USB-адаптер RS-485, USB-кабель, качество подключения в разъемах и, возможно, питание контроллера, которое может проседать, вызывая сбои в работе USB-хоста. Такой подход экономит часы времени, которые могли быть потрачены на бесплодную отладку потоков в Node-RED.

---

Итоги и лучшие практики

В этом уроке мы рассмотрели два мощных инструмента для диагностики — `node-red-log` и `journalctl`. Умение эффективно использовать их и, что самое главное, сопоставлять их выводы, отличает профессионального инженера-инсталлятора.

🔗 Связанный материал:

> Данный урок является логическим продолжением тем, раскрытых в `COURSE-04-M08-L02` 'Углубленное использование нод Debug, Status и Catch' и `COURSE-04-M08-L03` 'Диагностика физического уровня'. Только комплексное применение всех методик — отладки в Node-RED, физической проверки и анализа логов — дает полный контроль над системой.

Ключевые команды, которые должны быть в арсенале каждого инженера:

`node-red-log | grep "Имя Узла"` — для быстрой изоляции сообщений от конкретного компонента логики.
`journalctl -fu node-red.service` — для отслеживания системных событий, связанных с работой Node-RED.
`journalctl --since "10 minutes ago"` — для анализа недавних системных сбоев.

Лучшие практики для "чистых" логов

Чтобы логи были вашим помощником, а не источником хаоса, следуйте простым правилам при разработке потоков:

Осмысленное именование узлов: Как мы уже убедились, `grep` по имени — самый быстрый способ найти нужный узел. `Управление Светом Гостиная` гораздо информативнее, чем `rpi gpio out`.

Используйте `node.warn()` и `node.error()`: В ваших узлах `Function` не стесняйтесь добавлять собственное логирование.

* `node.warn("Получено некорректное значение влажности: " + humidity);` — для событий, которые не являются критической ошибкой, но требуют внимания.

* `node.error("Критическая ошибка: отсутствует обязательное поле 'id' в сообщении!", msg);` — для ситуаций, которые приводят к сбою логики. Второй аргумент `msg` прикрепит к логу все сообщение, что бесценно для отладки.

Не засоряйте лог: Не оставляйте в финальной версии проекта включенные узлы `Debug`, выводящие данные каждую секунду. Используйте их только на этапе отладки. Для постоянного мониторинга лучше подходит узел `Status`.

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

Что дальше?

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