Подробности предварительной обработки

Обзор

В этом разделе приведены сведения о предварительной обработке значений элементов данных. Предварительная обработка значений элементов данных позволяет определить и выполнить правила преобразования для полученных значений элементов данных.

Предварительная обработка управляется процессом менеджера предварительной обработки и рабочими процессами предварительной обработки, которые выполняют этапы предварительной обработки. Все значения, для которых настроена предварительная обработка и которые получены от разных сборщиков данных, проходят через менеджер предварительной обработки перед добавлением в кэш истории. Между сборщиками данных (опросчиками, трапперами и т. д.) и процессом предварительной обработки используется сокетное взаимодействие между процессами (IPC). Этапы предварительной обработки выполняет сервер Zabbix или прокси Zabbix (для элементов данных, которые отслеживаются прокси).

Обработка значений элементов данных

Чтобы визуализировать поток данных от источника данных к базе данных Zabbix, можно использовать следующую упрощенную диаграмму:

На приведенной выше диаграмме в упрощенном виде показаны только процессы, объекты и действия, связанные с обработкой значений элементов данных. На диаграмме не показаны условные изменения направления, обработка ошибок и циклы. Локальный кэш данных менеджера предварительной обработки также не показан, поскольку он не влияет непосредственно на поток данных. Цель этой диаграммы - показать процессы, участвующие в обработке значений элементов данных, и способы их взаимодействия.

• Сбор данных начинается с необработанных данных из источника данных. На этом этапе данные содержат только идентификатор, временную метку и значение (значений может быть несколько).
• Независимо от типа используемого сборщика данных принцип остается одинаковым для активных или пассивных проверок, элементов данных типа trapper и т. д., поскольку изменяются только формат данных и инициатор обмена данными (сборщик данных либо ожидает подключения и данных, либо инициирует обмен данными и запрашивает данные). Необработанные данные проверяются, а конфигурация элемента данных извлекается из кэша конфигурации (данные дополняются данными конфигурации).
• Для передачи данных от сборщиков данных менеджеру предварительной обработки используется механизм IPC на основе сокетов. На этом этапе сборщик данных продолжает собирать данные, не дожидаясь ответа от менеджера предварительной обработки.
• Выполняется предварительная обработка данных. Она включает выполнение шагов предварительной обработки и обработку зависимых элементов данных.

• Данные истории из локального кэша данных менеджера предварительной обработки выгружаются в кэш истории.
• На этом этапе поток данных останавливается до следующей синхронизации кэша истории (когда процесс синхронизации истории выполняет синхронизацию данных).
• Процесс синхронизации начинается с нормализации данных перед их сохранением в базе данных Zabbix. Нормализация данных выполняет преобразование в требуемый тип элемента данных (тип, определенный в конфигурации элемента данных), включая усечение текстовых данных на основе предопределенных размеров, разрешенных для этих типов (HISTORY_STR_VALUE_LEN для строк, HISTORY_TEXT_VALUE_LEN для текста и HISTORY_LOG_VALUE_LEN для значений журнала). После завершения нормализации данные отправляются в базу данных Zabbix.

• Собранные данные обрабатываются: проверяются триггеры, обновляется конфигурация элемента данных, если элемент данных переходит в состояние NOT SUPPORTED, и т. д.
• С точки зрения обработки значений элементов данных это считается концом потока данных.

Предварительная обработка значения элемента данных

Предварительная обработка данных выполняется в следующие этапы:

• Если для элемента данных не настроены ни предварительная обработка, ни зависимые элементы данных, его значение либо добавляется в кэш истории, либо отправляется диспетчеру LLD. В противном случае значение элемента данных передается диспетчеру предварительной обработки с использованием механизма IPC на основе сокетов UNIX.
• Создается задача предварительной обработки, которая добавляется в очередь, после чего рабочие процессы предварительной обработки уведомляются о новой задаче.
• На этом этапе поток данных останавливается до тех пор, пока не появится хотя бы один свободный рабочий процесс предварительной обработки (то есть рабочий процесс, не выполняющий никаких задач).
• Когда рабочий процесс предварительной обработки становится доступен, он извлекает из очереди следующую задачу.
• После завершения предварительной обработки (как при успешном, так и при неуспешном выполнении этапов предварительной обработки) обработанное значение добавляется в очередь завершенных задач, а диспетчер уведомляется о новой завершенной задаче.
• Диспетчер предварительной обработки преобразует результат в требуемый формат (определяемый типом значения элемента данных) и либо добавляет его в кэш истории, либо отправляет диспетчеру LLD.
• Если для обработанного элемента данных существуют зависимые элементы данных, они добавляются в очередь предварительной обработки вместе с предварительно обработанным значением главного элемента данных.

Зависимые элементы данных помещаются в очередь в обход обычных запросов на предварительную обработку значений, но только для главных элементов данных, для которых задано значение и которые не находятся в состоянии NOT SUPPORTED.

Обратите внимание, что на диаграмме предварительная обработка главного элемента данных немного упрощена: кэширование предварительной обработки пропущено.

Очередь предварительной обработки

Очередь предварительной обработки организована следующим образом:

• список ожидающих задач:
  • задачи, созданные непосредственно из запросов на предварительную обработку значений, в порядке их получения
• список немедленных задач (обрабатываются перед ожидающими задачами):
  • задачи тестирования (создаются в ответ на запросы веб-интерфейса на тестирование элемента данных/предварительной обработки)
  • задачи зависимых элементов данных
  • последовательные задачи (задачи, которые должны выполняться в строгом порядке):
    • использующие шаги предварительной обработки с последним значением:
      • изменение
      • ограничение частоты
      • JavaScript (кэширование байт-кода)
    • кэширование предварительной обработки зависимых элементов данных
• список завершенных задач

Кэширование предварительной обработки

Кэширование предварительной обработки было введено для повышения производительности предварительной обработки нескольких зависимых элементов данных с похожими шагами предварительной обработки (что часто является результатом LLD).

Кэширование выполняется путем предварительной обработки одного зависимого элемента данных и повторного использования некоторых внутренних данных предварительной обработки для остальных зависимых элементов данных. Кэш предварительной обработки поддерживается только для первого шага предварительной обработки следующих типов:

• Шаблон Prometheus (индексирует входные данные по метрикам)
• JSONPath (анализирует данные в дерево объектов и индексирует первое выражение [?(@.path == "value")])

Рабочие процессы предварительной обработки

Файл конфигурации сервера Zabbix позволяет задать количество потоков рабочих процессов предварительной обработки. Для задания количества предварительно запущенных экземпляров рабочих процессов предварительной обработки следует использовать параметр конфигурации StartPreprocessors, которое должно как минимум соответствовать количеству доступных ядер ЦП.

Если задачи предварительной обработки не требуют значительных ресурсов ЦП и включают частые сетевые запросы, рекомендуется настроить дополнительные рабочие процессы. Оптимальное количество рабочих процессов предварительной обработки зависит от многих факторов, включая количество «обрабатываемых» элементов данных (элементов данных, для которых требуется выполнить какие-либо шаги предварительной обработки), количество процессов сбора данных, среднее количество шагов предварительной обработки элементов данных и т. д. Недостаточное количество рабочих процессов может привести к высокому потреблению памяти. Для устранения неполадок, связанных с чрезмерным потреблением памяти в вашей установке Zabbix, см. раздел Профилирование чрезмерного потребления памяти с помощью tcmalloc.

Однако если предположить, что отсутствуют ресурсоемкие операции предварительной обработки, такие как разбор больших фрагментов XML/JSON, количество рабочих процессов предварительной обработки может соответствовать общему количеству процессов сбора данных. Таким образом, для собранных данных в большинстве случаев (за исключением случаев, когда данные от процесса сбора поступают пакетами) будет доступен как минимум один незанятый рабочий процесс предварительной обработки.

Конвейер обработки значений

Обработка значений элементов данных выполняется в несколько шагов (или фаз) несколькими процессами. Это может привести к следующему:

• Зависимый элемент данных может получить значения, в то время как главное значение получить невозможно. Этого можно добиться в следующем случае:
  • Главное элемент данных имеет тип значения UINT (можно использовать элемент данных типа trapper), а зависимый элемент данных — тип значения TEXT.
  • Для главного и зависимого элементов данных не требуются шаги предварительной обработки.
  • Текстовое значение (например, "abc") должно быть передано главному элементу данных.
  • Поскольку шаги предварительной обработки отсутствуют, менеджер предварительной обработки проверяет, что главное элемент данных не находится в состоянии NOT SUPPORTED и что значение задано (оба условия выполняются), а затем ставит зависимый элемент данных в очередь с тем же значением, что и у главного элемента данных (поскольку шаги предварительной обработки отсутствуют).
  • Когда главный и зависимый элементы данных достигают фазы синхронизации истории, главное элемент данных переходит в состояние NOT SUPPORTED из-за ошибки преобразования значения (текстовые данные нельзя преобразовать в беззнаковое целое число).

В результате зависимый элемент данных получает значение, а главное элемент данных изменяет свое состояние на NOT SUPPORTED.

• Зависимый элемент данных получает значение, отсутствующее в истории главного элемента данных. Этот случай очень похож на предыдущий, за исключением типа главного элемента данных. Например, если для главного элемента данных используется тип CHAR, его значение будет усечено на этапе синхронизации истории, тогда как зависимые элементы данных получат свои значения из исходного (неусеченного) значения главного элемента данных.