Участвуют 3 контроллера 7.3.3E/3 с прошивкой wb-2407
На каждом контроллере подключено несколько устройств, которые необходимо отслеживать. На всех примерно одинаковое количество устройств.
Например:
4 MAP,
5 MAI,
4 DI-WD-14,
1 M1W2.
Сценарий 1
На контроллерах установлен zabbix-agent2. Включены активные проверки. Включена подписка на mqtt по tcp://127.0.0.1:1883 без авторизации.
На сервере Zabbix mqtt.get принимает мастер-данные. Сценарий 2
На контроллерах удален zabbix-agent2.
На сервере Zabbix установлен zabbix-agent2, включены активные проверки. Включена подписка на mqtt по tcp://{IP контроллера}:1883 без авторизации.
На сервере Zabbix mqtt.get принимает мастер-данные. Сценарий 3
ПО MQTT Explorer запущен и читает данные.
При любом сценарии если выполнять 1 запрос (1 хост в Zabbix), то все ок. данные идут ежесекундно, если изменяются.
Как только я включу 2 запроса и более, то все сразу умирает.
Лог Zabbix-agent2 пишет что
[MQTT] cannot subscribe topic ‘/devices/GC_TP1_IN2/controls/#’ to [tcp://192.168.2.131:1883]: timed out while subscribing
[MQTT] connection lost to [tcp://192.168.2.131:1883]: pingresp not received, disconnecting Сценарий 1
Проработав в таком режиме некоторое время контроллер зависает намертво. Может отвалиться web, может работать, но никакие данные не отображаются. Невозможно собрать диагностические данные. Помогает только перезапуск контроллера. Сценарий 2
Контроллеры работают сами по себе, у них все хорошо. Но данные Zabbix-agent2 на сервере Zabbix не собираются. В логах агента аналогично. Сценарий 3
MQTT Explorer аналогично - 1 окно работает нормально, запускаешь 2 окна - появляется табличка Disconnected from server.
Т.е. я делаю вывод что нельзя подключиться несколько раз к 1 контроллеру для получения данных?
Добрый день,
Похоже, что у вас возникает проблема с многократными подключениями к MQTT-брокеру на контроллерах Wiren Board, что приводит к перегрузке ресурса или блокировке соединений. MQTT-брокер по умолчанию поддерживает одновременные подключения, но его настройки и нагрузка могут сильно влиять на стабильность.
При вашем сценарии я бы рекомендовал реализовать внешний общий MQTT брокер, который собирает все метрики от N контроллеров и направляет их в zabbix.
Для более детального анализа проблемы пришлите, пожалуйста, архивы с диагностической информацией контроллеров. Создание архива описано в документации.
Эта инструкция - mqtt.get работает если хост один.
В zabbix нельзя получить Зависимый элемент данных из другого узла, например Одним узлом (одним запросом) получаем данные по всему контроллеру, а другим узлом(-ами) получаем данные через JSON через зависимый элемент.
Добрый день, прошу прощения за долгий ответ.
На данный момент нашел, наверное, самое короткое решение по настройке мониторинга в Zabbix нескольких контроллеров. Потребуется настроить агента и следовать следующим шагам:
1. Установка Zabbix Agent 2 на каждом контроллере
Выполните установку агента:
apt update
apt install zabbix-agent2
2. Настройка файла конфигурации
Отредактируйте файл конфигурации /etc/zabbix/zabbix_agent2.conf на каждом контроллере. Укажите параметры:
LogFile=/var/log/zabbix/zabbix_agent2.log
LogFileSize=0
DebugLevel=3
Server= # IP вашего Zabbix Server
ServerActive= # IP вашего Zabbix Server
Hostname=WirenBoard-Controller-1 # Уникальное имя для вашего контроллера
В разделе Конфигурация → Узлы сети выберите нужные контроллеры и добавьте им созданный шаблон Template WirenBoard MQTT All Topics.
6. Проверка данных
Перейдите в Мониторинг → Последние данные и найдите данные по элементу MQTT All Topics. Вы должны увидеть все сообщения, которые публикуются на MQTT-брокере контроллера.
День добрый!
Это все понятно. Оно так и работает.
Проблема как раз в 5 пункте.
Когда 1 узел сети - все работает отлично.
Когда 2+ начинаются проблемы как в топик старте.
Т.е. проблема заключается в том что ZA2 первый раз подключаясь к брокеру инициирует одно соединение (при одном узле).
При 2+ узлах он инициирует 2+ подключения к брокеру. При этом первое соединение должно быть сброшено.
3й узел подключается - второе соединение сбрасывается и так по кругу.
Т.е. как я и писал ранее Брокер поддерживает 1 соединение от одного клиента.
Давайте уточним, как воспроизвести поведение которое наблюдается у вас.
У меня есть объект, описанный в узлах сети. К нему применены несколько шаблонов, в каждом из которых несколько топиков.
Все верно?
А можете мне скинуть шаблон с которым вы подключаетесь к узлу?
Ко всему прочему у меня добавилась проблема с
Спойлер
Failed: cannot extract value from json by path “$[‘/devices/GC_TP1_IN1/controls/Irms L1’]”: no data matches the specified path
1134194:20241119:153737.147 error reason for “GC TP1-1:Irms.L2” changed: Preprocessing failed for: {“/devices/GC_TP1_IN1/controls/Температура трансформатора 10Кв”:“28”}
Failed: cannot extract value from json by path “$[‘/devices/GC_TP1_IN1/controls/Irms L2’]”: no data matches the specified path
1134194:20241119:153737.147 error reason for “GC TP1-1:Irms.L3” changed: Preprocessing failed for: {“/devices/GC_TP1_IN1/controls/Серийный номер”:“3403015”}
Failed: cannot extract value from json by path “$[‘/devices/GC_TP1_IN1/controls/Irms L3’]”: no data matches the specified path
1134194:20241119:153737.147 [Z3008] query failed due to primary key constraint: [1062] Duplicate entry ‘103495-1732019854-435303983’ for key ‘PRIMARY’
1134194:20241119:153737.147 skipped 1 duplicates
Он берет каждое полученное значение, сравнивает его с json path и, если оно не совпадает, выдает ошибку.
И так каждый раз по каждому item.
Приложил свой шаблон, часть для примера. Wirenboard TP new mqtt.yaml (2,0 КБ)
Лог сервера zabbix_server.log (6,4 МБ)
У меня крайне простой тестовый: zbx_export_templates.yaml (2,6 КБ)
агент 6.0.14, штатный из дистрибутива
И, что интересно я столкнулся с подобным. После нескольких перезапусков c добавлением топиков вижу в логах:
ov 21 14:23:56 wirenboard-AQASN7R6 mosquitto[20238]: 1732199036: New connection from ::1:55684 on port 1883.
Nov 21 14:23:56 wirenboard-AQASN7R6 mosquitto[20238]: 1732199036: New client connected from ::1:55684 as Zabbix agent 2 6.0.14 d9c18619-118d-6f7b-c96f-85ea21e90af4 (p2, c1, k30).
Nov 21 14:23:56 wirenboard-AQASN7R6 mosquitto[20238]: 1732199036: Client Zabbix agent 2 6.0.14 d9c18619-118d-6f7b-c96f-85ea21e90af4 disconnected due to malformed packet.
Nov 21 14:23:56 wirenboard-AQASN7R6 zabbix_agent2[12287]: [MQTT] connection lost to [tcp://localhost:1883]: EOF
Nov 21 14:23:56 wirenboard-AQASN7R6 zabbix_agent2[12287]: [MQTT] cannot subscribe topic '/devices/SocketRelay_2floor/controls/P L1 ' to [tcp://localhost:1883]: Connection lost before Subscribe completed
Интересная тема. Не натыкался на нее.
НО там пишут что на 7 версии проблема остается.
Если с 7,2 не получится надо на 6.2.9 откатываться.
Жду тестов)
Наконец-то просвет в задаче.
С проблемой “cannot subscribe …” борюсь уже очень давно.
(даже подписан на ряд топиков с форума zabbix с этой траблой но там решения не нашли, как и в поддержке zabbix).
Сразу говорю: никакие откаты на старые версии не помогут - проверено.
Увеличение таймаутов тоже.
Корневая проблема - в библиотеках клиента paho, которые использует плагин агента2.
По моим наблюдениям ошибка возникает когда агента2 пытается подписаться на большое количество топиков.
Вот да. Я пару дней поэспериментировал и получил что если топиков больше 3-4 то вероятность ошибок подписки увеличивается. На 1-2 топика работает стабильно.
Тут моих компетенций довольно мало для подробной диагностики.
