Разное время срабатывания тригера и опов

[WALRUS]

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

Пытался сделать следующее. разделить активность на два тригера.
1. проверяет все подряд

{PingLos5s:icmpping[].last(0)}=0

2. как раз должен срабатывать только через некоторое время.
пробовал разные варианты.

	{TRIGGER.VALUE}=0&{PingLos5s:icmpping[].last(20)}=0|
                {TRIGGER.VALUE}=1&{PingLos5s:icmpping[].last(0)}=1

или

{PingLos5s:icmpping[].count(#10,0}<5

Толком ничего не работает.
Может я что то не так делаю? и есть другой способ сделать необходимое?

[sadman]

Назначьте в Action оповещение по e-mail на шаг N, где N = желаемое время / длительность шага (Default operation step duration).

[WALRUS]

Назначьте в action оповещение по e-mail на шаг n, где n = желаемое время / длительность шага (default operation step duration).

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

[sadman]

Показывайте скриншот Действия-> Операции в открытом виде

[Kos]

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

Тут смешивается сразу несколько понятий, либо пропущена середина. Между "падением узла" и "отсылкой оповещения" есть ещё, как минимум два промежуточных шага: 1) срабатывание триггера; 2) работа механизма эскалаций.

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

{PingLos5s:icmpping[].last(0)}=0

(который срабатывает при первом же неуспешном пинге) можно использовать

{PingLos5s:icmpping[].max(10)}=0

(все последние 10 пингов неуспешны) или

{PingLos5s:icmpping[].count(#10,0)}>5

(из десяти последних пингов неуспешны больше половины).

В этом случае "при падении узла" триггер сработает на "сразу", а через какое-то время, когда удостоверится, что проблема таки устойчиво есть.

Во-вторых, как справедливо заметил sadman, в свойствах действий (Actions) настраивается, что же и в какой момент делать после срабатывания триггера. Обычно выполняется шаг 1 (т.е. сразу же после того, как триггер перешёл в состояние "Проблема"), но никто не мешает не использовать первый шаг, а начать реальные действия (отсылку оповещений) только со второго шага, выставив при этом нужную продолжительность шагов.

[WALRUS]

Тут смешивается сразу несколько понятий, либо пропущена середина. Между "падением узла" и "отсылкой оповещения" есть ещё, как минимум два промежуточных шага: 1) срабатывание триггера; 2) работа механизма эскалаций.

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

{PingLos5s:icmpping[].last(0)}=0

(который срабатывает при первом же неуспешном пинге) можно использовать

{PingLos5s:icmpping[].max(10)}=0

(все последние 10 пингов неуспешны) или

{PingLos5s:icmpping[].count(#10,0)}>5

(из десяти последних пингов неуспешны больше половины).

В этом случае "при падении узла" триггер сработает на "сразу", а через какое-то время, когда удостоверится, что проблема таки устойчиво есть.

Во-вторых, как справедливо заметил sadman, в свойствах действий (Actions) настраивается, что же и в какой момент делать после срабатывания триггера. Обычно выполняется шаг 1 (т.е. сразу же после того, как триггер перешёл в состояние "Проблема"), но никто не мешает не использовать первый шаг, а начать реальные действия (отсылку оповещений) только со второго шага, выставив при этом нужную продолжительность шагов.

Понял ошибку что указывал длительность шага не там где нужно.
Переделал. В Действия - операции Сделал два шага. первый тупо ждет 200 секунд(тестовое значение) второй уже отправка сообщения. Только проблема в том что, да он теперь отправляет с задержкой, но все равно отправляет. а мне надо грубо говоря так. упал хост. лежал 2 минуты и поднялся, что бы такое не присылал. а вот если упал и уже лежит 10 минут тогда надо прислать уведомление что нужно обратить внимание на хост. Сейчас попробую варианты что бы сам тригер не срабатывал при первом же потеряном пинге. Вот эти варианты

{PingLos5s:icmpping[].max(10)}=0

{PingLos5s:icmpping[].count(#10,0)}>5

[WALRUS]

Попробовал по

{PingLos5s:icmpping[].count(#10,0)}>5

да. теперь срабатывает с задержкой как нужно, только вот не возвращается в состояние ОК вообще. хост поднялся, а тригер не ушел.

[Kos]

В Действия - операции Сделал два шага. первый тупо ждет 200 секунд(тестовое значение) второй уже отправка сообщения.

Во-первых, как я писал чуть раньше, шаг №1 ничего не ждёт, он выполняется сразу. На вашем же скриншоте это чётко видно: в графе "Начало в" стоит: "незамедлительно". Во-вторых, вопреки вашим утверждениям, на том же скриншоте видно, что в первом шаге уже настроено действие "Отправлять сообщение...". Наконец, в-третьих, второй шаг (который, судя по вашему скриншоту, должен начать выполняться через 03:20 после срабатывания триггера) будет выполнен только в том случае, если триггер за это время ещё не закроется. Успеет триггер перейти в состояние "ok" - шаг №2 выполняться не будет.

Пример действия, где выполнение начинается со второго шага (выполняется удалённая команда через 5 минут после срабатывания триггера, если он до этого ещё сам не закрылся):

[Kos]

Попробовал по

{pinglos5s:icmpping[].count(#10,0)}>5

да. теперь срабатывает с задержкой как нужно, только вот не возвращается в состояние ОК вообще. хост поднялся, а тригер не ушел.

Логично. Условие такого триггера:

из десяти последних пингов неуспешны больше половины

Когда из десяти последних пингов успешны будут половина или более, тогда он и закроется.

Повторюсь ещё раз:

нужно определить, что для вас считается проблемой

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

[WALRUS]

Логично. Условие такого триггера: Когда из десяти последних пингов успешны будут половина или более, тогда он и закроется.

Повторюсь ещё раз: Другими словами, опишите сначала, когда, по вашему мнению, триггер должен срабатывать, а когда закрываться обратно. Закрываться при первом же успешном пинге - на мой взгляд, неправильно (а вдруг следующий же снова будет неуспешным?); но у вас могут быть свои взгляды, поэтому и начать надо с того, что, по-вашему, "правильно". Под это у писать условие триггера.

Мне надо что бы если хост более 10 минут в дауне то тригер срабатывает. а если например за последние 2 минуты потерь было не более 10% то все ок, отключать тригре.

будет ли верно если вот так написать?

{trigger.value}=0&{pinglos5s:icmpping[].count(#300,0)}>200|
{trigger.value}=1&{pinglos5s:icmpping[].count(#100,0)}<50

[Kos]

Мне надо что бы если хост более 10 минут в дауне то тригер срабатывает. а если например за последние 2 минуты потерь было не более 10% то все ок, отключать тригре.

будет ли верно если вот так написать?

Ну, я не знаю, с каким интервалом у вас делаются проверки. count(#300,...) - это просмотреть 300 последних значений. Без решётки, count(300,...) - это просмотреть значения за последние 5 минут (300 секунд). Но, в любом случае, чтобы сравнивать результат функции count() с чем-то, вам нужно знать, сколько значений вы ожидаете. Например, если интервал опроса 30 секунд, то правильным будет примерно так:

({trigger.value}=0&{pinglos5s:icmpping[].count(#20,0)}=20)    //Переход в состояние PROBLEM: из последних двадцати значений все двадцать - неуспешные
|
({trigger.value}=1&{pinglos5s:icmpping[].count(#4,0)}>1)    //Удержание в состоянии PROBLEM: из последних 4-х значений неуспешны более одного