Короткий ответ

Если дежурный ненавидит Zabbix, проблема почти никогда не в «маленьком StartPollers». Шум лечится порогами по базе, hysteresis (разные условия PROBLEM/OK), зависимостями (не звонить о 40 хостах при мёртвом ICMP шлюза) и антифлапом (min/avg за 5–15 минут, не last()>80). Не Disable trigger «навсегда» и не держите Acknowledge без действия. Пороги CPU/RAM: как выбрать. Карта: полезные зависимости. Молчание наоборот — триггер не срабатывает.

Хост-пример: WS-042, сервер 10.0.20.50, UI zabbix.example.

Симптомы и как отличить

Типичная картина:

  • Problems: сотни WARNING, единицы DISASTER;
  • один интерфейс флапает, LLD наплодил триггеры;
  • в 03:00 пачка CPU из-за backup;
  • при падении VPN — все удалённые агенты «недоступны».

Отличия:

ШумНе «ложные пороги»Куда
Тысячи item на фантомных FSLLDLLD мусор
Диск алертит при 0 байттренд местадиск заранее
Триггер не открываетсяexpression/nodataне срабатывает
CPU 50% «навсегда» в шаблонебаза нагрузкипороги CPU/RAM

Возможные причины

  1. Порог last(/WS-042/system.cpu.util)>50 без окна.
  2. Нет hysteresis: OK при <50, PROBLEM при >50 — дрожание на границе.
  3. Нет trigger dependency от ICMP шлюза / hypervisor.
  4. Severity всех LLD портов = Average.
  5. Макросы шаблона не переопределены на хосте ({$CPU.UTIL.CRIT}).
  6. Nodata слишком короткий на нестабильном WAN.
  7. Редко: дубли шаблонов на одном хосте, два триггера на один смысл.

Диагностика

1. Топ шумных триггеров

Monitoring → Problems: фильтр по хосту/группе, посмотрите Event list одного триггера за 7 дней. Если 200 переходов — flap, не «инфраструктура горит 200 раз».

2. Expression как есть

Откройте триггер, перепишите в заявку. Для 6.0/7.0 синтаксис:

min(/WS-042/system.cpu.util,5m)>90

не

last(/WS-042/system.cpu.util)>50

Проверьте Recovery expression: если пустой, OK = отрицание PROBLEM, граница та же.

3. Dependencies

У «агент недоступен» на WS-042 должна быть зависимость от недоступности proxy/шлюза, если путь общий. Иначе падение 10.0.20.50:10051 умножает тикеты.

4. Макросы хоста

Inventory/Macros: {$CPU.UTIL.MAX} и т.п. Шаблонный 80% на SQL-сервере, который живёт на 85% — ложь, не авария.

5. LLD

Сколько триггеров на net.if.* для down портов. Админские down — не PROBLEM. Фильтры discovery.

Решение

Сценарий A. Flap на пороге

Hysteresis:

# PROBLEM
min(/WS-042/system.cpu.util,10m)>90
# Recovery
max(/WS-042/system.cpu.util,10m)<70

Цифры — после базы, не с потолка. См. статью про пороги.

Сценарий B. Каскад при падении сети

Зависимости: ICMP gateway → хосты за ним; Zabbix proxy down → агенты этого proxy. Не наоборот. Подробно — карта алертов.

Сценарий C. Ночной backup CPU

Окно: либо trigger с time() (осторожно с TZ), либо выше порог в известный слот, либо не алертить CPU Warning на этом хосте, оставив DISASTER на 10m avg 99% + load. Лучше явно документировать, чем mute.

Сценарий D. LLD портов

Фильтр {#IFNAME} не матчит ^(lo|docker|veth). Severity Operational data. Down admin → не триггерить.

Сценарий E. Короче nodata на WAN

nodata(/WS-042/agent.ping,30m) вместо 5m для филиала. Не маскируйте реальный down 30 минутами на LAN-сервере в том же шаблоне — macro на хосте.

После правок шаблона подождите кэш или zabbix_server -R config_cache_reload на 10.0.20.50.

Как проверить, что проблема устранена

7 дней: число событий по топ-триггеру упало на порядок, реальные инциденты (диск, недоступность агента после подтверждённого down) всё ещё приходят. Дежурный не использует «закрыть все». Flap test: искусственно подержите CPU выше порога 10+ минут — PROBLEM должен открыться один раз.

Если не помогло

  • Шум из mediatype retry (email 10 раз) — чините media, не триггер.
  • Escalation дублирует Telegram и SMS на Warning — оставьте SMS на Disaster.
  • Пользователи подписаны на все группы.
  • Триггеры в unknown из-за unsupported плодят «события» — чините item.

Профилактика

  • Review топ-20 триггеров раз в месяц.
  • Макросы порогов на уровне хоста/группы.
  • Запрет линка двух шаблонов с одним CPU-триггером.
  • Дашборд «noise»: events/day.

Разбор шума — регулярная процедура, не «когда совсем достало». Раз в две недели снимайте топ-10 имён триггеров по числу событий, срез по host group, отдельно LLD-порты и CPU. Для каждой строки решите: hysteresis, макрос хоста, зависимость, фильтр discovery или удаление бессмысленного trigger. В заявке фиксируйте «было N событий за неделю, стало M».

Не заменяйте карту алертов вечным Acknowledge. ACK без действия учит игнорировать Disaster. Если бизнес просит не звонить ночью по CPU, это severity и media, не Disable trigger. Ночной диск и backup-fail должны уметь разбудить.

Макросы критичности CPU на группе SQL и на группе филиал обязаны отличаться. Один шаблон допустим, одна цифра на всю компанию — нет. После смены макроса дождитесь окна выражения, не объявляйте победу через пять минут тихого графика.

Отдельно посмотрите mediatype: десять повторных писем на один PROBLEM выглядят как «ложные алерты», хотя триггер открылся один раз. Снимите retry SMTP и дубли Telegram плюс SMS на Warning. Шум канала и шум expression — разные заявки, не лечите оба Disable trigger на WS-042.

FAQ

Acknowledge снимает шум?

Нет. Это «видели». Без действия trigger вернётся. Не стройте процесс на вечном ACK.

Можно ли avg за 1h чтобы не звонило?

Спрячете 20-минутный outage CPU steal, который нужен. Для Warning — 10–15m, для Disaster — короче, но с hysteresis.

Maintenance vs Disable trigger

Maintenance на окно работ. Disable — только мёртвый смысл (декомиссия интерфейса), с комментарием.

Почему после зависимостей «мало алертов», босс недоволен?

Зависимости прячут симптомы, не корневую причину. Корневая должна быть громкой (uplink). Объясните картой, не включайте всё обратно.

Макрос в шаблоне не применяется

Опечатка {$CPU.UTIL.CRIT} vs другое имя в expression. Trigger не берёт «похожие» макросы.

6.0 vs 7.0 syntax

Обе LTS — функции last(/host/key). Старый {WS-042:agent.ping.nodata(5m)}=1 в новых шаблонах не копируйте смешивая стили без проверки.