Разработчикам: макросы типа {trigger.unack}
Уважаемые разработчики Zabbix!
Пишу вам, поскольку согласно странице http://www.zabbix.com/documentation/.../config/macros у мне есть устойчивое ощущение что в 1.8.3 мы (я не один такой) не получим то, что очень бы хотелось иметь...
Суть проблемы (это уже обсуждалось, но я вкратце вернусь к этому вопросу): в случае работы с Windows EventLog'ами очень хочется иметь возможность делать Ack на эвенты, висящие в дашборде.
Пример (как работает сейчас):
- на сервере "сервер1" включено слежение за eventlog'ом Application: eventlog[Application,,Error,,,200]
- любая возникшая запись об ошибке передаётся на сервер Zabbix, где её встречает триггер: {Template_CROS_Windows_EventLogs:eventlog[Application,,Error,,,200].logseverity(4)}=4&{Template_CROS_Windows_EventLog s:eventlog[Application,,Error,,,200].nodata(30)}=0
Это позволяет автоматически обрабатывать поступающие ошибки (выполняя на них Action). Но для меня например это НЕ ПРАВИЛЬНО! Ведь с таким триггером все поступающие сообщения об ошибках просто сгенерируют почту-извещение (согласно настройкам) и всё, вроде как проблемы нет... В дашборде пусто а мыло можно и удалить...
А что же нужно?
Чтобы все эвенты (Issue) висели в дашборде (в Last 20 issues) ДО ТЕХ ПОР, пока администратор их в явном виде не Ack'нет.
Т.е. выражение триггера в этом случае могло бы иметь вид типа:
{Template_CROS_Windows_EventLogs:eventlog[Application,,Error,,,200].logseverity(4)}=4&{TRIGGER.EVENTS.UNACK}#0
И в принципе, эту методу можно было бы применять в каких угодно случаях, когда проверяемый хост\объект\дачтоугодно не имеет чёткого разделения по состояниям типа OK и PROBLEM.
Согласно документации, следующие макросы в 1.8.3 НЕЛЬЗЯ будет использовать в выражениях триггеров (Trigger expressions):
{TRIGGER.PROBLEM.EVENTS.PROBLEM.UNACK}
{TRIGGER.EVENTS.PROBLEM.UNACK}
{TRIGGER.EVENTS.UNACK}
Но поверьте, этого очень бы хотелось... Это очень нужно.
С уважением и огромной надеждой жду вашего ответа...
Пишу вам, поскольку согласно странице http://www.zabbix.com/documentation/.../config/macros у мне есть устойчивое ощущение что в 1.8.3 мы (я не один такой) не получим то, что очень бы хотелось иметь...
Суть проблемы (это уже обсуждалось, но я вкратце вернусь к этому вопросу): в случае работы с Windows EventLog'ами очень хочется иметь возможность делать Ack на эвенты, висящие в дашборде.
Пример (как работает сейчас):
- на сервере "сервер1" включено слежение за eventlog'ом Application: eventlog[Application,,Error,,,200]
- любая возникшая запись об ошибке передаётся на сервер Zabbix, где её встречает триггер: {Template_CROS_Windows_EventLogs:eventlog[Application,,Error,,,200].logseverity(4)}=4&{Template_CROS_Windows_EventLog s:eventlog[Application,,Error,,,200].nodata(30)}=0
Это позволяет автоматически обрабатывать поступающие ошибки (выполняя на них Action). Но для меня например это НЕ ПРАВИЛЬНО! Ведь с таким триггером все поступающие сообщения об ошибках просто сгенерируют почту-извещение (согласно настройкам) и всё, вроде как проблемы нет... В дашборде пусто а мыло можно и удалить...
А что же нужно?
Чтобы все эвенты (Issue) висели в дашборде (в Last 20 issues) ДО ТЕХ ПОР, пока администратор их в явном виде не Ack'нет.
Т.е. выражение триггера в этом случае могло бы иметь вид типа:
{Template_CROS_Windows_EventLogs:eventlog[Application,,Error,,,200].logseverity(4)}=4&{TRIGGER.EVENTS.UNACK}#0
И в принципе, эту методу можно было бы применять в каких угодно случаях, когда проверяемый хост\объект\дачтоугодно не имеет чёткого разделения по состояниям типа OK и PROBLEM.
Согласно документации, следующие макросы в 1.8.3 НЕЛЬЗЯ будет использовать в выражениях триггеров (Trigger expressions):
{TRIGGER.PROBLEM.EVENTS.PROBLEM.UNACK}
{TRIGGER.EVENTS.PROBLEM.UNACK}
{TRIGGER.EVENTS.UNACK}
Но поверьте, этого очень бы хотелось... Это очень нужно.
С уважением и огромной надеждой жду вашего ответа...
.
Comment