Только одно уведомление при срабатывании триггера при цепочке хостов.

[ktulxu123]

Читал форум, до конца так и не понял возможно ли так сделать. Есть оборудование, которое подключено по цепочке. Например SW1 -> SW2 -> SW3 -> Server.

Надо сделать так, чтобы при выходе из строя любого из узлов приходило только одно сообщение на почту. Ведь если не доступен узел SW1 - то зачем уведомлять о недоступности SW2, SW3 и Server. Читал, что можно делать зависимые триггеры, но ведь zabbix то всё равно опрашивает все узлы вне зависимости от триггера.

[Hamardaban]

«Сообщение на почту» - это «уведомление» о «проблеме»
В вашем случае проблемы порождаются триггерами.
Установление зависимости между триггерами позволяет отключить срабатывание «нижележащих» триггеров => проблеммы по ним не генерируются и уведомления не отсылаются.
Но там не всё так просто и есть засады.
Посмотрите также на глобальную корреляцию триггеров.

[ktulxu123]

«Сообщение на почту» - это «уведомление» о «проблеме»
В вашем случае проблемы порождаются триггерами.
Установление зависимости между триггерами позволяет отключить срабатывание «нижележащих» триггеров => проблеммы по ним не генерируются и уведомления не отсылаются.
Но там не всё так просто и есть засады.
Посмотрите также на глобальную корреляцию триггеров.

Ну да, всё верно поняли. А нижележащие триггеры - это триггеры на одном хосте, или с других тоже учитывается? Ведь что может случиться. Хост не доступен (SW3). Триггер должен срабатывать, или ждать пока вышестоящий (SW2) не станет недоступный? А если он исправен - уведомление о проблеме придёт или нет? А если не доступны оба хоста, но заббикс опросил сначала зависимый (SW3), он не доступен, а потом вышестоящий хост (SW2)? Сработает ли триггер у зависимого хоста (SW3)?

[MikeTk]

Как таковое решение вашей проблемы не лежит на поверхности. Об этом уже много раз говорилось, но похоже ситуация с места не сдвинится. Есть еще более сложный пример, когда есть резервные каналы. Это настроить будет совсем не просто. Но это и решение проблемы. Когда есть резервы, понимание того, какая часть сети упала, намного важнее. В вашем же случае, рекомендую оповещение сделать только на конечных серверах. А вот установление причины уже глазами искать в заббиксе. Я когда переходил с Nagios, тоже не мог понять, почему нет понятия родителя. Но автор сказал: "потому что", с тех пор я больше этим вопрососм не задаюсь.

[ktulxu123]

Как таковое решение вашей проблемы не лежит на поверхности. Об этом уже много раз говорилось, но похоже ситуация с места не сдвинится. Есть еще более сложный пример, когда есть резервные каналы. Это настроить будет совсем не просто. Но это и решение проблемы. Когда есть резервы, понимание того, какая часть сети упала, намного важнее. В вашем же случае, рекомендую оповещение сделать только на конечных серверах. А вот установление причины уже глазами искать в заббиксе. Я когда переходил с Nagios, тоже не мог понять, почему нет понятия родителя. Но автор сказал: "потому что", с тех пор я больше этим вопрососм не задаюсь.

Просто если за родительским коммутатором 50 устройств, которые мониторит zabbix, придёт 50 уведомлений. А мне на надо так. Вот и ищу можно ли как-то это обойти.

А чего ушли с Nagios?

[Hamardaban]

Вам же указали на способ.
Про подробности можно прочитать в документации и статьях в блоге

[kharkov_max]

Как то настраивал зависимые тригеры на более старых версиях zabbix, так вот из опыта.
К примеру есть 3 зависимых узла и нам их нужно пинговать:

zabbix_server->1->2->3

Первый пингуем 15сек, второй 35 сек, третий 80 сек
Т.е. каждый следующий узел должен мониториться в 2-2.5 раза медленнее чем предыдущий в цепочке.
Тогда зависимые триггеры отрабатывают как часы и как результат вы увидите только проблему на узле 1 и не получите по узлам 2 и 3

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

[MikeTk]

А чего ушли с Nagios?

Это было 15 лет назад. На тот момент было несколько автономных инсталляций, мониторящих свою сеть и соседей. Штатно, графики он не рисовал, так же не было веб интерфейса. Все это решалось сторонними приложениями. Оно работало, но было ощущение, что сеть из 20 узлов мониторится отлично, а вот больше, уже решение проблем отнимает много времени.

В заббикс не хватало многих вещей, но постепенно сами задачи да и подход к их решению изменились.

Пожалуй и сейчас не хватает механизма flip-flop, когда триггер прыгает туда сюда. Наггиос просто определял это и сообщения переставали идти. В заббикс же триггер рождает новое событие. Вот тут мне порой не хватает терпения и до разбора с проблемой приходится деактивировать триггер или отключать получения сообщения. Возможно есть решения, как это обойти, но пока они мне не известны. Вот тут был очень рад идеям.