2. Дополнительные сведения о предобработке

Обзор

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

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

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

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

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

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

Элемент данных может изменить своё состояние на NOT SUPPORTED во время выполнения предобработки, если какой-либо из шагов предобработки завершится ошибкой.

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

Элемент данных может изменить своё состояние на NOT SUPPORTED, если нормализация данных завершится ошибкой (например, когда текстовое значение не может быть преобразовано в число).

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

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

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

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

Обратите внимание, что на диаграмме предобработка мастер-элемента данных немного упрощена за счёт пропуска кэширования предобработки.

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

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

  • список ожидающих задач:

    • задачи, созданные непосредственно из запросов предварительной обработки значений в порядке их получения

  • список немедленных задач (обрабатываемых до ожидающих задач):

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

  • список завершённых задач

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

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

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

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

Потоки предобработки

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

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

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

Слишком большое количество процессов сбора данных (pollers, unreachable pollers, ODBC pollers, HTTP pollers, Java pollers, pingers, trappers, proxypollers) вместе с IPMI manager, SNMP trapper и обработчиками предобработки может исчерпать лимит файловых дескрипторов на процесс для менеджера предобработки.

Исчерпание лимита файловых дескрипторов на процесс приведет к остановке сервера Zabbix, как правило, вскоре после запуска, хотя иногда это может произойти и позже. Чтобы избежать таких проблем, проверьте файл конфигурации сервера Zabbix, чтобы оптимизировать количество параллельных проверок и процессов. Кроме того, при необходимости убедитесь, что лимит файловых дескрипторов установлен достаточно высоким, проверив и скорректировав системные ограничения.

Поток обработки значения

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

  • Зависимый элемент данных может получить значения, в то время как основной элемент данных — нет. Такое может произойти при следующем сценарии:
    • У основного элемента данных тип значения UINT (можно использовать элемент данных траппер), у зависимого элемента данных тип значения TEXT.
    • Шаги предварительной обработки не требуются ни для основного, ни для зависимого элементов данных.
    • Основному элементу данных необходимо передать текстовое значение (например, «abc»).
    • Поскольку нет шагов предварительной обработки для выполнения, менеджер предварительной обработки проверяет, что основной элемент данных не находится в НЕПОДДЕРЖИВАЕМОМ состоянии и что имеется значение (оба условия выполняются), и помещает в очередь зависимый элемент данных с таким же значением, что и основной элемент данных (поскольку шаги предварительной обработки отсутствуют).
    • Когда основной и зависимый элементы данных переходят в фазу синхронизации истории, основной элемент данных становится НЕПОДДЕРЖИВАЕМЫМ из-за ошибки конвертации значения (текстовые данные невозможно преобразовать в целое положительное число).

В результате зависимый элемент данных получает значение, тогда как основной элемент данных меняет свое состояние на НЕ ПОДДЕРЖИВАЕТСЯ.

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