本节提供监控项值预处理详细信息。 监控项值预处理允许为接收到的监控项值定义和执行转换规则 。
预处理由预处理管理进程管理,该进程在Zabbix 3.4中添加,用于执行预处理步骤。 所有来自不同数据收集器的值(无论是否经过预处理)都会在添加到历史缓存之前通过预处理管理器。 基于套接字的 IPC 通信作用于数据收集器(轮询器、捕获器等)和预处理进程之间。 Zabbix server或 Zabbix proxy(由代理监控的监控项)负责执行预处理步骤。
为了可视化从数据源到 Zabbix 数据库的数据流,我们可以使用下面的简化图:
上图仅以简化形式显示了与监控项值处理相关的流程、对象和操作。 该图没有显示有条件的方向变化、错误处理或循环。 预处理管理器的本地数据缓存也没有显示,因为它不直接影响数据流。 此图的目的是显示监控项价值处理中涉及的流程及其交互方式。
如果任何预处理步骤失败,则在执行预处理时,监控项可以将其状态更改为不支持。
如果数据规范化失败(例如,当文本值无法转换为数字时),监控项可以将其状态更改为不支持。
为了可视化数据预处理过程,我们使用下面的简化图来展示:
上图仅以简化形式显示了与监控项值预处理相关的流程、对象和主要操作。 该图没有显示有条件的方向变化、错误处理或循环。 这张图只显示了一个预处理进程(在现实生活中可以使用多个预处理进程),只处理一个监控项值,我们假设该监控项需要执行至少一个预处理步骤。 此图的目的是展示监控项值预处理管道背后的理念。
监控项可以放在预处理队列的末尾或开头。 Zabbix 内部监控项总是放在预处理队列的开头,而其他监控项类型在最后排队。
监控项值处理分多个步骤(或阶段)在多个进程中执行。 这可能导致:
UINT
,(可以使用陷阱监控项),依赖项具有值类型TEXT
。因此,依赖项收到一个值,而主要监控项状态将变为不支持。
CHAR
类型,则主要监控项值将在历史同步阶段被截断,而依赖项将从主要监控项的初始(未截断)值接收它们的值。预处理队列是一种 FIFO 数据结构,它存储值,保留值由预处理管理器检索的顺序。 FIFO 逻辑有多个例外:
我们使用下面的简化图来可视化展示预处理队列的逻辑:
预处理队列中的值从队列的开头刷新到第一个未处理的值。 因此,例如,预处理管理器将刷新值1、2和3,但不会刷新值 5,因为值4尚未处理:
刷新后队列中只剩下两个值(4 和 5),将值添加到预处理管理器的本地数据缓存中,然后将值从本地缓存传输到历史缓存。 预处理管理器可以在单项模式或批量模式下从本地数据缓存中刷新值(用于依赖项和批量接收的值)。
Zabbix server 配置文件允许用户设置预处理工作进程的数量。StartPreprocessors配置参数应用于设置预处理进程的预分配实例数。 预处理进程的最佳数量可以由许多因素决定,包括“可预处理”监控项(需要执行任何预处理步骤的监控项)的数量、数据收集过程的数量、监控项预处理的平均步骤数等。
但是假设没有像解析大型 XML/JSON 块这样的繁重的预处理操作,预处理进程的数量可以匹配数据收集器的总数。 这样,大多数情况下(除了来自收集器的数据大量进入的情况)至少有一个空闲的预处理进程来处理收集的数据。
太多的数据收集进程(轮询器、无法访问的轮询器、ODBC 轮询器、HTTP 轮询器、Java 轮询器、pingers、陷阱器、代理轮询器)连同 IPMI 管理器、SNMP 陷阱器和预处理进程可能会耗尽预处理管理器的每个进程的文件描述符限制。 这将导致 Zabbix server停止(通常在启动后不久,但有时可能需要更多时间)。 应修改配置文件或提高限制以避免出现这种情况。