Мониторинг очереди данных RabbitMQ

[exesition]

В работе используется RabbitMQ. Данные ходят и все хорошо, но проблема в том, что иногда случается, что данные копятся, но с очереди не разбираются и это крайне плохо(смотрим картинки. График - когда случается проблема. График-2 все нормально )
Хотелось бы в случаях, когда очередь не разбирается какое то время и растет количество сообщений повесить триггер, который бы об этом оповещал. Данные собираются трапером.

Пока что на ум пришло только {rmq01.netsrv.pw:rabbitmq.queue.messages[kungur.1c,db9tokungur.data].count(300,50,gt)}=4, но по документации пишется что функция должна отрабатывать по принципу количество значений за последние 5 минут, которые больше '50' и только после 4-х проверок если значение удовлетворяет условию должен срабатывать.
На деле срабатывает почти сразу если сообщений в очереди становится больше 50.

Главное условие чтобы увидеть если в течение 20 минут наблюдается аномальный простой с сообщениями то слать уведомление.

[Kos]

Пока что на ум пришло только {rmq01.netsrv.pw:rabbitmq.queue.messages[kungur.1c,db9tokungur.data].count(300,50,gt)}=4, но по документации пишется что функция должна отрабатывать по принципу количество значений за последние 5 минут, которые больше '50' и только после 4-х проверок если значение удовлетворяет условию должен срабатывать

Не совсем так.
Значение триггера в любом случае пересчитывается при каждом получении нового значения для каждого из перечисленных в триггере элементов данных.
В данном случае выражение триггера имеет смысл: "если за последние 5 минут было ровно 4 значения, которые больше 50, то ПРОБЛЕМА". Которая по счёту это проверка - неважно. Например, у вас за последние 5 минут могло быть три значения больше 50, потом 20 нулевых значений, а потом - одно снова больше 50.

Кроме того, это условие имеет ещё один недостаток: сравнение на точное совпадение. Т.е. если придёт пятое значение, большее 50, то триггер уже вернётся в состояние ОК.
Мы не знаем, с какой периодичностью у вас эти значения собираются (и может ли возникнуть такая ситуация на самом деле), но теоретически - может.

Если вы хотите, чтобы триггер срабатывал в случае, когда последние 4 принятых значения все больше какого-то порога, то проще воспользоваться функциями min() или max().
Например:
{rmq01.netsrv.pw:rabbitmq.queue.messages[kungur.1c,db9tokungur.data].min(#4)}>50
перейдёт в состояние ПРОБЛЕМА, когда все 4 последних значения будут больше 50, и вернётся в OK при первом же значении, которое не превышает 50.

Или:
{rmq01.netsrv.pw:rabbitmq.queue.messages[kungur.1c,db9tokungur.data].max(#4)}>50
перейдёт в состояние ПРОБЛЕМА, когда хотя бы одно из 4 последних значений будет больше 50, и вернётся в OK, когда все 4 последних значения буду меньше или равны 50.

[exesition]

Не совсем так.
Значение триггера в любом случае пересчитывается при каждом получении нового значения для каждого из перечисленных в триггере элементов данных.
В данном случае выражение триггера имеет смысл: "если за последние 5 минут было ровно 4 значения, которые больше 50, то ПРОБЛЕМА". Которая по счёту это проверка - неважно. Например, у вас за последние 5 минут могло быть три значения больше 50, потом 20 нулевых значений, а потом - одно снова больше 50.

Кроме того, это условие имеет ещё один недостаток: сравнение на точное совпадение. Т.е. если придёт пятое значение, большее 50, то триггер уже вернётся в состояние ОК.
Мы не знаем, с какой периодичностью у вас эти значения собираются (и может ли возникнуть такая ситуация на самом деле), но теоретически - может.

Если вы хотите, чтобы триггер срабатывал в случае, когда последние 4 принятых значения все больше какого-то порога, то проще воспользоваться функциями min() или max().
Например:
{rmq01.netsrv.pw:rabbitmq.queue.messages[kungur.1c,db9tokungur.data].min(#4)}>50
перейдёт в состояние ПРОБЛЕМА, когда все 4 последних значения будут больше 50, и вернётся в OK при первом же значении, которое не превышает 50.

Или:
{rmq01.netsrv.pw:rabbitmq.queue.messages[kungur.1c,db9tokungur.data].max(#4)}>50
перейдёт в состояние ПРОБЛЕМА, когда хотя бы одно из 4 последних значений будет больше 50, и вернётся в OK, когда все 4 последних значения буду меньше или равны 50.

min и max как и count не совсем те выражения, что необходимы. Оно не позволит выявить проблему именно "застоя" т.к. сообщения могу перестать отправляться и при меньших количествах. Похоже нужно делать какое то сложное выражение чтобы исполнялось 2 из 3 условий и только потом шло уведомление...

Основная задача задумана как "Ненулевое количество сообщений в очереди в течение 20 минут и более.
Алерт: "%queue_name% - сообщения находятся в очереди более 20 минут"

[Kos]

min и max как и count не совсем те выражения, что необходимы. Оно не позволит выявить проблему именно "застоя" т.к. сообщения могу перестать отправляться и при меньших количествах. Похоже нужно делать какое то сложное выражение чтобы исполнялось 2 из 3 условий и только потом шло уведомление...

Основная задача задумана как "Ненулевое количество сообщений в очереди в течение 20 минут и более.
Алерт: "%queue_name% - сообщения находятся в очереди более 20 минут"

Ну, "Ненулевое количество сообщений в очереди в течение последних 20 минут" - это как раз и есть

{rmq01.netsrv.pw:rabbitmq.queue.messages[kungur.1c,db9tokungur.data].min(20m)}>0

[exesition]

Ну, "Ненулевое количество сообщений в очереди в течение последних 20 минут" - это как раз и есть

{rmq01.netsrv.pw:rabbitmq.queue.messages[kungur.1c,db9tokungur.data].min(20m)}>0

Хорошо. Попробую использовать такой триггер
В таком случае если мы хотим отследить условие "Нулевое количество сообщений в очереди в течение 20 минут и более"
{rmq01.netsrv.pw:rabbitmq.queue.messages[kungur.1c,db9tokungur.data].nodata(20m)}=1, верно? и кроме nodata чем еще можно попробовать?

[Kos]

Нет, nodata() - это вообще немного не о том. Это проверка не того, какие данные поступали, а того, поступали ли данные вообще.
Вы упомянули, что в вашем случае данные собираются трапером, т.е., по всей видимости, отсылаются каким-то скриптом, в который вставлен вызов утилиты zabbix_sender.
Было бы легче сориентироваться, если бы вы могли немного подробнее рассказать о ваших настройках - в частности, как часто этот zabbix_sender отсылает данные (или там вообще нет конкретной периодичности?).

[exesition]

Нет, nodata() - это вообще немного не о том. Это проверка не того, какие данные поступали, а того, поступали ли данные вообще.
Вы упомянули, что в вашем случае данные собираются трапером, т.е., по всей видимости, отсылаются каким-то скриптом, в который вставлен вызов утилиты zabbix_sender.
Было бы легче сориентироваться, если бы вы могли немного подробнее рассказать о ваших настройках - в частности, как часто этот zabbix_sender отсылает данные (или там вообще нет конкретной периодичности?).

Установлено следующее ПО

https://github.com/zarplata/zabbix-agent-extension-rabbitmq

Если верить описанию там не используется zabbix_sender.

[Kos]

Если верить описанию там не используется zabbix_sender.

Ну ладно, это непринципиально - видимо, его функциональность засунута в сам продукт.
Но какая-то периодичность получения данных существует или нет? Если да - то триггерной функцией nodata() вы можете контролировать, что данные от этого продукта всё ещё поступают, а состояние проверять, анализируя сами поступающие данные.

[exesition]

Ну ладно, это непринципиально - видимо, его функциональность засунута в сам продукт.
Но какая-то периодичность получения данных существует или нет? Если да - то триггерной функцией nodata() вы можете контролировать, что данные от этого продукта всё ещё поступают, а состояние проверять, анализируя сами поступающие данные.

Узнал что данные собираются каждые 30 секунд. Данные собираются в виде 0.03/s
Как можно организовать в таком случае мониторинг по условию "Если значение по 0 в течение 20 минут, то значит проблема"



за подсказку с функцией min() спасибо. Действительно стало работать, как хотелось бы это видеть

[Kos]

Узнал что данные собираются каждые 30 секунд. Данные собираются в виде 0.03/s
Как можно организовать в таком случае мониторинг по условию "Если значение по 0 в течение 20 минут, то значит проблема"

Соответственно, логика будет: max(20m)=0
Функция nodata(), которую вы упоминали, может использоваться для контроля того, работает ли сам мониторинг (т.е. поступают ли какие-то данные вообще).

[exesition]

Соответственно, логика будет: max(20m)=0
Функция nodata(), которую вы упоминали, может использоваться для контроля того, работает ли сам мониторинг (т.е. поступают ли какие-то данные вообще).

Cпасибо. В оф документации как то не учтены эти моменты. Спасибо! Буду знать

[exesition]

Соответственно, логика будет: max(20m)=0
Функция nodata(), которую вы упоминали, может использоваться для контроля того, работает ли сам мониторинг (т.е. поступают ли какие-то данные вообще).

Появился вопрос,
В очереди есть постоянно какие то данные.
Мы можем сделать такое условие - в очереди за Х минут хоть раз должно быть 0 сообщений ?

[Kos]

Появился вопрос,
В очереди есть постоянно какие то данные.
Мы можем сделать такое условие - в очереди за Х минут хоть раз должно быть 0 сообщений ?

Воспользуйтесь триггерной функцией count().