Кто постоянно работает с 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% коридор, который не только предотвращает флаппинг триггера, но и защищает нас от иллюзии ложного восстановления, когда триггер перешел в состояние ОК, но значения остались близки к критическим.
Рекомендуем настроить подобный гистерезис для всех триггеров, имеющих критическое значение для системы, где мы должны быть твердо уверенны, что проблема действительно ушла, а не затаилась на время.