Как убрать лишние оповещения?

[xeonkeeper]

День добрый!
Использую мониторинг сетевого оборудования с использованием ping.
Соответственно создал три триггера с разными Severity.

{c1811Zaharova:icmppingloss[].avg(600)}>95
{c1811Zaharova:icmppingloss[].avg(1200)}>95
{c1811Zaharova:icmppingloss[].avg(2400)}>95

Но при пропадании пинга на 600 секунд соответственно высвечивается первое оповещение, при пропадании на 1200 второе и тд. И они показываются все вместе.

А как сделать так, чтобы в Last issues отображалось только последнее (более важное) оповещение?

[Jimson]

через зависимости тригеров, но вообще странные тригеры у тебя, ты хочешь что бы "важность" поднималась со временем?

[_AlekseY_]

Скорее всего да.

Я тоже так организовал у себя. 2 минутки без связи терпим, на дашборде показываем. Через 5 уже начинаем рассылать письмена и смски.

Пойду передалаю на зависимости тригеров Спасибо за совет.

[xeonkeeper]

через зависимости тригеров, но вообще странные тригеры у тебя, ты хочешь что бы "важность" поднималась со временем?

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

[_AlekseY_]

Подскажите, пожалуйста, где я ошибся.

Есть два триггера.
1. Предупреждение. Узел {HOST.NAME} уже две минуты как недоступен {Template Ping:icmpping[,5,,,].max(120)}=0
2. Высокая. АХТУНГ!!! {HOST.NAME} без связи уже 5 минут!!!
Зависит от :
Template Ping : Узел {HOST.NAME} уже две минуты как недоступен {Template Ping:icmpping[,5,,,].max(300)}=0

Т.е., если я правильно понимаю, второй тригер должен показываться только после первого. При этом первоее сообщение пропадёт. Но первое сообщение на дашборде болтается уже 23 минуты, а второе никак не показывается.

[Jimson]

Не правильно. В вашем случае первый тригер, с меньшей важностью, должен зависеть от второго, который с большей важностью. В этом случае зависимый тригер не должен показываться с того момента как сработает "главный" тригер. Но не факт, надо проверять. В любом случае задуманное поведение тригеров слишком спорное на мой взгляд, забикс таки не трекерная система где запросы с течением времени "всплывают" как более важные, у нас nms (аларминг): если у нас скопытился сервер, то это одинаково важно как сегодня, так и завтра.

[sergo]

зависимости вообще работают несколько криво (либо я чего-то недопонимаю), в частности как пример стоит три тригера на оповещение по отжираемуму свопу <75%, <50%, <25% (50 зависит от 25, 75 зависит от 50 и 25)
исли в теченни 1 проверки своп сожрется со 100% свободного пространства до 20%. сработают все три тригера в одну секунду, и придет все три оповещения

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

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

[Jimson]

зависимости вообще работают несколько криво (либо я чего-то недопонимаю), в частности как пример стоит три тригера на оповещение по отжираемуму свопу <75%, <50%, <25% (50 зависит от 25, 75 зависит от 50 и 25)
исли в теченни 1 проверки своп сожрется со 100% свободного пространства до 20%. сработают все три тригера в одну секунду, и придет все три оповещения

"<25%" это что ? занято меньше 25% или осталось свободно меньше 25%?
если первое, то опять же зависимости не правильные, зависимость должна быть "менее важный" -> "более важный", т.о.

25% -> 50% -> 75%

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

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

Ну тут два варианта, или мало таки насилуют, или тебе нравиться
Ты криво сделал тригер доступность узла, тригеры без "hysteresis" (http://www.zabbix.com/documentation/...ers/expression) как бы "ниочень".

Во первых даже срабатывание тригера в некоторых случаях должно быть по min/max/avg за некий промежуток времени, для примера если тригер срабоатывает по icmpping[], иначе будут ложные срабатывания, а если тригер таки сработал, ну скажем по условию icmpping[].min(60) = 1, то вернуться в нормальное состояние он должен по условию icmpping[].max(120) = 0. Hysteresis даст тебе запас по времени, когда хост А уже работает, но тригер еще блокирует срабатывание зависимых тригеров.

[sergo]

"<25%" это что ? занято меньше 25% или осталось свободно меньше 25%?

свободно имеется ввиду, там написано это даже)

Ну тут два варианта, или мало таки насилуют, или тебе нравиться

насилуют достаточно, выходит что нравится :d

видиш ли какая штука, руководитель у меня достаточно педантичный человек и ему очень важно знать когда что происходит вплоть до секунд, посему такое решение:

по условию icmpping[].min(60) = 1, то вернуться в нормальное состояние он должен по условию icmpping[].max(120) = 0

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

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

[Jimson]

Может я чего то не понимаю, но если нужна точность до долей секунды в информировании о том что сервер упал или поднялся, то NMS тут мало чем поможет. Догадываюсь что подобное нужно в системах управления ядерными реакторами, но мне почему то кажется что забикс там в качестве системы мониторинга даже не рассматривается, так же как и HP OpenView Network Node Manager.

[sergo]

Может я чего то не понимаю, но если нужна точность до долей секунды в информировании о том что сервер упал или поднялся, то nms тут мало чем поможет. Догадываюсь что подобное нужно в системах управления ядерными реакторами, но мне почему то кажется что забикс там в качестве системы мониторинга даже не рассматривается, так же как и hp openview network node manager.

ну доли секунд не важны, но точность того что за чем и когда именно к моей печали важна ну к примеру при распределенном ддосе ресурса на два десятка фронтендов, очень важно в какой момент времени определенные метрики срабатывают на различных узлах отвечающих за отказоустойчивость, тяжело объяснить специфику, но еслиб была возможность выставлять приоритеты на проверку одной метрики перед другой, и зависимости работали бы логично (не претендую на оптимальность собственной логики :d), самонаписания обвеса заббикса уменьшелось бы процентов на 90%

да и опять таки, в случае описанном выше рестарта сервера, больше играет вопрос раздражения, ибо получить в 3 часа ночи вместо 1 смс-ки три десятка.... очень негативно сказывается на сне и карме исполнителя