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

Порог «CPU > 50%» навсегда — источник либо вечного шума, либо ложного спокойствия. Снимите базу WS-042 за 7–14 дней (рабочие часы vs ночь), задайте Warning выше базы с окном min(...,10m), Disaster на плато 95–100% + load/latency, hysteresis на OK. Для RAM на Linux смотрите available, не used с cache. Шум: ложные алерты. Диск так же не 0 байт: диск. Разные ОС: Linux, Windows.

Макросы на шаблоне/хосте, не хардкод в 50 выражениях. Сервер 10.0.20.50, UI zabbix.example.

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

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

  • Problems всегда про WS-042 CPU, все игнорят;
  • Linux RAM 95% used, available 8 ГБ, ложный Disaster;
  • реальное зависание 2 минуты 100% — триггер min(15m) не успел;
  • ночной backup = пачка Warning.

Это не «Zabbix врёт», это шаблон с чужой жизнью.

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

  1. Скопировали шаблон vendor с 80% на все.
  2. last()>50 без окна — flap.
  3. Windows Committed vs Linux used+cache.
  4. Нет раздельных макросов для ролей.
  5. Смотрят только CPU, не load, queue length, latency приложения.
  6. VM: не смотрят system.cpu.util[,steal].
  7. Редко: один vCPU, порог как у железа 32 ядра.

Диагностика

1. Снимите график, не ощущения

Latest data / graph 14d: system.cpu.util, per cpu, steal, iowait, vm.memory.size[available], Windows vm.memory.size[pavailable].

zabbix_get -s 10.0.20.42 -p 10050 -k system.cpu.util \
  --tls-connect psk --tls-psk-identity psk-ws042 \
  --tls-psk-file /etc/zabbix/psk-ws042.psk
zabbix_get -s 10.0.20.42 -p 10050 -k 'vm.memory.size[available]' \
  --tls-connect psk --tls-psk-identity psk-ws042 \
  --tls-psk-file /etc/zabbix/psk-ws042.psk

Запишите: p50/p95 рабочих часов. Warning должен быть выше p95 устойчивого, иначе вечный шум.

2. Роль хоста

DC, SQL, RDS, сборщик логов, Zabbix server 10.0.20.50 — разные базы. zabbix-server сам может жить на 40–60% в пике очереди — это повод чинить очередь, не копировать порог на WS-042.

3. Память

Linux: available включает учёт cache. Триггер used>90 почти всегда ложен на файловом сервере.

Windows: смотрите Available MBytes / Committed, не «Task Manager 90%» как слепок Zabbix без понимания standby.

Решение

Сценарий A. Макросы

{$CPU.UTIL.WARN} {$CPU.UTIL.CRIT} на шаблоне-роли: File 85/95, SQL 90/98 (если база подтвердила), idle-VDI 50/80. Override на хосте.

min(/WS-042/system.cpu.util,15m)>{$CPU.UTIL.WARN}

Disaster:

min(/WS-042/system.cpu.util,5m)>{$CPU.UTIL.CRIT}

Recovery hysteresis: max(...,15m)<{$CPU.UTIL.WARN}-15 или отдельные макросы.

Сценарий B. Не только util

Добавьте: system.cpu.util[,iowait], steal, proc.load[avg1] относительно числа ядер. Высокий iowait — диск/SAN, не «нужно больше CPU вслепую».

Сценарий C. RAM

max(/WS-042/vm.memory.size[available],5m)<{$MEMORY.AVAILABLE.MIN}

{$MEMORY.AVAILABLE.MIN} в байтах (1G и т.д.) по размеру VM: на 8 ГБ гостя порог 300–500M available — уже тесно; копировать 10% used нельзя.

Swap: рост paging + падение available важнее «swap есть 1%».

Сценарий D. Окна backup

Либо выше WARN в известный слот (осторожно с time() TZ), либо не Warning CPU на этом хосте, оставив CRIT на 10m@99%. Документируйте.

Сценарий E. После смены железа

Пересмотрите макросы: добавили ядра — load-порог меняется. Не забывайте.

Связка с картой: CPU Warning не SMS. Disaster + недоступность сервиса — да. Зависимости: не звонить CPU гостей, если хост гипервизора steal/CPU Disaster.

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

14 дней: число CPU events на WS-042 упало, реальный инцидент (зависший процесс 100% 10+ мин) пойман. Linux больше не орёт на cache. Дежурный не ACK «как всегда». Стенд: stress-ng/CPU на 20 мин выше CRIT — один PROBLEM, не 50 flap.

Не запускайте stress на проде WS-042.

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

  • p95 уже 92% постоянно — порог не «нарисовать зелёным», нужен capacity, иначе вы скрываете правду. Разделите: Warning capacity ticket vs Disaster outage.
  • Item interval 10s, trigger last() — верните min().
  • Неверный ключ Windows perf.

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

  • Ревью макросов раз в квартал или после проекта нагрузки.
  • Запрет шаблона «50%» в git.
  • Дашборд p95 CPU по группам.
  • Связка с доступностью приложения, не CPU ради CPU.
  • На zabbix.example макросы роли видны в Configuration → Hosts → WS-042 → Macros, не только в шаблоне.

Снимите p50 и p95 за две рабочие недели до смены макросов. Если p95 CPU уже 88%, Warning 80% будет вечным. Это проект ёмкости, а не «нарисуем 95%, чтобы затихло». Disaster оставьте для плато, близкого к отказу сервиса: латентность, очередь, почти 100% несколько минут.

Linux cache: покажите коллегам free -h рядом с графиком available — споры «память забита» схлопнутся. Windows не копируйте процент Task Manager в trigger без понимания Standby. RDS и SQL получают свои макросы: база нагрузки другая.

После resize VM пересмотрите пороги в том же изменении. Старый абсолют available 512M на машине 64 ГБ не стрельнет никогда, а старые проценты наоборот начнут врать.

Практический минимум на WS-042: график 14 дней, p95 рабочих часов, макрос WARN чуть выше p95 с окном 10–15 минут, CRIT на короткое плато у потолка, hysteresis на возврат. RAM — available в байтах, не used процент. Steal и iowait рядом, чтобы не покупать CPU при больном диске. Ночной backup либо документированное окно, либо не Warning. Раз в квартал пересмотр после проектов нагрузки. Не копируйте 50% из старого шаблона «потому что так везде». Если p95 уже упирается в CRIT, эскалируйте capacity, а не рисуйте 99% «чтобы Zabbix замолчал» — молчание при зажатом сервере хуже шума.

FAQ

Почему vendor template 80%?

Универсальная отсечка. У вас не универсальное железо. Макросы для того и существуют.

load vs util

load — очередь. util — занятость. На Windows load как у Linux нет; используйте processor queue length если нужен аналог.

Нужен ли per-cpu trigger?

Шумно. tot util + steal/iowait. Per-cpu — диагностика, не SMS.

Zabbix 7.0 считает иначе?

Ключи те же по смыслу. Не меняйте пороги «потому что 7.0», меняйте по графику.

RAM VM с balloon

Dynamic memory ломает «проценты». Смотрите available и demand гипервизора отдельно.

Можно ли ML/anomaly в 6.0/7.0?

Есть trend functions. Не включайте anomaly на всё сразу — получите новый шум. Сначала макросы и окна.