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

Обзор

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

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

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

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

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

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

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

• Выполняется обработка собранных данных - проверяются триггеры, обновляется конфигурация элементов данных, если элемент данных становится НЕПОДДЕРЖИВАЕМЫМ, и тому подобное.
• Этот момент считается завершением потока данных с точки зрения обработки значений элементов данных.

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

Для визуализации процесса предобработки данных мы можем использовать следующую упрощённую диаграмму:

Диаграмма выше показывает только процессы, объекты и основные действия, связанные с предварительной обработкой значений элементов данных, в упрощенной форме. Диаграмма не отображает изменения направлений при различных условиях, обработку ошибок или циклы. На диаграмме показан только один рабочий процесс ("preprocessing worker") предварительной обработки (в реальных сценариях могут использоваться несколько таких процессов), обрабатывается только одно значение элемента данных и мы предполагаем, что этот элемент данных требует выполнения по крайней мере одного шага предварительной обработки. Цель этой диаграммы — показать идею конвейера предварительной обработки значений элемента данных.

• Данные элемента данных и значение элемента данных передаются менеджеру предварительной обработки с использованием механизма IPC на основе сокета.
• Элемент данных помещается в очередь предварительной обработки.

• На этом этапе поток данных останавливается до тех пор, пока не появится хотя бы один не занятый (не выполняющий никакие задачи) рабочий процесс ("worker") предварительной обработки.
• Когда "worker" становится доступным, ему направляется задача предварительной обработки.
• После завершения предварительной обработки (как с ошибкой, так и успешно выполненных шагов предобработки), обработанное значение передаётся обратно менеджеру предварительной обработки.
• Менеджер предварительной обработки конвертирует результат в желаемый формат (заданный типом значения элемента данных) и помещает его в очередь предобработки. Если у текущего элемента данных имеются зависимые элементы данных, то зависимые элементы данных также добавляются в очередь предобработки. Зависимые элементы данных помещаются в очередь предварительной обработки сразу после основного элемента данных, но только по тем основным элементам данных, у которых имеется значение и они не находятся в НЕПОДДЕРЖИВАЕМОМ состоянии.

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

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

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

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

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

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

Очередь предварительной обработки - это структура данных FIFO, где накопленные значения сохраняют порядок, в котором они получены менеджером предварительной обработки. Существует несколько исключений логики FIFO:

• Внутренние элементы данных помещаются в начало очереди
• Зависимые элементы данных всегда помещаются в очередь после основного элемента данных

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

Значения из очереди предварительной обработки сбрасываются, начиная с начала очереди до первого необработанного значения. Таким образом, к примеру, менеджер предварительной обработки сбросит значения 1, 2 и 3, но не сбросит значение 5, так как значение 4 ещё не обработано:

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

Preprocessing caching

Preprocessing caching was introduced to improve the preprocessing performance for multiple dependent items having similar preprocessing steps (which is a common LLD outcome).

Caching is done by preprocessing one dependent item and reusing some of the internal preprocessing data for the rest of the dependent items. The preprocessing cache is supported only for the first preprocessing step of the following types:

• Prometheus pattern (indexes input by metrics)
• JSONPath (parses the data into object tree and indexes the first expression [?(@.path == "value")])

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

Файл конфигурации Zabbix сервера позволяет пользователям указать количество рабочих процессов предварительной обработки ("preprocessing worker"). Чтобы задать количество экземпляров рабочих процессов предварительной обработки, нужно использовать параметр конфигурации StartPreprocessors. Оптимальное количество рабочих процессов предварительной обработки может определяться многими факторами, включая количество "предобрабатываемых" элементов данных (элементов данных, требующих выполнения каких-либо шагов предварительной обработки), количество процессов сбора данных, среднее количество шагов для предварительной обработки и так далее.

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