Например:
- добавили много hosts;
- подключили новый template;
- уменьшили update interval;
- добавили большое количество items;
- изменили схему мониторинга;
- появилась сетевая проблема;
- часть monitored systems стала отвечать медленнее.
Изменение во времени часто существенно сокращает пространство гипотез.
Когда увеличение StartPollers становится обоснованным
Гипотеза о недостаточной poller capacity становится значительно сильнее, если данные показывают одновременно:
pollers устойчиво насыщены
+
соответствующие checks задерживаются
+
queue подтверждает проблему
+
нет аномальных timeout/latency
+
не обнаружен более очевидный bottleneck
Теперь recommendation логически следует из собранного evidence: увеличить poller capacity контролируемым шагом и проверить результат. Не «поставить побольше». Не «сервер мощный — сделаем x10». А выполнить управляемое изменение с последующей проверкой.
После изменения начинается validation
Допустим, StartPollers увеличили.
Теперь задаём вопросы:
poller utilization снизился?
queue уменьшается?
задержка checks сократилась?
не переместился ли bottleneck в другой subsystem?
Последний вопрос особенно важен. Ускорив один участок pipeline, можно обнаружить ограничение уже на следующем. Поэтому:
параметр изменён
≠
проблема решена
Главное
pollers busy ≈ 100% — важный диагностический факт.
Но сам по себе он не отвечает на вопрос, почему pollers насыщены.
Правильная последовательность выглядит так:
Observation
↓
Hypotheses
↓
Evidence
↓
Verification
↓
Finding
↓
Recommendation
↓
Change
↓
Validation
Сначала устанавливаем причину. Потом меняем параметр. И только после проверки результата считаем изменение успешным.
100% utilization — это начало расследования, а не готовый диагноз.
#Разбор #Zabbix #Performance #Troubleshooting