задачка: зависимости тригеров

[Jimson]

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

Имеется элемент данных, icmppingloss, интервал 60 секунд.
Требуется два триггера:
1) недоступность => avg значение icmppingloss (2 последних значения, например) больше 99
2) потери => любые значения icmppingloss больше 0, но триггер не должен пересекаться с триггером "недоступность"

Есть красивые варианты? Я уже голову сломал

P.S. да, вслед за тем как тригер "недоступность" переходит из состояния FAIL в OK триггер "потери" срабатывать не должен, собственно в этом и вся загвоздка

[inform11]

А чем не нравится, если оба триггера сработают при недоступности?

[inform11]

а если попробовать написать триггер ПОТЕРИ вот так:

{{host:icmppingloss[,10,300,128,1000].last(0)}>50} & {{host:icmppingloss[,10,300,128,1000].last(0)}#100}

а триггер НЕДОСТУПНОСТЬ вот так:

{host:icmppingloss[,10,300,128,1000].last(0)}=100

по-моему логика должна сработать именно па вашей хотелке

[Jimson]

А чем не нравится, если оба триггера сработают при недоступности?

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

слать по 10 пингов с большой задержкой нельзя потому что пингеры не резиновые, прийдется ставить интервалы для таких элементов данных по 10 минут
второй момент, у вас пришло два результата таких проверок, оба на 90%, означает ли это что там было "0 100 100 ... 100 100 0" или там было "80 95 30 98 ...." ? т.о. по сути не ясно потери это или точка отваливалась

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

пока единственным решением является проверки с time_shift, но условия срабатывания получаются очень сложные, надо и проверить факт наличия потерь пакетов и проверить что эти потери небыли 100% непрерывным отрезком (т.е. это небыла недоступность)

[dima_dm]

Просто используйте зависимость триггеров. Т.е. триггер icmppingloss зависит от триггера недоступности хоста.

[inform11]

Просто используйте зависимость триггеров. Т.е. триггер icmppingloss зависит от триггера недоступности хоста.

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

[dima_dm]

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

Эта фича специально для таких случаев сделана
http://www.zabbix.com/documentation/...onfig/triggers
4.12.3. Зависимости триггеров

[Jimson]

Просто используйте зависимость триггеров. Т.е. триггер icmppingloss зависит от триггера недоступности хоста.

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

P.S. доступность в данном случае проверяется по тому же loss, делать же второй элемент данных с большей частотой сбора данных избыточно, вообщем я это все тоже написал выше

[dima_dm]

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

Если Вы используете prev данные, кто мешает продлить состояние хост недоступен на полный интервал получения валидных данных для триггера icmppinglos. т.е. 120, 180 секунд и т.д.?
Пример
{Test:icmpping.last()}=0 | {Test:icmpping.count(180,0)}>1

[inform11]

и вот мы вернулись почти к моему первоначальному варианту - написать триггер посложнее и все

[Jimson]

Если Вы используете prev данные, кто мешает продлить состояние хост недоступен на полный интервал получения валидных данных для триггера icmppinglos. т.е. 120, 180 секунд и т.д.?
Пример
{Test:icmpping.last()}=0 | {Test:icmpping.count(180,0)}>1

был такой вариант в голове, точнее так:

({TRIGGER.VALUE}=0&{icmppingloss[].avg(#2)}>99)|
({TRIGGER.VALUE}=1&{icmppingloss[].avg(#2, 90)}<99)

а на потери просто avg(#2) > 0

но будет срабатывание "потерь" сразу как прийдут первые данные со 100% loss, надо или проверять на потери (last(#1) < 99 & avg(#2) > 0), либо проверять на потери со сдвигом time_shift, а тогда прийдется еще сильнее затягивать по времени "недоступность" (увеличивать time_shift в проверке при trigger.value = 1)

вообщем планировал тестить такой вариант, еще какие то варианты решения будут ?

P.S. даже проще можно наверно, опустить проверку значения тригера на 0, оставить только на 1:
icmppingloss[].avg(#2)}>99 | ({TRIGGER.VALUE}=1&{icmppingloss[].avg(#2, 90)}<99)
где 90 есть полуторный интервал опроса icmppingloss[]