Оповещение с задержкой

[Amicable]

Доброго времени суток. Есть ряд роутеров, которые монитоятся простой проверкой icmpping[,4]. Для этой проверки создал триггер:
{Template SNMP Mikrotik:icmpping[,4].count(3m,0)}>5
Как я понимаю, что если в течении 3 минут пропадут 5 пакетов, то присылать смс. Вероятно есть более правильное решение, так как в моем случае смс приходит сразу же. А когда провайдер начинает флапать, в ночи раздается трель смсок) Подскажите как правильней реализовать, отправку оповещения с задержкой?

[Kos]

Для этой проверки создал триггер:
{Template SNMP Mikrotik:icmpping[,4].count(3m,0)}>5
Как я понимаю, что если в течении 3 минут пропадут 5 пакетов, то присылать смс.

1) не совсем так. Не "в течении 3 минут пропадут 5 пакетов", а "в течении 3 минут будет более пяти неуспешных проверок". В Вашем случае одна проверка - это 4 пинга подряд (вернётся ноль, если не придёт ни одного ответа).
2) какой у Вас интервал между проверками?
3) что видно в Latest Data для данного элемента данных?

А когда провайдер начинает флапать, в ночи раздается трель смсок

А что именно Вы хотите? Попробуйте поставить задачу поточнее.

[Amicable]

Интервал раз в минуту.
В latest data = 1.

А что именно Вы хотите? Попробуйте поставить задачу поточнее.

Микротики пингуются по локальным адресам. Если адрес не доступен 3 минуты, присылать оповещение.

[Kos]

Интервал раз в минуту.

Если у Вас интервал опроса одна минута, то тогда я вообще не понимаю, как у Вас срабатывает триггер

{Template SNMP Mikrotik:icmpping[,4].count(3m,0)}>5

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

В latest data = 1.

А остальные данные? Если выбрать ряд значений за тот период, когда было срабатывание триггера, то что там есть?

Микротики пингуются по локальным адресам. Если адрес не доступен 3 минуты, присылать оповещение.

Да ,вроде, правильно пытаетесь делать. Только ощущение, что либо что-то недоговариваете, либо что-то не так описываете

Можно ещё попробовать переформулировать условие триггера, заменив временной параметр на явное количество проб:

{Template SNMP Mikrotik:icmpping[,4].count(#5,0)}>3

"если из последних пяти проб больше трёх были неуспешными - то тревога"

[rough-84]

Я бы сделал
{Template SNMP Mikrotik:icmpping[,4].min(#3)}>0
Те же яйца, только в профиль, сработает когда 3 проверки подряд дадут "1"

[Kos]

icmpping при нормальных условиях возвращает единицу; ловить надо, когда НЕ пингуется. Т.е. тогда уж должно быть наоборот:

{Template SNMP Mikrotik:icmpping[,4].max(#3)}=0

если последние три значения - одни нули.

Но, по сравнению с count(), такой подход хуже работает в условиях "дребезга". Т.е. когда, например, сеть фактически "лежит" и из 10 пингов проходит один-два, такой триггер будет постоянно переключаться из одного положения в другое, давая множество оповещений. С count-ом можно настроить гибче.

[Amicable]

Я бы сделал
{Template SNMP Mikrotik:icmpping[,4].min(#3)}>0
Те же яйца, только в профиль, сработает когда 3 проверки подряд дадут "1"

1 это значит пинг есть и все хорошо. Тогда наоборот наверно меньше 1.

Если у Вас интервал опроса одна минута, то тогда я вообще не понимаю, как у Вас срабатывает триггер

слукавил случайно. интервал, раз в 30 секунд.

В latest data, для этого элемента только 1, или 0, в момент падения.

"если из последних пяти проб больше трёх были неуспешными - то тревога"

{Template SNMP Mikrotik:icmpping[,4].count(#6,0)}>3 , тогда наверно так можно по пробовать. 6 попыток это три минуты.

[rough-84]

icmpping при нормальных условиях возвращает единицу; ловить надо, когда НЕ пингуется. Т.е. тогда уж должно быть наоборот:

{Template SNMP Mikrotik:icmpping[,4].max(#3)}=0

если последние три значения - одни нули.

Но, по сравнению с count(), такой подход хуже работает в условиях "дребезга". Т.е. когда, например, сеть фактически "лежит" и из 10 пингов проходит один-два, такой триггер будет постоянно переключаться из одного положения в другое, давая множество оповещений. С count-ом можно настроить гибче.

Ну да, тогда просто изменить:

({TRIGGER.VALUE}=0 and {Template SNMP Mikrotik:icmpping[,4].max(#3)}=0) or
({TRIGGER.VALUE}=1 and {Template SNMP Mikrotik:icmpping[,4].min(#3)}>0)

При таком варианте сработает когда подряд 3 нуля и выйдет из состояния проблема когда подряд 3 единицы, вроде правильно, давно уже гистериоз не использовал...
Вариаций множество, мне ближе функции max, min.

[Kos]

Ну да, тогда просто изменить:

({TRIGGER.VALUE}=0 and {Template SNMP Mikrotik:icmpping[,4].max(#3)}=0) or
({TRIGGER.VALUE}=1 and {Template SNMP Mikrotik:icmpping[,4].max(#3)}>0)

Вариаций множество, мне ближе функции max, min.

Да, согласен - так тоже можно.
Только в конце второй строчки вместо max(#3)}>0 должно быть что-то другое, например, min(#3)}=0 (удерживать сработавший триггер, пока не получим три успешных пинга подряд).

[rough-84]

Да, согласен - так тоже можно.
Только в конце второй строчки вместо max(#3)}>0 должно быть что-то другое, например, min(#3)}=0 (удерживать сработавший триггер, пока не получим три успешных пинга подряд).

Во, точно спасибо, напомнил логику гистериоза.

[Amicable]

({TRIGGER.VALUE}=0&{Template SNMP Mikrotik:icmpping[,4].max(#3)}=0)|({TRIGGER.VALUE}=1&{Template SNMP Mikrotik:icmpping[,4].min(#3)}=0)

Если учесть, что проверка каждые 30 секунд, то триггер сработает спустя 90 секунд.
rough-84,Kos, cпасибо за помощь. По пробую так.

[aib]

Одно маленькое замечание - если интервал проверки 30 секунд, то это еще не значит, что за 90 секунд у вас будет 4 проверки. Интервал проверки "плавает" около заданного (рекомендованного) времени.

[Amicable]

Одно маленькое замечание - если интервал проверки 30 секунд, то это еще не значит, что за 90 секунд у вас будет 4 проверки. Интервал проверки "плавает" около заданного (рекомендованного) времени.

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