Агрегированный триггер для агрегации ин&

[therb1]

Добрый вечер коллеги!
Я встал в тупик и если кто то подскажет как лучше реализовать данную задачу был бы очень признателен.
Есть 3 хоста с rabbitmq которые собраны в кластер.

Есть задача мониторить очереди и если на всех трех хостах количество сообщений в одной из очередей больше 5 то присылать оповещение.
Эта часть решена.

Но проблема в том что приходит сразу три письма и смс о том что очередь переполнена, так происходит из за того что триггеры генерируются lld на каждом хосте.

Вопрос:
Как избавиться от лишних смс и писем?

[Semiadmin]

Думаю, вам может помочь айтем типа Aggregate check с функцией grpmin. А уже для него сделать триггер на то, что он >5, и оповещение на этот триггер.

[therb1]

Думаю, вам может помочь айтем типа Aggregate check с функцией grpmin. А уже для него сделать триггер на то, что он >5, и оповещение на этот триггер.

Я думаю это не поможет так как триггер создается тоже прототипом на всех трех нодах.
При этом отдельные триггеры я сделать не могу так как по lld получаю для каких элементов строить триггеры.

[Semiadmin]

Да, вы правы. Тогда могу разве что предложить костыль в виде прямого запроса в базу, считающего, сколько созданных для данной очереди триггеров находятся в состоянии problem. И триггер на то, что результат =3.

[therb1]

Да, вы правы. Тогда могу разве что предложить костыль в виде прямого запроса в базу, считающего, сколько созданных для данной очереди триггеров находятся в состоянии problem. И триггер на то, что результат =3.

Я не совсем понимаю что вы имеете ввиду, можно пример?

[Semiadmin]

Ну, я как-то делал подобный айтем, который считал, сколько на хосте дисков с недостатком места. Айтем типа Database monitor, запрос к БД Zabbix:
SELECT COUNT(triggerid) FROM triggers WHERE triggerid IN (SELECT triggerid FROM functions WHERE itemid IN (SELECT itemid FROM items WHERE hostid IN (SELECT hostid FROM hosts WHERE host="{HOST.NAME}") AND key_ LIKE "vfs.fs.size[_:,pfree]")) AND value=1 AND priority=4
Только в вашем случае надо считать по-другому. Главное, не трогать тяжелые таблицы history, а считать сработавшие триггеры.

[therb1]

Ну, я как-то делал подобный айтем, который считал, сколько на хосте дисков с недостатком места. Айтем типа Database monitor, запрос к БД Zabbix:
SELECT COUNT(triggerid) FROM triggers WHERE triggerid IN (SELECT triggerid FROM functions WHERE itemid IN (SELECT itemid FROM items WHERE hostid IN (SELECT hostid FROM hosts WHERE host="{HOST.NAME}") AND key_ LIKE "vfs.fs.size[_:,pfree]")) AND value=1 AND priority=4
Только в вашем случае надо считать по-другому. Главное, не трогать тяжелые таблицы history, а считать сработавшие триггеры.

Проблема в том что я не знаю названия очередей, они достаются из Rabbitmq, и у нас они динамические. Если брать те которые я получаю в lld все равно будет три срабатывания так как шаблон навешан на три ноды.

[Semiadmin]

Попробовал создать в LLD прототип айтема типа Aggregate check, успешно. Надо только решить, на какой из хостов повесить агрегированные айтемы и триггеры к ним. А лучше - на виртуальный хост, если LLD не через активный агент работает.

[therb1]

Попробовал создать в LLD прототип айтема типа Aggregate check, успешно. Надо только решить, на какой из хостов повесить агрегированные айтемы и триггеры к ним. А лучше - на виртуальный хост, если LLD не через активный агент работает.

А как вы создаете триггеры на айтемы которых нет на этом виртуальном хосте, ведь насколько я понимаю в триггере надо указать элемент имя которого я получаю из lld, а на виртуальном хосте я не получу этих элементов. Я думал о том что бы повесить это все на один хост, но это выглядит очень ненадежно, так как падение одной ноды для меня не критично, а вот падение всего мониторинга из за одной ноды это очень плохо.

[Semiadmin]

Я бы сделал прототип триггера на прототип агрегированного айтема, в том же LLD. В LLD эти айтем и триггер указал бы как Disabled. На виртуальном хосте, на котором будет вестись агрегация, наоборот, сделал бы их enabled, а обычные, неагрегированные - disabled. IP виртуального хоста сделал бы таким же, как у одной из нод, чтобы для него LLD работало, если оно типа "пассивный агент".
P.S. можно сделать 2 разных шаблона, с разными прототипами - для нод и виртуального хоста.

[therb1]

Я бы сделал прототип триггера на прототип агрегированного айтема, в том же lld. В lld эти айтем и триггер указал бы как disabled. На виртуальном хосте, на котором будет вестись агрегация, наоборот, сделал бы их enabled, а обычные, неагрегированные - disabled. Ip виртуального хоста сделал бы таким же, как у одной из нод, чтобы для него lld работало, если оно типа "пассивный агент".
P.s. можно сделать 2 разных шаблона, с разными прототипами - для нод и виртуального хоста.

Спасибо большое за помощь. Решение очень нестабильное получается, я думаю рассмотреть другую систему мониторинга для этих целей.

[Semiadmin]

Честно говоря, единственный потенциальный источник нестабильности, который я здесь вижу - это если упадет та нода, которая будет давать данные lld для агрегированных проверок, и агрегированные айтемы перестанут соответствовать обычным на 2 оставшихся нодах, если там список айтемов обновится. Но думаю, что и эту проблему можно решить при желании.

[therb1]

Честно говоря, единственный потенциальный источник нестабильности, который я здесь вижу - это если упадет та нода, которая будет давать данные lld для агрегированных проверок, и агрегированные айтемы перестанут соответствовать обычным на 2 оставшихся нодах, если там список айтемов обновится. Но думаю, что и эту проблему можно решить при желании.

Я думал о динамической генерации итемов и триггеров с помощью заббикс апи для dummy хоста на котором они бы обрабатывались, но как по мне это уже совсем наркомания какая-то получается.