本节提供有关监控项值预处理的详细信息。通过监控项值预处理,可以为接收到的监控项值定义并应用execute transformation rules。
预处理由预处理管理器进程以及执行预处理步骤的预处理工作进程共同管理。所有带有预处理设置的值(在Zabbix 7.0.17之前,所有值)从不同的数据收集器接收后,都会经过预处理管理器,然后才被添加到history cache中。数据收集器(轮询器、trappers等)与预处理进程之间通过基于套接字的IPC通信进行交互。无论是Zabbix server还是Zabbix proxy(用于由proxy监控的监控项),都会执行预处理步骤。
为了可视化数据从数据源到Zabbix数据库的流向,我们可以使用以下简化图示:
上图仅以简化形式展示了与监控项值处理相关的进程、objects和操作。该图未显示条件方向变化、错误处理或循环。预处理管理器的本地数据缓存也未显示,因为它不直接影响数据流。此图的目标是展示参与监控项值处理的进程及其交互方式。
如果任何预处理步骤失败,则监控项的状态可以在预处理期间更改为NOT SUPPORTED。
如果数据归一化失败(例如,当文本值无法转换为数字时),则监控项的状态可以更改为NOT SUPPORTED。
数据预处理按以下步骤执行:
请注意,在图中主 监控项 的预处理过程略作简化,省略了预处理缓存的步骤。
预处理队列的组织方式如下:
预处理缓存的引入是为了提升多个具有相似预处理步骤的依赖 监控项(这通常是LLD的结果)的预处理性能。
缓存通过预处理一个依赖的 监控项,并为其余依赖的 监控项 重用部分内部预处理数据来实现。预处理缓存仅支持以下类型的第一步预处理:
[?(@.path == "value")]
)Zabbix server配置file允许用户设置预处理工作线程的数量。 应使用startpreprocessors配置参数来设置预启动的预处理工作者实例数量,该数量至少应与可用CPU核心数量匹配。
如果预处理任务不是CPU密集型且涉及频繁的网络请求,则建议配置额外的工作进程。 预处理工作者的最佳数量可能由许多因素决定,包括“可预处理”监控项的数量(需要进行execute任何预处理步骤的监控项)、数据收集进程的数量、监控项预处理的平均步骤数量等。 工作者数量不足可能导致较高的memory使用率。有关解决Zabbix安装中过多memory使用率的问题,请参见Profiling excessive memory usage with tcmalloc。
但假设不存在解析大型XML/JSON块等繁重的预处理操作,则预处理工作者的数量可以与数据收集器的总数匹配。这样,通常情况下(除了数据从收集器批量到达的情况),将至少有一个未被占用的预处理工作者来处理收集到的数据。
过多的数据收集进程(轮询器、不可达轮询器、ODBC轮询器、HTTP轮询器、Java轮询器、ping器、trapper、代理轮询器)与IPMI管理器、SNMP trapper和预处理工作者一起可能会耗尽预处理管理器的每个进程file描述符限制。
耗尽每个进程的file描述符限制将导致Zabbix server停止,通常在启动后不久发生,但有时可能需要更长时间。 为避免此类问题,请查看Zabbix server configuration file以优化并发检查和进程数量。 此外,如有必要,请确保通过检查和调整系统限制,将file描述符限制设置得足够高。
监控项 值处理由多个进程分多个步骤(或阶段)执行。这可能会导致:
UINT
(可以使用 trapper 监控项), 依赖的 监控项 的值类型为 TEXT
。结果是,依赖的 监控项 接收到一个值,而主 监控项 改变为 NOT SUPPORTED 状态。
CHAR
类型, 那么主 监控项 的值将在历史数据同步阶段被截断,而依赖的 监控项 将从主 监控项 的初始值 (未截断的值)接收它们的值。