Добавить в корзинуПозвонить
Найти в Дзене

Гистерезис как средство стабилизации триггеров в Zabbix

Кто постоянно работает с Zabbix знает такое явление как дребезг триггеров (или флаппинг), когда контролируемое значение колеблется около значения срабатывания триггера и приводит к постоянному его срабатыванию и восстановлению. Это неприятно, так как приводит к резкому росту количества уведомлений и именно с этим явлением предлагают бороться, но на самом деле проблема лежит глубже, это проблема иллюзии восстановления. О чем это мы? Давайте возьмем для примера триггер High memory utilization, который имеет следующее выражение срабатывания: min(/Linux by Zabbix agent/vm.memory.utilization,5m)>{$MEMORY.UTIL.MAX} Оно означает, что если все значения за последние 5 минут были выше порога, то триггер сработает. Это обусловлено использованием min(), фактически мы берем наименьшее значение за 5 минут и сравниваем с порогом. Поэтому набор значений: 89 90 91 89 92 95 – не сработает, min = 89 а набор: 91 93 95 91 92 94 – сработает, min = 91 При этом фактически ситуация по памяти у нас не

Гистерезис как средство стабилизации триггеров в Zabbix

Кто постоянно работает с Zabbix знает такое явление как дребезг триггеров (или флаппинг), когда контролируемое значение колеблется около значения срабатывания триггера и приводит к постоянному его срабатыванию и восстановлению.

Это неприятно, так как приводит к резкому росту количества уведомлений и именно с этим явлением предлагают бороться, но на самом деле проблема лежит глубже, это проблема иллюзии восстановления.

О чем это мы? Давайте возьмем для примера триггер High memory utilization, который имеет следующее выражение срабатывания:

min(/Linux by Zabbix agent/vm.memory.utilization,5m)>{$MEMORY.UTIL.MAX}

Оно означает, что если все значения за последние 5 минут были выше порога, то триггер сработает. Это обусловлено использованием min(), фактически мы берем наименьшее значение за 5 минут и сравниваем с порогом.

Поэтому набор значений:

89 90 91 89 92 95 – не сработает, min = 89

а набор:

91 93 95 91 92 94 – сработает, min = 91

При этом фактически ситуация по памяти у нас не меняется и триггер или будет постоянно флапать или замолчит, и мы будем уверены, что ситуация выправилась, хотя на самом деле это не так и она продолжает оставаться критичной.

Как этого избежать? Ввести гистерезис, т.е. переводить триггер в состояние восстановления не сразу после того, как выражение срабатывания перестало работать, а с задержкой, когда мы будем уверены, что ситуация действительно нормализировалась.

Примем для этого значения порог срабатывания – 5%, при этом условием восстановления будет то, что за 5 минут ни одно значение не превысит этот порог. Теперь, после срабатывания триггера по памяти (штатное значение 90%) он не перейдет в состояние восстановления до тех пор, пока утилизация памяти стабильно не снизится менее 85%.

Для этого в настройках триггера добавим выражение восстановления и запишем туда следующий текст:

max(/Linux by Zabbix agent/vm.memory.utilization,5m) < ({$MEMORY.UTIL.MAX} - 5)

Обратите внимание, что здесь мы используем не min(), а max(), так как у нас ни одно значение метрики не должно в течении 5 минут превысить пороговое.

Таким образом мы ввели четкий 5% коридор, который не только предотвращает флаппинг триггера, но и защищает нас от иллюзии ложного восстановления, когда триггер перешел в состояние ОК, но значения остались близки к критическим.

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