Всем доброго времени суток.
Не совсем понятно в wiki описана корреляция событий. По правьте меня если я не прав, просто по пробовал, не работает, хочу понять что сделал не так.
С учетом текущих известных проблем
Начнем с начала - есть два типа событий
а) Новое
б) Старое
Не нашел что это значит. То есть нет понимания когда событие становится старым.
Я установил теги на триггер, в моем случае это ICMP пинг. В триггере подключенном к Core Router указан тег ping_core_router, состояние тега {ITEM.LASTVALUE}, которое равно 0 = проблема, 1 = ОК.
Далее я создал множество триггеров ICMP пинг с разным количеством опросов и временем между опросами. При условии что при падении рутера заббикс всегда в два-три раза быстрее узнает о недоступности оного, чем других объектов (смотри выше про известные проблемы). У этих триггеров свои теги, просто схема зависимостей у меня достаточно сложная, но пока хочу разобраться с глубиной в 1.
И так собственно правило кореляции
Если ping_core_router = 0 и (группы хостов), действие - закрыть новое событие.
Идея данной корреляции в том, что бы при падении рутера, не получать тучу сработавших триггеров. При этом не заморачиваясь с зависимостями на уровне триггеров, что просто кошмарно не удобно при большом количестве хостов.
И последнее - если действие уже работает, то есть корреляция срабатывает по тегу триггера: это новое событие или старое? Я предполагал что с текущей корреляцией ко мне придет 1 действие о не доступности рутера, а пришло от всех.
Не совсем понятно в wiki описана корреляция событий. По правьте меня если я не прав, просто по пробовал, не работает, хочу понять что сделал не так.
С учетом текущих известных проблем
Начнем с начала - есть два типа событий
а) Новое
б) Старое
Не нашел что это значит. То есть нет понимания когда событие становится старым.
Я установил теги на триггер, в моем случае это ICMP пинг. В триггере подключенном к Core Router указан тег ping_core_router, состояние тега {ITEM.LASTVALUE}, которое равно 0 = проблема, 1 = ОК.
Далее я создал множество триггеров ICMP пинг с разным количеством опросов и временем между опросами. При условии что при падении рутера заббикс всегда в два-три раза быстрее узнает о недоступности оного, чем других объектов (смотри выше про известные проблемы). У этих триггеров свои теги, просто схема зависимостей у меня достаточно сложная, но пока хочу разобраться с глубиной в 1.
И так собственно правило кореляции
Если ping_core_router = 0 и (группы хостов), действие - закрыть новое событие.
Идея данной корреляции в том, что бы при падении рутера, не получать тучу сработавших триггеров. При этом не заморачиваясь с зависимостями на уровне триггеров, что просто кошмарно не удобно при большом количестве хостов.
И последнее - если действие уже работает, то есть корреляция срабатывает по тегу триггера: это новое событие или старое? Я предполагал что с текущей корреляцией ко мне придет 1 действие о не доступности рутера, а пришло от всех.
Comment