РАЗБОР #02
В Zabbix видим:
preprocessing worker utilization ≈ 100%Первая реакция выглядит логично: workers не хватает → увеличиваем StartPreprocessors. Иногда это действительно правильное действие. Но высокая загрузка preprocessing workers сама по себе подтверждает только одно: текущая нагрузка почти полностью занимает доступные workers. Почему это происходит — отдельный вопрос.
preprocessing 100%
≠
workers недостаточно
Что вообще происходит в preprocessing
Упрощённо pipeline можно представить так:
получено значение
↓
preprocessing manager
↓
preprocessing workers
↓
шаги обработки
↓
результат
↓
дальнейшая обработка в Zabbix
Workers выполняют настроенные шаги preprocessing. Например:
- — JSONPath;
- — XPath;
- — регулярные выражения;
- — JavaScript;
- — преобразование типов;
- — фильтрацию значений;
- — другие операции предварительной обработки.
Чем больше значений проходит через preprocessing и чем сложнее их обработка, тем больше работы получают workers.
Особенно интересны master item и dependent items
Один из сильных механизмов Zabbix выглядит примерно так:
master item
↓
один большой JSON/XML/текстовый ответ
↓
preprocessing
↓
dependent item #1
dependent item #2
dependent item #3
...
master item получает данные один раз.
dependent items (зависимые элементы данных) извлекают из этого результата отдельные значения.
Это позволяет вместо десятков отдельных запросов к устройству или API получить данные одним запросом.
Но есть обратная сторона.
Один новый результат master item может породить обработку сразу большого количества dependent items.
Например:
1 master item
↓
80 dependent items
Если master item обновляется раз в минуту, это уже регулярный поток операций preprocessing. А теперь представим:
500 hosts × несколько master items × десятки dependent items
Нагрузка становится совсем другого масштаба.
Гипотеза №1. Workers действительно мало
Самый прямой вариант. Объём preprocessing вырос, а количество workers осталось прежним. Например:
- — добавили новые hosts;
- — подключили тяжёлый template;
- — увеличили количество dependent items;
- — уменьшили интервалы обновления;
- — вырос объём собираемых данных.
Тогда имеющаяся производительность workers действительно может стать ограничением.
В таком случае увеличение StartPreprocessors может быть оправдано.
Но это ещё нужно подтвердить.
Гипотеза №2. Проблема не в количестве, а в стоимости обработки
Не все preprocessing steps одинаковы по нагрузке. Условно:
простое преобразование значения
и
большой JSON → несколько сложных JSONPath → JavaScript → дополнительные преобразования
— совершенно разные задачи. Если отдельное значение требует заметного времени обработки, увеличение количества workers может повысить параллелизм. Но сама тяжёлая логика никуда не исчезнет. Поэтому нужно смотреть не только: сколько workers? но и: что именно они делают?
Гипотеза №3. Слишком много dependent items
Dependent items сами по себе не проблема. Напротив, во многих сценариях они позволяют существенно сократить количество запросов к контролируемой системе. Но архитектура:
один master item
↓
очень большое число dependent items
↓
несколько preprocessing steps у каждого
может создавать значительную внутреннюю нагрузку.
Особенно если такая конструкция массово размножается через templates или LLD.
Тогда вопрос уже не только в StartPreprocessors.
Нужно анализировать саму архитектуру сбора данных.
Гипотеза №4. Нагрузка приходит всплесками
Средняя загрузка может выглядеть приемлемо, но раз в минуту происходить:
10% 10% 15% 100% 100% 100% 20%