Исходная ситуация:
Zabbix Queue ≈ 170 000 items
Одновременно наблюдаем:
- poller processes периодически доходят до высокой загрузки;
- preprocessing workers также близки к пределу;
- в системе много dependent items;
- очередь продолжает расти.
Первая гипотеза напрашивается сама:
pollers не хватает → увеличиваем StartPollers.
Но пока это только гипотеза.
1. Что мы действительно знаем
Большая Queue подтверждает:
часть checks не выполняется в ожидаемый срок.
Она не показывает, где именно находится bottleneck.
Поэтому:
Queue ↑ ≠ StartPollers слишком мал
2. Добавляем следующий факт
Наблюдаем:
poller utilization → 100%
Теперь гипотеза о недостаточной poller capacity становится сильнее.
Но высокая занятость pollers может означать как минимум два разных сценария:
слишком много checks
или:
checks выполняются слишком долго
В обоих случаях utilization будет высоким. Причины — разные.
3. Появляется второй признак насыщения
Одновременно:
preprocessing workers → высокая загрузка
и мы знаем, что система обрабатывает большое количество dependent items.
Теперь простая цепочка:
pollers 100%
↓
увеличить StartPollers
становится ещё менее надёжной. Если pollers начнут получать данные быстрее, нагрузка может просто быстрее переместиться в preprocessing. Мы не устраним bottleneck — мы его сдвинем.
4. Формируем несколько гипотез
H1. Недостаточная poller capacity Checks действительно больше, чем текущие процессы способны обработать вовремя.
H2. Медленные checks Pollers значительную часть времени ждут:
- — ответы monitored hosts;
- — network latency;
- — timeout;
- — медленные SNMP-устройства;
- — внешние проверки.
H3. Bottleneck в preprocessing Данные поступают, но preprocessing не успевает их обработать.
H4. Источник проблемы — конкретные templates / discovery rules Например:
master item
↓
много dependent items
↓
тяжёлый preprocessing
↓
pipeline saturation
H5. Ограничение находится ниже Database, storage, proxy или другой subsystem тоже могут создавать вторичное насыщение процессов.
5. Что проверяем дальше
Для каждой гипотезы нужен свой evidence. Смотрим:
- — Queue по типам checks и задержке;
- — utilization разных process types;
- — timeout и latency;
- — unreachable hosts;
- — SNMP-нагрузку;
- — preprocessing steps;
- — master/dependent architecture;
- — проблемные templates и LLD;
- — состояние database и storage.
Задача не в том, чтобы собрать максимум метрик. Задача — понять: какая проверка способна подтвердить или опровергнуть конкретную гипотезу.
6. Допустим, poller capacity подтверждена
После проверки получаем:
pollers стабильно насыщены
+
соответствующие checks задерживаются
+
аномальных timeout нет
+
другого очевидного bottleneck нет
Теперь finding уже можно сформулировать: текущей poller capacity недостаточно для существующей нагрузки.
И только теперь появляется обоснованная recommendation:
увеличить
StartPollers
контролируемым шагом.
Не в 5 раз «на всякий случай».
А настолько, чтобы проверить гипотезу изменением.
7. Но preprocessing остаётся
Если preprocessing workers по-прежнему насыщены, это уже отдельный finding.
Тогда нужно решать второй вопрос:
worker'ов действительно мало или сама preprocessing architecture создаёт избыточную нагрузку?
Простое увеличение StartPreprocessors может помочь.
Но оно не исправит неэффективную структуру master/dependent items или тяжёлые preprocessing steps.
8. Change ≠ problem solved
После изменения начинается validation:
Queue ↓ ? Poller utilization ↓ ? Preprocessing utilization ↓ ? Processing delay ↓ ?
И ещё один обязательный вопрос:
не появился ли новый bottleneck?
Например:
pollers разгрузились
↓
preprocessing ускорился
↓
database стала новым ограничением
Это тоже результат. Но ещё не обязательно хороший.
Главное В начале у нас были:
Queue = 170 000 Pollers ≈ 100%
Очень легко было сказать: «Увеличиваем StartPollers». Но нормальная диагностика выглядит иначе:
Observation
↓
Evidence
↓
Hypotheses
↓
Verification
↓
Finding
↓
Recommendation
↓
Change
↓
Validation