Например, большое количество items имеет одинаковый интервал обновления и значения приходят практически одновременно. В результате preprocessing получает не равномерную нагрузку, а короткий мощный всплеск. Тогда важно смотреть динамику, а не только среднее значение.
Что проверяем до изменения StartPreprocessors
1. Характер загрузки
Это:
- постоянные 90–100%;
- периодические пики;
- кратковременные всплески?
Эти сценарии требуют разных выводов.
2. Что изменилось
Если проблема появилась недавно, выясняем:
- какие templates добавили;
- какие hosts подключили;
- появились ли новые master items;
- выросло ли число dependent items;
- изменились ли интервалы обновления;
- добавились ли тяжёлые preprocessing steps.
Часто это быстрее приводит к причине, чем простое увеличение параметра.
3. Какие preprocessing steps используются
Особое внимание стоит обратить на массово используемые:
- JavaScript;
- JSONPath;
- XPath;
- регулярные выражения;
- обработку крупных входных значений.
Не потому, что эти механизмы плохие. А потому, что их стоимость зависит от объёма данных, сложности выражения и количества выполнений.
4. Архитектуру master/dependent items
Проверяем:
сколько master items?
↓
сколько dependent items на каждый?
↓
как часто приходит новое значение?
↓
сколько preprocessing steps выполняется?
Здесь уже можно увидеть, откуда фактически появляется нагрузка.
5. Другие ограничения системы
Preprocessing не существует изолированно. После его ускорения данные должны обрабатываться дальше. Поэтому изменение:
StartPreprocessors ↑
может просто позволить быстрее передать нагрузку следующей подсистеме. Нужно следить, не появилось ли новое узкое место.
Когда увеличение workers оправдано
Допустим, проверка показывает:
preprocessing стабильно насыщен
+
нагрузка ожидаемая и обоснованная
+
явно неэффективных templates не найдено
+
тяжёлые шаги действительно необходимы
+
CPU и другие ресурсы позволяют увеличить параллелизм
Тогда увеличение StartPreprocessors становится технически обоснованным действием.
Причём параметр меняем контролируемо, а не по принципу:
было 16 — поставим 100.
После изменения обязательно проверяем результат.
Проверка результата
Смотрим:
utilization workers ↓ ?
очередь preprocessing ↓ ?
задержка обработки ↓ ?
CPU не стал новым ограничением?
не появилось узкое место дальше по pipeline?
Если изменение параметра не дало ожидаемого результата, сама гипотеза требует пересмотра.
Отдельно о StartPreprocessors
В актуальной документации Zabbix рекомендуется задавать количество preprocessing workers не меньше числа доступных CPU cores. Но это не означает, что:
16 CPU → StartPreprocessors=16 → настройка всегда оптимальна
Количество workers — только один из факторов. Реальная нагрузка определяется тем, сколько данных приходит и что Zabbix должен с ними сделать.
Главное
preprocessing 100%
≠
просто мало workers
Высокая загрузка может быть следствием:
- реального недостатка workers;
- тяжёлых preprocessing steps;
- большого количества dependent items;
- неоптимального template;
- слишком частого получения данных;
- всплескового характера нагрузки;
- сочетания нескольких факторов.
Поэтому правильный вопрос: не «сколько ещё workers добавить?», а «что создаёт текущую нагрузку preprocessing?» Сначала разбираем источник нагрузки. Потом меняем параметр. После изменения — проверяем результат.
Нужно разобраться с производительностью вашей Zabbix-инфраструктуры?
Выполняю диагностику очередей, pollers, preprocessing и других проблем производительности Zabbix.
Услуги на Kwork: https://kwork.ru/user/borib
#Разбор #Zabbix #Performance #Troubleshooting