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

Полезная карта алертов — это дерево зависимостей + severity + разные media, не «все триггеры в Telegram». При падении шлюза/proxy/10.0.20.50:10051 должен кричать корень, а не 200 agent.ping за ним. CPU Warning не звонит; Disaster недоступности LDAP и диск-timeleft — звонит. Шум порогов: ложные алерты. Молчание: триггер не срабатывает. Доступность слоями: сервис, не только ICMP.

UI zabbix.example. Хосты вроде WS-042 висят на конкретных uplink/proxy — это рёбра карты, их надо нарисовать явно.

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

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

  • падение одного коммутатора = 80 SMS;
  • дежурный выключает звук на весь Zabbix;
  • в тикетах нет корня, есть «всё красное»;
  • Warning и Disaster в одном чате без тегов.

Отличия от «просто высокие пороги»: пороги режут flap одного item; карта режет каскад разных хостов. Нужны оба слоя. CPU: пороги. Диск: тренд места.

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

  1. Нет dependencies вообще.
  2. Все хосты зависят от ICMP zabbix.example — прячет реальные локальные диски при плановом рестарте UI? Нет: зависимость от сервера мониторинга тушит мир, когда мёртв только UI. Не делайте.
  3. SMS на Information.
  4. Один action «все группы, все severity».
  5. Maintenance вместо карты на каждый чих.
  6. Дубли mediatype retry × 5.
  7. Редко: циклические зависимости триггеров.

Диагностика

1. Инцидент-разбор

Возьмите последний каскад: Events за 10 минут. Один корневой хост (switch/proxy) и хвост WS-042… Если хвост ушёл в SMS — ребра не настроены.

2. Dependencies в UI

Configuration → Hosts → Triggers → Dependencies. У «Zabbix agent is not available» на хостах филиала должен быть родитель «proxy down» / «gateway icmp down».

3. Actions

Notifications: фильтр severity, host group, time period. Escalation: Warning 30 мин в чат, Disaster сразу SMS. Action log: сколько сообщений на одно падение VLAN.

4. Карта сети UI

Monitoring → Maps — картинка для NOC, не замена trigger dependencies. Можно иметь оба: map для глаз, dependencies для тишины телефона.

Решение

Слой 0. Инвентарь путей

Таблица (ведите вне Zabbix, потом макросы):

  • Филиал A: gateway 10.0.30.1 → proxy → хосты WS-042…
  • ДЦ: ToR → гипервизор → VM
  • Сам Zabbix 10.0.20.50 мониторится с другого probe, иначе смерть сервера тиха

Слой 1. Сеть

Триггер ICMP шлюза. Дочерние: ICMP хостов за ним, net.tcp.service тех же хостов. Не кладите диск-timeleft в зависимость от ICMP шлюза? Кладите: если хост недостижим, «диск» item nodata всё равно врёт/шумит. Диск зависит от «агент доступен», агент — от «шлюз/proxy». Цепочка: uplink → proxy → agent ping → disk items triggers.

Исключение: item снимается другим путём (SNMP СХД в другой сети) — не вешать на uplink филиала.

Слой 2. Proxy

Proxy не передаёт: родитель «proxy last seen». Дети — все agent unavailable этого proxy. Не дети: хосты, которых proxy не обслуживает.

Слой 3. Сервис на хосте

HTTP зависит от «порт 443 down» или от «агент down», если HTTP через агент. LDAP зависит от NTDS service и от host up. Не наоборот (host up зависит от LDAP).

Слой 4. Severity и media

SeverityПримерMedia
Inforealloc=4 стабильнодашборд
WarningCPU выше базы, диск 14d timeleftчат дневной
HighRAID degraded, backup fail, cert 7dчат + тикет
DisasterLDAP down, диск hours timeleft, proxy downSMS/звонок

Не SMS на Warning. Это и есть «не звонить обо всём».

Слой 5. Actions без дублей

Один action Disaster 24/7 SMS на группу дежурных. Warning — рабочие часы, Telegram. Не три action с пересечением «all triggers». Теги scope:network / scope:app для фильтра.

После правок:

sudo zabbix_server -R config_cache_reload

Проверка конфига сервера, если трогали процессы:

sudo -u zabbix zabbix_server -c /etc/zabbix/zabbix_server.conf -T

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

На стенде (не прод-шлюз):

  1. Down ICMP gateway → одно Disaster, хосты за ним не SMS (видны как зависимые в UI, если включён показ).
  2. Down только WS-042 при живом шлюзе → SMS/чат про этот хост.
  3. CPU Warning → нет SMS.
  4. Диск timeleft Disaster при живом агенте → есть SMS.
  5. Action log: счётчик сообщений каскада упал на порядок.

Разбор реального инцидента через неделю: в тикете указан корень, не 40 вложений.

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

  • Зависимости есть, UI всё равно пачка: включён показ dependents; media смотрит и на них. Снимите «notify dependent» если появилось в вашей версии action — сверяйте 6.0/7.0 UI, не выдумывайте флажок.
  • Родитель не переходит в PROBLEM (порог ICMP слишком мягкий) — дети не прячутся, чините родительский trigger.
  • Цикл A↔B: Zabbix отвергнет или поведение странное — уберите.
  • Карта Maps зелёная, SMS красные — maps не управляют media.

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

  • Новый филиал: ребра в том же change, что хосты.
  • Ревью топ SMS раз в месяц — это метрика качества карты.
  • Запрет action «all host groups, not classified+».
  • Документ дерева в git (таблица), не только клики.
  • Не глушить backup-fail зависимостью от CPU.
  • Новые хосты из LLD не получают рёбра сами: template-level depends на gateway, где возможно, иначе runbook «дописать depends» в том же изменении, что discovery.

FAQ

Host dependencies vs trigger dependencies

В 6.0/7.0 основной механизм глушения каскада — trigger dependencies. Host-level (если используете) не путайте с «хост в maintenance». Читайте форму триггера.

Можно ли event correlation вместо dependencies?

В 7.0 есть развитый correlation. Не заменяет простое дерево uplink→host. Начните с dependencies.

Почему дети всё равно в Problems?

Фильтр Show suppressed / dependant. Для дежурного SMS важнее, чем список на дашборде.

Зависимость от «Zabbix server is down»

Осторожно: если server down, зависимые триггеры не вычисляются anyway. Внешний probe на 10.0.20.50:10051 и HTTP zabbix.example должен жить вне этой карты (другая система или простой cron), иначе слепое пятно.

Maps для руководства

Да, для демо. Телефон спасают dependencies+severity.

Нужно ли закрывать события вручную после каскада?

Нет, если OK пришёл. Ручной close без фикса корня — маскировка. ACK с сообщением «ждём линк» ок.