Zabbix без лишних алертов: настройка полезных триггеров

Считать шум измеримой проблемой

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

Перед перенастройкой выгружают события за репрезентативный период и группируют по trigger, host, severity, длительности и числу повторов. Отдельно отмечают события, по которым был инцидент или полезное превентивное действие. Это позволяет исправить несколько самых шумных правил вместо глобального снижения severity.

У каждой категории своя причина: порог около нормального значения, короткий spike, flap сети, неверный nodata, повтор от зависимых узлов, устаревший host или неуместная escalation. Универсальное увеличение периода скрывает часть шума, но одновременно замедляет реальные сигналы.

Отделить сбор данных от решения об аварии

Item должен надёжно собирать наблюдение, trigger expression — интерпретировать его во времени, а action — решать, кого уведомить. Попытка компенсировать шум увеличением update interval item ухудшает графики и диагностику. Обычно данные продолжают собирать достаточно часто, а устойчивость проверяют функциями trigger.

Порог выбирают по физическому смыслу и времени реакции. Для диска полезна комбинация процента, абсолютного остатка и прогноза; для CPU — длительное насыщение, а не один пик; для ошибок интерфейса — скорость прироста, а не накопительный counter. Шаблонный порог переносится через user macros, чтобы исключения были видны на уровне host или template.

Expression документируют operational data и понятным именем. Сообщение «Problem: trigger 18492» заставляет открывать интерфейс, тогда как имя с объектом, значением и длительностью позволяет быстро оценить ситуацию. Не включайте в имя изменчивые данные, если это создаёт множество уникальных сущностей; используйте operational data и event tags.

• Item хранит исходный сигнал с достаточной частотой.
• Trigger использует окно и несколько признаков по необходимости.
• User macro задаёт управляемый порог для класса узлов.
• Tags описывают service, team, scope и environment.
• Action маршрутизирует событие, а не исправляет плохой expression.

Добавить длительность и hysteresis

Функции min, max, avg и count отвечают на разные вопросы. max(/host/key,5m)>80 означает, что хотя бы одно значение было выше 80; min(...,5m)>80 — что все значения окна выше порога; avg сглаживает, но может скрыть короткий критичный пик. Выражение выбирают по механике отказа, а не по привычке.

Hysteresis задаёт разные условия открытия и восстановления. Например, проблема свободного места открывается ниже 10%, а recovery происходит выше 15%. Это предотвращает flap около 10%, но требует реалистичной границы: если очистка обычно возвращает только 12%, событие никогда не закроется.

Для триггеров с recovery expression нужно проверить режим OK event generation и поведение при отсутствии данных. Изменение expression на продуктивном шаблоне способно пересчитать состояние тысяч хостов; сначала клонируют правило на пилотной группе или проверяют функцию по истории.

min(/Linux by Zabbix agent/vfs.fs.size[/,pfree],10m)<{$VFS.FS.PFREE.MIN.CRIT}
avg(/App/http.response.time,5m)>{$APP.LATENCY.WARN}
count(/Network/net.if.in[ifHCInErrors.1],5m,"gt",0)>3

Примеры показывают форму выражений. Ключи, макросы и функции нужно сверить с вашей версией Zabbix и фактическим шаблоном; не вставляйте их без проверки типов item.

Осторожно использовать nodata и unavailable

nodata() обнаруживает отсутствие значений, но причина может быть штатной: passive proxy передаёт историю пакетами, узел выключен по расписанию, item unsupported или interval больше окна. Окно nodata должно превышать ожидаемую задержку сбора и доставки, особенно для proxy с нестабильным каналом.

Отдельный trigger на каждый item при недоступном агенте создаёт десятки событий. Сначала нужен базовый сигнал доступности агента или узла, а зависимые проверки должны подавляться через dependencies либо логически учитывать доступность. При этом внешний web scenario может оставаться главным пользовательским сигналом даже при недоступном агенте.

Unsupported item — конфигурационная проблема, а не обязательно авария сервиса. Его мониторят отдельным служебным процессом: обнаруживают массовые изменения после обновления шаблона, назначают владельца мониторинга и не отправляют каждый unsupported item в круглосуточное дежурство.

Описать зависимости отказов

Trigger dependency подавляет уведомление зависимого trigger, когда проблема активна у master trigger. Типичные связи: сервер зависит от коммутатора, ВМ — от гипервизора, приложение — от базы данных, филиал — от WAN-канала. Пользователь видит первичную проблему, а зависимые события при необходимости остаются доступными для диагностики.

Зависимости должны отражать причинность, а не организационную иерархию. Если приложение способно работать из кэша при недоступной базе, полное подавление может скрыть самостоятельную деградацию. Если у сервиса два резервных upstream, зависимость от одного из них неверна: master-событие должно описывать потерю всей доступности или учитывать логику резервирования.

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

• Недоступность сетевого устройства подавляет host-unreachable за ним.
• Проблема гипервизора подавляет агентские проверки его гостевых ВМ.
• Недоступность Zabbix proxy подавляет сбор с обслуживаемых узлов.
• Зависимость не должна скрывать независимую end-to-end проверку критичного сервиса.

Применять maintenance по назначению

Maintenance сообщает Zabbix, что объект находится в плановых работах. Режим with data collection продолжает графики, но подавляет problem actions в зависимости от настроек; no data collection создаёт пробел и может повлиять на nodata после завершения. Для большинства обновлений полезнее продолжать сбор, если агент и сеть доступны.

Maintenance создают до начала работ, ограничивают точной группой или host и удаляют либо завершают после проверки. Постоянное окно на широкой группе скрывает реальные инциденты. Если работы касаются одного сервиса, host-level maintenance может подавить слишком много; tags и conditions actions позволяют точнее управлять уведомлениями.

Нужно заранее решить судьбу уже открытых проблем и событий, возникших внутри окна. Поведение уведомлений зависит от action operation и параметров escalation: после окончания maintenance старое событие может продолжить escalation. Процесс тестируют на некритичном объекте, а не предполагают.

1. Выбрать конкретные hosts/services и период с небольшим запасом.
2. Оставить сбор данных, если нет причины его выключать.
3. Проверить conditions actions и tags подавляемых событий.
4. Провести работы и убедиться в recovery до выхода из окна.
5. Закрыть maintenance и проверить очередь активных проблем.

Маршрутизировать события через tags и actions

Severity описывает влияние, а не название команды. Один High не должен автоматически отправляться всем администраторам. Event tags позволяют связать событие с service, team, environment и scope, после чего actions адресуют только ответственную группу и нужный канал.

Escalation строят по времени и отсутствию подтверждения: сначала рабочий канал, затем дежурный, затем владелец сервиса. Повтор каждые пять минут без изменения контекста редко ускоряет восстановление. Полезнее одно полное сообщение, обновление при escalation и recovery с длительностью.

Права пользователей Zabbix влияют на доставку: пользователь должен иметь доступ к host и severity, media должна быть активна в нужный период. Ошибка «action совпал, но сообщение не пришло» часто находится в permissions, media time period или failed delivery. Проверяют audit log и отчёт actions.

• В problem сообщении: host, symptom, value, duration и dashboard.
• В recovery: исходная проблема, продолжительность и текущее значение.
• Секреты webhook хранятся в защищённых macro, не в тексте script.
• Тестовый media type не должен отправлять продуктивные события.

Использовать корреляцию без потери причин

Event correlation полезна, когда несколько событий описывают один жизненный цикл или новое событие должно закрыть старое по tags. Она не заменяет корректный trigger. Слишком широкое правило корреляции может закрыть активную проблему другого объекта и создать ложное восстановление.

Для log-based событий recovery часто не возникает автоматически: item получает только строку ошибки. Теги с идентификатором сервиса или инцидента позволяют связать последующее сообщение recovery, если формат источника стабилен. Перед корреляцией сохраняют примеры реальных сообщений и обрабатывают отсутствие ожидаемого поля.

Дедупликацию на стороне внешнего incident manager согласуют с Zabbix. Если обе системы независимо группируют по разным ключам, одно событие может потеряться или, наоборот, размножиться. Выбирают систему — источник жизненного цикла и передают стабильный event ID.

• Правило ограничено source, object и точными tags.
• Новый event не закрывает проблемы другого environment.
• Есть тест для problem, повторного problem и recovery.
• История исходных событий остаётся доступной для разбора.

Проверить изменения на реальном пути уведомления

После правок сравнивают частоту problem/recovery, долю подтверждённых событий, время до acknowledge и число инцидентов без сигнала. Снижение количества сообщений само по себе не успех: можно просто скрыть мониторинг. Нужен контрольный список критичных сервисов и подтверждение, что их отказ всё ещё обнаруживается.

Тест выполняют безопасно: на тестовом host временно задают порог, останавливают некритичный сервис или используют zabbix_sender для trapper item. Затем проверяют expression, event tags, action conditions, media delivery, escalation, acknowledgement и recovery. Кнопка Test у media type проверяет только часть маршрута.

Изменения шаблонов версионируют экспортом и журналом решений. Перед массовым link обновлённого template оценивают число затронутых hosts, новые items и triggers, preprocessing и макросы. Откат должен возвращать не только template, но и ожидаемые action conditions.

1. Снять базовую статистику шума за одинаковый период.
2. Исправить одну группу триггеров и применить на пилотных hosts.
3. Создать problem и recovery контролируемым способом.
4. Проверить зависимости, maintenance и конечный media.
5. Сравнить полезность, задержку и пропущенные сигналы.
6. Расширить изменение и назначить дату повторного аудита.