Зависимость триггеров

[jet_one]

У меня есть триггер, который, если получает данные срабатывает и висит 5 минут, если за этот промежуток времени новых данных не было уведомление исчезает, если получил, продолжает висеть. Так вот, необходимо создать еще один триггер, уже с другой степенью "Важности", который будет срабатывать, если первый триггер висит больше 30 минут(например).
P.s при создании триггера есть вкладка "Зависимости", но с чем ее есть, я так и не понял.

[yukra]

У меня есть триггер, который, если получает данные срабатывает и висит 5 минут, если за этот промежуток времени новых данных не было уведомление исчезает, если получил, продолжает висеть. Так вот, необходимо создать еще один триггер, уже с другой степенью "Важности", который будет срабатывать, если первый триггер висит больше 30 минут(например).
P.s при создании триггера есть вкладка "Зависимости", но с чем ее есть, я так и не понял.

Зависимости как ни странно описаны в документации:


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

Например есть 2 триггера "Свободного места на диске меньше 10%" и "... меньше 5%".
На сервере осталось условно говоря 4%. Согласитесь что особого смысла показывать оператору оба триггера нет, потому что и так очевидно, что если "меньше 5%", то это значит что и "меньше 10%". Поэтому лишнее можно скрыть через зависимости.

Второй момент: триггеры не могут срабатывать на основе других триггеров, только на основании айтемов. То есть нельзя сказать "Если триггер А висит больше 30 минут, то включи триггер Б". Принципиально нельзя. Только "включи триггер Б, если у нас такие-то данные.

Я не знаю что у вас там за айтемы и триггеры, но по предполагаю что у вас там или snmp-трап, или обычный траппер, с какими-то данными, и триггер "За последние 5 минут пришли данные" в стиле "X.nodata(300)=0".
Я не знаю "простого" способа сделать второй триггер так, как вы описали, но вижу аналог, который вам возможно подойдет (вы же не написали какую практическую задачу пытаетесь решить):
Триггер "X.count(1800)>=6" (1800 - секунд в 30 минутах, 6 - колво пятиминутных интервалов в 30 минутах). Но этот триггер сработает немного не так, как вы хотите, он сработает если за последние 30 минут прилетит 6 или больше значений ... или за последние 20 минут ... или за 10 секунд., но зато формула простая.

Сложная формула: "X.count(300)>=1 AND X.count(300,,,300)>=1 AND ... AND X.count(300,,,1500)>=0". В данном случае используется та же функция count, но с необязательным четвертым параметром "сдвиг по времени".

Подробней смотрите описание функций триггеров в документации

Зы мне сложная формула не нравиться, я не стал бы ее использовать. Во первых легко ошибиться и получить триггер, который показывает не то, что вы ожидаете, во вторых я не уверен что все будет идеально работать и будет проблемы в стиле "разные функции расчитываются в разные моменты времени и на пограничных значениях одно и тоже значение может засчитаться в 2 соседних каунта(или наоборот не засчитаться ни в один". Ну и в третьих я не фанат использование трапперов для критичных триггеров, ибо принципиально нельзя доказать "это у нас с системой все ок и поэтому трапперов нет" или "траппер недошел из-за высокой нагрузки\ошибок на интерфейсе, падение сети, etc", поэтому все критические значения я предпочитаю получать постоянно в виде цифером и обрабатывать сразу функциями .last, .min, .max и avg, а в случае пропуска двух интервалов опроса (который как правило у меня 60-90 секунд) выкидывать триггер по nodata, но это уже моя личная политика ведения мониторинга, вы можете делать так, как вам кажется более удобным в вашем случае.

[Semiadmin]

Если второй триггер - не самоцель, а средство отправить оповещение другой группе людей или запустить некий скрипт, то можно использовать эскалации https://www.zabbix.com/documentation...on/escalations

[jet_one]

Зависимости как ни странно описаны в документации:


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

Например есть 2 триггера "Свободного места на диске меньше 10%" и "... меньше 5%".
На сервере осталось условно говоря 4%. Согласитесь что особого смысла показывать оператору оба триггера нет, потому что и так очевидно, что если "меньше 5%", то это значит что и "меньше 10%". Поэтому лишнее можно скрыть через зависимости.

Второй момент: триггеры не могут срабатывать на основе других триггеров, только на основании айтемов. То есть нельзя сказать "Если триггер А висит больше 30 минут, то включи триггер Б". Принципиально нельзя. Только "включи триггер Б, если у нас такие-то данные.

Я не знаю что у вас там за айтемы и триггеры, но по предполагаю что у вас там или snmp-трап, или обычный траппер, с какими-то данными, и триггер "За последние 5 минут пришли данные" в стиле "x.nodata(300)=0".
Я не знаю "простого" способа сделать второй триггер так, как вы описали, но вижу аналог, который вам возможно подойдет (вы же не написали какую практическую задачу пытаетесь решить):
Триггер "x.count(1800)>=6" (1800 - секунд в 30 минутах, 6 - колво пятиминутных интервалов в 30 минутах). Но этот триггер сработает немного не так, как вы хотите, он сработает если за последние 30 минут прилетит 6 или больше значений ... или за последние 20 минут ... или за 10 секунд., но зато формула простая.

Сложная формула: "x.count(300)>=1 and x.count(300,,,300)>=1 and ... And x.count(300,,,1500)>=0". В данном случае используется та же функция count, но с необязательным четвертым параметром "сдвиг по времени".

Подробней смотрите описание функций триггеров в документации

Зы мне сложная формула не нравиться, я не стал бы ее использовать. Во первых легко ошибиться и получить триггер, который показывает не то, что вы ожидаете, во вторых я не уверен что все будет идеально работать и будет проблемы в стиле "разные функции расчитываются в разные моменты времени и на пограничных значениях одно и тоже значение может засчитаться в 2 соседних каунта(или наоборот не засчитаться ни в один". Ну и в третьих я не фанат использование трапперов для критичных триггеров, ибо принципиально нельзя доказать "это у нас с системой все ок и поэтому трапперов нет" или "траппер недошел из-за высокой нагрузки\ошибок на интерфейсе, падение сети, etc", поэтому все критические значения я предпочитаю получать постоянно в виде цифером и обрабатывать сразу функциями .last, .min, .max и avg, а в случае пропуска двух интервалов опроса (который как правило у меня 60-90 секунд) выкидывать триггер по nodata, но это уже моя личная политика ведения мониторинга, вы можете делать так, как вам кажется более удобным в вашем случае.

Есть триггер степенью важности "не классифицировано", который при вводе неверного пароль на сервер ругается и висит 5 минут, если ошибка не повторится. Если идет перебор, но он висит n кол-во времени. Ставить степень важность "высокая" смысла нет, ибо при ошибке обычного пользователя сразу будет ругаться. Хотелось сделать, чтоб если висит 30 минут, уже всплывал другой триггер с степенью важности "высокая". Но вы сказали что так нельзя, как я понял.
Тогда другой вопрос. Можно ли сделать так, чтоб триггер ругался только тогда, если за последние 30 минут было получено n сообщений. Где n я указываю количество сообщений.

[yukra]

Есть триггер степенью важности "не классифицировано", который при вводе неверного пароль на сервер ругается и висит 5 минут, если ошибка не повторится. Если идет перебор, но он висит n кол-во времени. Ставить степень важность "высокая" смысла нет, ибо при ошибке обычного пользователя сразу будет ругаться. Хотелось сделать, чтоб если висит 30 минут, уже всплывал другой триггер с степенью важности "высокая". Но вы сказали что так нельзя, как я понял.
Тогда другой вопрос. Можно ли сделать так, чтоб триггер ругался только тогда, если за последние 30 минут было получено n сообщений. Где n я указываю количество сообщений.

Да, можно. Ссылка на документацию выше, функция count подойдет.