Типичная картина в Zabbix:
poller processes busy ≈ 100%
Первая реакция вполне понятна:
pollers не хватает → увеличиваем StartPollers.
Иногда это действительно правильное решение.
Но есть проблема:
100% utilization ещё не доказывает, что причина именно в недостаточном количестве pollers.
Этот показатель говорит о другом:
существующие poller processes почти всё доступное время заняты работой.
А вот почему они заняты — это уже предмет диагностики.
Что мы действительно наблюдаем
Упрощённо работа poller выглядит так:
получить задачу
↓
выполнить проверку
↓
получить ответ
или дождаться timeout
↓
перейти к следующей задаче
Если задач слишком много, pollers будут постоянно заняты.
Но тот же эффект возникнет, если задач не так много, зато отдельные проверки выполняются слишком долго.
Поэтому:
pollers busy ≈ 100%
≠
StartPollers слишком мал
Это симптом насыщения процесса, а не установленная причина.
Гипотеза №1. Poller capacity действительно недостаточно
Самый очевидный сценарий:
количество checks ↑
↓
текущей concurrency недостаточно
↓
pollers постоянно заняты
↓
проверки начинают задерживаться
↓
queue растёт
В таком случае увеличение StartPollers действительно может быть обоснованным.
Но сначала нужно подтвердить, что именно capacity стала ограничением.
Гипотеза №2. Проверки выполняются слишком долго
Представим две системы с одинаковым количеством pollers.
В первой типичная проверка завершается быстро.
Во второй poller значительную часть времени ожидает ответ monitored host или timeout.
Количество процессов одинаковое.
Их фактическая пропускная способность — нет.
Причиной могут быть:
- высокая network latency;
- packet loss;
- недоступные или нестабильные hosts;
- медленные ответы monitored systems;
- timeout;
- тяжёлые проверки;
- external checks и внешние зависимости.
В этом случае увеличение количества процессов может дать системе возможность одновременно ждать больше медленных checks, но не устранит исходную причину задержек.
Гипотеза №3. Смотрим не на тот process type
Современный Zabbix использует разные типы процессов для разных задач.
Например, обычные pollers и SNMP pollers — это не одно и то же.
Поэтому перед изменением StartPollers нужно понять:
какие именно процессы насыщены и какие checks они обслуживают?
Если проблема находится, например, в SNMP-нагрузке, сначала нужно исследовать соответствующий pipeline, а не автоматически увеличивать обычные pollers.
Гипотеза №4. Pollers — не единственная точка насыщения
Допустим, одновременно наблюдаем:
pollers → высокая загрузка preprocessing workers → высокая загрузка queue → растёт
Теперь картина уже не сводится к одному параметру.
Даже если увеличение poller capacity ускорит получение данных, следующим ограничением может оказаться preprocessing или другой участок pipeline.
Вместо:
pollers 100%
↓
увеличить StartPollers
получаем задачу:
где начинается задержка?
↓
какие процессы насыщены?
↓
какие данные через них проходят?
↓
что ограничивает throughput?
Что проверить до изменения
StartPollers
1. Queue
Растёт ли очередь вообще?
Нужно понять не только её размер, но и характер задержанных checks.
2. Динамику poller utilization
Важно отличить:
единичный spike
от:
устойчивых 95–100%
или регулярного насыщения в определённые периоды.
Один пик и постоянный bottleneck — разные ситуации.
3. Другие process types
Не ограничиваемся одним графиком.
Смотрим, нет ли одновременного насыщения:
- preprocessing;
- unreachable pollers;
- SNMP pollers;
- history processing;
- других процессов, связанных с конкретной нагрузкой.
4. Характер checks
Нужно понять, какую работу выполняют насыщенные процессы:
- сколько таких items;
- с какой периодичностью они запускаются;
- какие hosts их генерируют;
- нет ли большого числа медленных или проблемных проверок.
5. Timeout и latency
Если процесс большую часть времени ждёт ответ, это принципиально другая причина высокой занятости, чем просто недостаточная concurrency.
6. Что изменилось
Один из самых полезных вопросов: