Имеется такая задача: при срабатывании триггера на Zabbix-сервере необходимо отправить MODBUS-сообщение на устройство, подключенное к контроллеру WirenBoard 7 через интерфейс RS-485.
- В файле конфигурации сервера /etc/zabbix/zabbix_server.conf разрешил глобальные скрипты EnableGlobalScripts=1
- Создал скрипт, который при срабатывании триггера должен отправить команду sudo /usr/bin/printf ‘test’ > /dev/ttyRS485-2
- На контроллере WirenBoard 7 разрешил Zabbix-агенту 2 выполнение команд. Для этого в конфигурационный файл /etc/zabbix/zabbix_agent2.conf вставил строку AllowKey= system.run[*]
- На всякий случай разрешил запись команд в файл /var/log/zabbix/zabbix_agent2.log. Для этого раскомментировал строку Plugins.SystemRun.LogRemoteCommands=0 и изменил ее значение на 1.
- Перезапустил агент
- В каталоге /etc/sudoers.d создал файл zabbix-command и вписал в него строку zabbix ALL=(ALL) NOPASSWD: /usr/bin/printf
При проверке срабатывания триггера команда не выполняется - на RS485 ничего не выдается. В системном журнале WEB-интерфейса WirenBoard 7 видно, что она получена. Никаких ошибок или предупреждений нет. В логе zabbix_agent2.log команда также зафиксирована.
Далее попробовал действовать через MQTT.
- Изменил скрипт на Zabbix-сервере: sudo mosquitto_pub -r -t ‘/devices/buzzer/controls/enabled/on’ -m 1
- В файл /etc/sudoers.d/zabbix-command добавил строку zabbix ALL=(ALL) NOPASSWD: /usr/bin/mosquitto_pub
- Проверил триггер и все заработало. Зуммер включился!
Вопрос: почему не выполняется команда printf в первом случае?
P.S. Костыльный путь с создание виртуального устройства, который отправляет команду на RS485 с помощью runShellCommand(“/usr/bin/printf ‘test’ > /dev/ttyRS485-2”) при записи в соответствующий контрол сигнала с помощью mosquitto_pub работает.
Добрый день! Спасибо большое за подробное описание!
Думаю, что причина, по которой не работает комада sudo /usr/bin/printf 'test' > /dev/ttyRS485-2 в следующем: от имени рута выполняется только /usr/bin/printf 'test', а перенаправление > /dev/ttyRS485-2 – уже от пользователя, под которым запущен агент, который не в группе dialout и прав на запись в порт у него нет.
Попоробуйте добавить пользователя в группу или перенаправять в порт от рута: sudo sh -c "printf test > /dev/ttyRS485-2".
На самом деле стандартный способ общения с устройствами подключенными к контроллеру – MQTT, отправка команд прямо в порт может помешать wb-mqtt-serial, или он может помешать отправке команд прямой записью в порт. Занят ли порт wb-mqtt-serial, можно проверить, например, командой fuser -v /dev/ttyRS485-2
Собственно, инеграцию агента 2 мы рекомендуем делать через MQTT.
Какую задачу вы решаете?
Здравствуйте! Благодарю вас за оперативный ответ.
Теперь о результатах проверки:
- Zabbix-agent2 выполняется от имени root (команда ps aux |grep zabbix-agent2).
- В списке группы dialout по умолчанию находится единственный пользователь knxd.
- Добавление пользователей root и zabbix (на всякий случай) командой usermod -aG dialout root|zabbix ничего не дало. Команда printf по-прежнему не выполняется.
- Изменение команды в скрипте на рекомендуемую вами sudo sh -c “printf ‘test’ > /dev/ttyRS485-2”, работает. Данные выдаются на нужный порт. Предварительно пришлось добавить в файл zabbix-command разрешение для sh. Так что рабочий вариант уже есть. Спасибо большое.
Теперь основной вопрос:
Как лучше, с вашей точки зрения, отправить MODBUS-команду на контроллер, подключенный к WirenBoard7 при срабатывании триггера Zabbix-сервера, так чтобы не происходило “бодание” с wb-mqtt-serial?
Дополнительное описание системы:
- Дополнительный контроллер постоянно опрашивается драйвером wb-mqtt-serial. Данные передаются на Zabbix-сервер.
- Триггер срабатывает при выходе считываемых значений за определенные пределы.
- При срабатывании триггера необходимо отправить MODBUS-команду на дополнительный контроллер. Жесткого realtime’а не требуется. Результат выполнения команды помещается в один из считываемых регистров. То есть обратная связь есть.
- Встроенный в Zabbix-agent2 mqtt-plugin нам не подходит, поскольку при его использовании нет возможности регулировать период опроса и поэтому сильно перегружается ненужными данными Zabbix-сервер. Кроме этого за ним замечен тот грех, что при “отвале” сервера, агент впадает в непрерывный реконнект к mosquitto и восстанавливается только после перезапуска.
- Версия Zabbix-agent2 - 6.0.14.
Система на основе вашего контроллера WirenBoard развертывается в сети медицинских центров репродукции и предназначена для круглосуточного мониторинга критически важных процессов.
1-4:
А подскажите, не очень понимаю, “команда printf по-прежнему не выполняется”: что при этом происходит у вас, и чего не происходит? По каким признакам вы понимаете, что команда не выполнилась?
Как отправить MODBUS-команду на устройство, подключенное к контроллеру: скажите, а что за устройство подключено к вашему контроллеру Wiren Board 7? Вы тоже называете его контроллером – это утройство Modbus-slave? Для slave-устройства надо создать шаблон, где описать регистр, в который вы хотите отправить нужное значение, добавить устройство с этим шаблоном, а затем публиковать значения по MQTT, например, через mosquitto_pub.
5-8:
А вот это “триггер срабатывает при выходе считываемых значений за определенные пределы” – эти значения получаются тоже контроллером Wiren Board 7?
В этом случае мне кажется, что самый простой способ реализовать управление – через движок правил контроллера, не используя для этого заббикс-агент – это позволит и снизить нагрузку на контроллер, и быстрее реагировать, и устранит дополнительные точки отказа.
Здравствуйте.
Команда не выполнилась потому, что на порт RS485-2 ничего не выдается. В “Системном журнале” WirenBoard команда printf, которая должна предшествовать команде mosquitto_pub, отсутствует:
Тем не менее в логе zabbix_agent2, команда printf имеет место быть:
К контроллеру WirenBoard в нашей системе подключается в качестве slave-устройства специализированный контроллер весовых ячеек (load cells). За рекомендацию использовать шаблон спасибо, будем пробовать.
Контроллер WirenBoard, в нашей системе, помимо все прочего, транслирует данные от весового контроллера на Zabbix-сервер. Алгоритм их обработки для выявления кризисных ситуаций нетривиален, и должен быть единым для всех объектов одного типа и легко модифицироваться администраторами сервера. Кроме команд на slave-контроллер срабатывание триггеров генерирует еще некоторое количество алертов (Telegram, e-mail и т.д.), которые дифференцируются для разных Zabbix-пользователей и групп. Поэтому нам удобнее реализовывать управление централизованно на Zabbix-сервере.Что касается точек отказа, то отправляемые команды slave-контроллеру не критичны и носят индикативный характер. Кроме этого, само событие потери связи с объектовым контроллером (WirenBoard), является критическим событием и инициирует соответствующие триггеры.
Перепроверили еще раз вашу рекомендацию добавить пользователя в группу dialout. Все заработало. Добавили пользователя zabbix:
НАДО БЫЛО ПЕРЕЗАГРУЗИТЬ WirenBoard после модификации /etc/group. Вчера не работало именно из того, что забыли перегрузиться. Спасибо еще раз за разбор нашего случая и рекомендации.
Двигаться будем в направлении организации обратного канала “по правильному”, то есть через MQTT.
О, отличные новости! Пока писал ответ, все заработало!
Хотел полюбопытствовать: скажите, пожалуйста, а как вы ставили агент v2 на контролллер?
Насколько я знаю, zabbix-agent2 отсутствует в штатном репозитории, есть только агент v1. Вы его сами собирали под нашу архитектуру?
Почему нет? Все имеется. В смысле Zabbix-agent2 имеется:) Во всяком случае, он ставится очень просто:
Понял, спасибо, вы не обновляли контроллер с тех пор, как пакет еще был в репозиториях. Сейчас бы не удалось, bullseye-backports теперь EOL, на зеркалах его больше нет.
Будьте осторожны с обновлениями. Хотя после apt updae && apt upgrade агент, конечно, не должен просто пропасть. (Мы когда-то перейдем на Debian 12, конечно, там сейчас есть 1:7.0.9+dfsg-1~bpo12+1.)
Отчасти из-за таких ситуаций мы рекомендуем на контроллер устанавливать агент1, а агент2 устанавливать на сервер и общаться с контроллером по mqtt.
Хотел вас предупредить о такой ситуации. Тем более что у вас мониторинг критически важных процессов завязан на агент2.
Доброе утро. Спасибо большое за предупреждение. Контроллер обновляли, агент при этом, действительно, никуда не делся. В дальнейшем будем внимательнее при обновлениях.
1 лайк
