Алерт молчит при аварии на WS-042: проверьте expression, nodata и maintenance

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

Нет PROBLEM — сначала Events и статус триггера, не Telegram. Проверьте: expression на актуальном синтаксисе 6.0/7.0, item не unsupported, хост не в maintenance (с подавлением), nodata() с достаточным окном, зависимости не давят событие, severity проходит действие. Медиа чинят после того, как событие видно в Monitoring → Problems. Шум наоборот: ложные алерты. Нет значений: нет данных.

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

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

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

• диск 100% на графике, Problems пуст;
• агент мёртв, nodata молчит;
• триггер Unknown;
• событие есть, стрелка в мессенджер нет.

Отличия:

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

1. Expression сравнивает не те единицы (pfree vs free bytes).
2. min(...,15m)>X при аварии 2 минуты — ещё не окно.
3. Recovery/hysteresis слишком широкий, остаётся OK.
4. Maintenance «with data collection» и показ проблем скрыт фильтром UI.
5. nodata() короче, чем интервал item + timeout, или item passive мёртв иначе чем nodata ждёт.
6. Зависимость от другого триггера, который PROBLEM (глушит дочерний).
7. Trigger disabled, не в шаблоне, который вы смотрите.
8. Редко: clock Zabbix, time() функции, неправильный TZ в time().

Диагностика

1. Item жив?

Latest data ключа из expression. Нет данных — не триггер. Есть данные, значение за порогом визуально — дальше expression.

zabbix_get -s 10.0.20.42 -p 10050 -k agent.ping \
  --tls-connect psk --tls-psk-identity psk-ws042 \
  --tls-psk-file /etc/zabbix/psk-ws042.psk

2. Статус триггера

Configuration → Hosts → WS-042 → Triggers: Enabled, Value (OK/PROBLEM), Unknown. Info при ошибке вычисления.

Expression пример nodata (6.0/7.0):

nodata(/WS-042/agent.ping,10m)=1

Если update interval 5m и окно 5m — ложные/пропуски. Окно ≥ 2–3 интервала.

3. Maintenance

Configuration → Maintenance: хост, группа, период, Maintenance type. «No data collection» тушит item. В Monitoring → Problems включите Show: history и снятый фильтр «suppress».

4. Dependencies

Родитель в PROBLEM — дочерний не покажется как обычный PROBLEM (зависит от настроек отображения). Для «почему не крикнуло про диск, когда умер агент» — так и задумано, если диск зависит от агента. Для «умер агент, nodata молчит» зависимости быть не должно от ложного родителя.

5. Actions

Events: событие создано? Action log: matched, sent, fail (SMTP). Не путать с молчащим триггером.

Решение

Сценарий A. Неверная метрика

vfs.fs.size[C:,pfree]<5 для «мало места», не >5. Путаница pfree/pused — классика молчания. Для диска заранее — тренд, не порог 0 байт.

Сценарий B. Окно слишком длинное

Для Disaster недоступности LAN: max(/WS-042/icmpping,3m)=0 или nodata 10m на agent.ping, не avg за час. Для CPU — наоборот, короткое last() даёт шум, см. пороги.

Сценарий C. Unknown из макроса

Неопределённый {$CPU.UTIL.CRIT} в expression → unknown. Задайте макрос на шаблоне.

Сценарий D. Maintenance забыл снять

Снимите или сузьте период. Не overlapping «на месяц» после работ.

Сценарий E. Nodata vs agent.ping=0

agent.ping возвращает 1 или ничего при down (не 0) для passive timeout — часто нужен именно nodata(), не last()=0. Проверьте фактические last values при остановленном агенте.

sudo systemctl stop zabbix-agent2   # только на тестовом клоне WS-042, не на проде вслепую

Сценарий F. Action фильтр

Добавьте severity Warning если нужно, или поднимите severity триггера. Отдельный action на группу Windows servers.

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

sudo zabbix_server -R config_cache_reload

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

На тесте: доведите item до условия (или Check now + значение trapper). В Events — PROBLEM за секунды–минуты согласно окнам. Action log — отправка. Потом OK по recovery. На проде — следующий реальный инцидент с записью в тикет «событие №…».

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

• Trigger prototype LLD не создался — discovery не видит объект.
• Пользователь смотрит другую инсталляцию (стенд vs zabbix.example).
• Proxy задерживает данные дольше окна nodata — сначала очередь/proxy.
• Multiple templates: вы правите не тот trigger name.

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

• Тест триггера при приёмке шаблона (fake value / stop agent на стенде).
• Canary: предсказуемый item и дежурный знает, что «тест раз в неделю».
• Документировать окна nodata в runbook.
• Не строить Disaster на last()>90 CPU.

Частый самообман: открыт Monitoring → Problems с фильтром только unacknowledged и скрытием suppressed. Событие есть в Events, его просто не видно на дашборде. Второй самообман: правят action и SMTP, хотя Value триггера остаётся OK — медиа здесь ни при чём.

Для nodata(/WS-042/agent.ping,10m) помните: если интервал item 5m, а proxy копит данные 8 минут, получите ложный PROBLEM или пропуск. Окно nodata должно быть больше худшего легитимного лага до 10.0.20.50. Для LAN обычно хватает 10m, для филиала с active proxy после ночного обрыва — 20–30m и отдельный макрос на хосте.

Проверяйте, что expression ссылается на Host name WS-042, а не на Visible name. После клонирования шаблона легко оставить чужой /OLDHOST/ в ручном триггере, и «на этом хосте молчит» будет буквальной правдой.

FAQ

Почему на графике красная зона, а триггера нет?

График — визуализация, порог линии может быть не связан с trigger. Смотрите expression.

Нужен ли «Check now» для nodata?

Nodata смотрит на отсутствие новых значений во времени. Check now наоборот пишет значение — для nodata это не тест аварии.

Maintenance «with data collection» должен алертить?

Данные пишутся, показ проблем можно подавить настройкой maintenance. Проверьте оба флага, не гадайте.

Trigger работает в Test expression, не в бою

Test берёт введённые значения. В бою item другой или history пуст.

7.0 сломал старый syntax?

Импорт старых выражений обычно конвертируется. Если вручную смешали {host:key.fn()} и fn(/host/key) — проверьте Trigger Info.

Зависимости скрыли Disaster диска

Пересмотрите карту: диск не должен зависеть от CPU. Должен зависеть от «агент недоступен», если без агента диск всё равно не измерить.