Помогите понять корелляции

[Victor Vislobokov]

Привет всему честному люду!

Почитал доку, но что-то как-то непонятно! Сложно как-то всё, мутно. Может кто-то из мэтров окажет любезность и портит на меня минут 10-15 времени, чтобы на примере пояснить как это работает? Будут очень благодарен.

В общем чего хочется. Есть некий узел, на котором находится zabbix proxy и zabbix agent, назовём его proxy. Есть другие узлы, которые мониторятся через этот, заданный прокси, например web1, web2. Хочу, в случае отказа узла proxy увидеть только сработавший триггер "zabbix agent не отвечает" для proxy, а не по всем узлам, которые находятся за ним. Если кто знаком с nagios, то совершенно типичная для него схема с parent: для web1 и web2 узел proxy является родителем, если родитель в состоянии "host down" ошибки по узлам, для которых он является родителем не показываются.

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

[max.ch.88]

Клонируй из Template zabbix agent новый шаблон и сделай в нем зависимость триггера недоступности агента от триггера недоступности агента на прокси. Новый шаблон повесь на все хосты за прокси вместо штатного.

[Victor Vislobokov]

Так, можно сделать, но это касается лишь срабатывания триггеров о недоступности Zabbix Agent. А у кроме Zabbix Agent у меня ещё там мониторится чёртова туча всего, что начнёт орать "нет данных". Конечно, можно и для этих проверок назначить зависимости, но это слишком много ручной работы, если у меня десятки хостов за прокси. Неужели нет какого-то более рациоанального способа?

[max.ch.88]

Я другого способа не знаю. И не очень представляю зачем может быть много триггеров с функцией nodata(). Сам использую такие триггеры для оборудования, опрашиваемого только по SNMP. Одного триггера на хост достаточно и его легко привязать к триггеру недоступности прокси.

[Victor Vislobokov]

Да пожалуй надо данные от любой службы проверять на nodata() иначе можно получить дырку от бублика вместо мониторинга. Например проверка веб-страницы. Бывают ооооочень долгие ответы, а это тоже ошибка как не крути. Результат вернёт пусто, что ни есть результат. Если это не отловить - можно проворонить перенагрузку на сервере, который отдаёт веб-страницу. Чем больше служб мониторится, тем больше подобных вещей, а служб тут у меня море: memcached (который редко, но бывает зависает), redis, rabbitmq, mysql, и т.д. и т.п. На каждый чих такие зависимости ручками делать - задолбаешься.

[Semiadmin]

Например проверка веб-страницы. Бывают ооооочень долгие ответы, а это тоже ошибка как не крути. Результат вернёт пусто, что ни есть результат.

Если речь про стандартный заббиксовский веб-мониторинг, то там действительно в свежих версиях пропуск значений вместо Response code или Response time в случае таймаута, но Failed step возвращается исправно.

[Victor Vislobokov]

Нет, не про него. Стандартный веб-мониторинг не даёт временных метрик и много чего другого