А в теле как?

Поправьте меня, но на данный момент задача генерации _уникальных_ событий по определенной строке в логе - нерешаема только внутренними механизмами zabbix, Также как и реакция на однотипные SNMP трапы в виде отдельных событий на каждый трап (без дублирования)

Утречка. Раньше такого не было, в новых версиях куча информационных триггеров сама не закрывается, внутри написано “Ack to close”. Никого больше не напрягает? Мне вот, как тому, кто настраивает мониторинг, совсем не хочется ходить и закрывать алерты на проде. Да и рассказывать раз в полгода тем, кто обновляет операционки, как это делать — тоже. Понимаю, что я волен делать что хочу и как хочу, но стоковые триггеры на то и стоковые, чтобы удовлетворять большинство. А меньшинство — может и кастомизировать. Вот хочу понять, я один такой, кому неудобно?

Имхо, есть 2 разных случая:
1. Метрика поллится и триггер основан на оперативном ее значении. Такие триггеры закрываются по невыполнению условия в проблеме.
2. Метрика поступает на сервер в произвольное время. Примеры: логи, трапы. Триггеры на основе этих метрик могут быть закрыты сразу после срабатывания

Например, у нас мало именно серверов, а рабочие станции мы не мониторим.

Основной объем - это кастомные проверки (скрипты, http, трапы).

Соответственно, не гаснущее уведомление о смене версии - и не напрягает, и вроде даже полезно.

Решаема. Критерий уникальности в тег, и локальная корреляция

я забыл дополнить свой пример еще одним требованием: закрытие событий по таймауту. Сейчас: минимально в течение 30сек.

ок, а вот тут мы и натыкаемся на дублирование событий при срабатывании nodata()

Вопрос к разработчикам. Когда в прототипы узлов сети теги завезут?

Завезли уже

В какой версии? В 5.0.3 нету

Через макрос {host:key.func(param)}. Но посчитано будет не на момент срабатывания триггера, а на момент формирования оповещения.

На разные события? Клади критерий уникальности в тег