активная проверка, mqtt, update interval

[shkiper]

прошу пояснить логику организации времени обновления данных при активных проверках (zabbix_server (Zabbix) 5.2.3, zabbix_agent2 (Zabbix) 5.2.3)
поля update interval (при выборе активной проверки) нет, я так понимаю это регулируется на стороне клиента - клиент берет список активных проверок с сервера, и потом сам посылает на сервер данные, когда считает нужным, вопрос - когда?
я сделал для пробы, элемент данных mqtt.get, который берет данные с mqtt на другом узле (это контроллер умного дома), данные приходят раз в 10 секунд, я не могу понять где это регулируется?
есть опасения, что если я нагружу контроллер умного дома всеми нужными ключами, то он загрустит

или нет?
тестовый итем это просто значение
рабочие данные будут через json и пред-обработку, хотя конечно их тоже будет некоторое количество
насколько грузит mqtt забор топика по сравнению с единичным значением?

[Hamardaban]

во первых интервал обновления у элемента данных при zabbix active есть! его активный агент к себе засасывает и в соответствии с ним данные пушит.
если у вас нет интервала - значит это что-то еще (например тип - трапер). скрин в студию.
во вторых лучше получать всё за один запрос а потом парсить на стороне сервера. есть одно но - можно нарваться на большой объем данных который где нибудь не пролезет в процессе.

[shkiper]

в примерах (старых) интервал есть, у меня нет, вот скрины
обычный агент и активный

[shkiper]

интервал пропадает при выборе типа ключа mqtt.get
это явно не спроста

[shkiper]

в общем mqtt.get работает, это очень хорошо
правильный синтаксис в препроцессинге для jsonpath: $.['/devices/wb-mcm8_26/controls/Input 2 counter']
но я ожидал что но будет работать по другому
вот демо с саммита 2020, там результат mqtt.get - цельный json с кучей полей


у меня по другому, в принципе в документации так и написано - подписывается на топик (в соответствии с указанным шаблоном), ждет пока туда что-нибудь упадет и при поступлении данных сразу скидывает, т.е. построчно, json однострочный всегда


соответственно в зависимом элементе с фильтром по jsonpath постоянно висит ошибка

пока не попадется подходящая строка, тогда он ее нормально обрабатывает

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

[Hamardaban]

зато теперь понятно почему интервала опроса нет! :-)
mqtt еще не пробовал (устройств нет) а вот с modbas тоже на грабли понаступал...
спасибо за исследования. есть над чем думать

[shkiper]

да пожалуйста
я с модбасом тоже планирую попробовать, шлюзы от WB (RS-485 - Ethernet) и без контроллера, сразу в заббикс

тут думаю, что таки делать с потоком данных?
например приходят со счетчика показания, это хорошо конечно что данные потоком сыпятся без проблем, но мне столько не надо
расход ЭЭ засекать каждые 5-10 секунд совершенно излишне, раз в минуту предостаточно (можно даже раз в 10 минут)
т.к. срок хранения показаний счетчиков у меня большой, то база будет гигантской
если со подсчетом импульсов я как-то выкрутился (в соседней теме)
то тут пока мыслей нет
как порубить этот поток на отрезки времени и взять из него значения по таймингу?

[Kos]

как порубить этот поток на отрезки времени и взять из него значения по таймингу?

Просто как идея: можно выставить для оригинального элемента данных короткий срок хранения (1 день), а затем сделать ещё один элемент данных - вычисляемый, с нужным интервалом (допустим, раз в 10 минут), функцией avg(10m) от оригинального элемента данных и более адекватным сроком хранения.

[shkiper]

среднее не всегда подойдет, например если это показания счетчика потребление ЭЭ, мне надо чтоб они были реальные и привязаны к временной метке
пока для некоторых вещей оставлю старый вариант
посоветовался со знакомым разработчиком, подлез к нему с вопросом - как вообще такие проблемы решаются в принципе?
говорит надо сохранять временно куда-то поток и потом агрегировать из него нужные данные в долговременное хранилище, привел в качестве примера ELK, типа там подобные инструменты развиты, в MongoDB говорит можно создавать коллекцию с ограничением количества данных в ней
в принципе логично, но я точно не вывезу, мне надо готовое решение, пока думаю
база данных сразу пошла в рост, пришлось накинуть места на виртуалке
даже срок хранения потока в 1 день, это все равно постоянный рост базы, удаление старых записей в БД не добавит места сразу, а добавлять объем данных поток будет нормально так
щас посмотрю как оно будет
на потоковых ключах пока поставил "не сохранять историю" (она там не нужна, на них опираются зависимые поля с предобработкой, там данных уже меньше)

пока вот пример преимуществ чтения с потока, черный график - mqtt.get, синий mosquitto_sub (на сиреневую заливку не обращайте внимания))
прыжки это то-ли заббикс подтупливает - провалы в приеме, то-ли устройство

но при переходе на mqtt.get все просто идеально (тут без "подрезок" ) и плюс изменения состояния не примерно в интервале, а мгновенно

[Joying]

meet the same situation，How to solve this problem？？
thanks!

[shkiper]

What problem?

[Joying]

What problem?

mqtt update interval doesn't display and mqtt.get not working.
zabbix_server (Zabbix) 5.2.3, Zabbix5 zabbix_agent2[2801]: Starting Zabbix Agent 2 (5.2.3)

[Hamardaban]

When using mqtt, item does not have polling intervals because mqtt like "data flow".
The concept of "polling interval"does not apply to it.
All data from the topic that the client subscribes to, client will receive immediately as the broker receives them from the publishers.

https://mqtt.org/getting-started/

https://git.zabbix.com/projects/ZBX/...mqtt/README.md

[shkiper]

mqtt update interval doesn't display and mqtt.get not working.
zabbix_server (Zabbix) 5.2.3, Zabbix5 zabbix_agent2[2801]: Starting Zabbix Agent 2 (5.2.3)

it's ok
this have another logic
data come to the element?
if not, what error returns to item?
logs (agent, server) check for any errors

need check realy work mqtt service (port listen)

netstat -tupln | grep 1883
tcp 0 0 0.0.0.0:1883 0.0.0.0:* LISTEN 324/mosquitto

if is jsonpath preprocessing, then the reason verylikly is in it, check syntax