2 预处理细节

概述

本节提供监控项值预处理的详细信息。监控项值预处理允许定义和执行转换规则，用于接收的监控项值。

预处理由预处理管理器进程管理，预处理工作者执行预处理步骤。 所有值（经过预处理或未经预处理）从不同的数据收集器传递到预处理管理器，然后再添加到历史缓存中。数据收集器（轮询程序、捕获器等）和预处理进程之间使用基于套接字的 IPC 通信。无论是 Zabbix server还是 Zabbix proxy（对于由proxy 监视的监控项）都执行预处理步骤。

监控项值预处理

为了可视化从数据源到 Zabbix 数据库的数据流，我们可以使用下面的简化图：

上图仅以简化形式显示了与监控项值处理相关的流程、对象和操作。 该图没有显示有条件的方向变化、错误处理或循环。 预处理管理器的本地数据缓存也没有显示，因为它不直接影响数据流。 此图的目的是显示监控项价值处理中涉及的流程及其交互方式。

• 数据收集从数据源的原始数据开始。 此时数据只包含ID、时间戳和值（也可以是多个值）
• 无论使用哪种类型的数据收集器，对于主动或被动检查、陷阱监控项等的想法都是相同的，因为它只更改数据格式和通信启动器（任何一个数据收集器都在等待连接和数据 ，或数据收集器发起通信并请求数据）。 验证原始数据，从配置缓存中检索监控项配置（使用配置数据丰富数据）。
• 基于套接字的 IPC 机制用于将数据从数据收集器传递到预处理管理器。 此时数据收集器继续收集数据，无需等待预处理管理器的响应。
• 执行数据预处理。 这包括执行预处理步骤和依赖项处理。

• 来自预处理管理器的本地数据缓存的历史数据正在刷新到历史缓存中。
• 此时数据流停止，直到历史缓存的下一次同步（当历史同步器进程执行数据同步时）。
• 同步过程从数据规范化开始，将数据存储在 Zabbix 数据库中。 数据规范化执行到所需监控项类型（监控项配置中定义的类型）的转换，包括基于这些类型允许的预定义大小截断文本数据（HISTORY_STR_VALUE_LEN 用于字符串，HISTORY_TEXT_VALUE_LEN 用于文本和 HISTORY_LOG_VALUE_LEN 用于日志值）。 规范化完成后，数据正在发送到 Zabbix 数据库。

• 正在处理收集的数据 - 检查触发器，如果监控项不支持，则更新监控项配置等。
• 从监控项值处理的角度来看，这被认为是数据流的结束。

监控项值预处理

数据预处理按以下步骤进行：

• 监控项值通过基于UNIX套接字的IPC机制传递给预处理管理器。
• 如果监控项既没有预处理也没有依赖监控项，其值将被添加到历史缓存或发送到LLD（低级发现）管理器。否则：
  • 创建预处理任务并将其添加到队列中，并通知预处理工作线程有新任务。
  • 此时数据流停止，直到至少有一个空闲的预处理工作线程（即，没有执行任何任务）。
  • 当有可用的预处理工作线程时，它会从队列中取出下一个任务。
  • 预处理完成后（包括预处理步骤的失败和成功执行），预处理后的值将被添加到已完成任务队列，并通知管理器有新的已完成任务。
  • 预处理管理器将结果转换为所需的格式（由监控项值类型定义），然后将其添加到历史缓存或发送到LLD管理器。
  • 如果有依赖于处理监控项的依赖监控项，则将依赖监控项添加到预处理队列，使用预处理后的主监控项值。依赖监控项被加入绕过正常值预处理请求的队列，但只适用于值设置且不处于不支持状态的主监控项。

请注意，在图表中，主监控项的预处理略有简化，跳过了预处理缓存的步骤。

预处理队列

预处理队列组织如下：

• 待处理任务列表：
  • 直接从值预处理请求中按接收顺序创建的任务
• 立即任务列表（在待处理任务之前处理）：
  • 测试任务（作为前端的监控项/预处理测试请求的响应而创建）
  • 依赖监控项任务
  • 顺序任务（必须按严格顺序执行的任务）：
    • 具有使用最后一个值的预处理步骤的任务：
      • 更改
      • 节流
      • JavaScript（字节码缓存）
    • 依赖监控项预处理缓存
• 已完成任务列表

预处理缓存

预处理缓存被引入，以改善具有相似预处理步骤的多个依赖监控项（这是常见的LLD结果）的预处理性能。

通过对一个依赖监控项进行预处理，并重用一些内部预处理数据，来为其余的依赖监控项提供缓存。预处理缓存仅支持以下类型的第一个预处理步骤：

• Prometheus 模式（按度量衡输入的索引）
• JSONPath（将数据解析为对象树，并索引第一个表达式 [?(@.path == "value")]）

预处理进程

Zabbix server 配置文件允许用户设置预处理工作进程的数量。StartPreprocessors配置参数应用于设置预处理进程的预分配实例数。 预处理进程的最佳数量可以由许多因素决定，包括“可预处理”监控项（需要执行任何预处理步骤的监控项）的数量、数据收集过程的数量、监控项预处理的平均步骤数等。

但是假设没有像解析大型 XML/JSON 块这样的繁重的预处理操作，预处理进程的数量可以匹配数据收集器的总数。 这样，大多数情况下（除了来自收集器的数据大量进入的情况）至少有一个空闲的预处理进程来处理收集的数据。

监控项值处理流水线

监控项值处理分多个步骤（或阶段）在多个进程中执行。 这可能导致：

• 依赖项可以接收值，而主要监控项不能。 这可以通过使用以下用例来实现：
  • 主要监控项具有值类型UINT，（可以使用陷阱监控项），依赖项具有值类型TEXT。
  • 主要监控项和依赖项都不需要预处理步骤。
  • 文本值（如“abc”）应传递给主要监控项。
  • 由于没有要执行的预处理步骤，预处理管理器检查主项是否处于不支持状态以及是否设置了值（两者都为真）并将具有与主要监控项相同的值的依赖项排入队列（因为没有预处理步骤 ）。
  • 当主要监控项和依赖项都达到历史同步阶段时，主要监控项变为不支持，因为值转换错误（文本数据无法转换为无符号整数）。

因此，依赖项收到一个值，而主要监控项状态将变为不支持。

• 依赖项接收主要监控项历史记录中不存在的值。 用例与前一个非常相似，除了主要监控项类型。 例如，如果主要监控项使用 CHAR 类型，则主要监控项值将在历史同步阶段被截断，而依赖项将从主要监控项的初始（未截断）值接收它们的值。