1 基于触发器的事件关联

基于触发器的事件关联允许关联由一个触发器报告的独立问题。

通常情况下，一个OK事件可以关闭由一个触发器创建的所有问题事件，但在某些情况下需要更详细的处理方式。例如，在监控日志文件时，您可能希望发现日志中的特定问题file，并分别关闭这些问题，而不是一次性全部关闭。

这种情况适用于将问题事件生成模式参数设置为Multiple的触发器。此类触发器通常用于日志监控、陷阱处理等场景。

在Zabbix中，可以根据tagging将问题事件关联起来。标签用于提取值和create问题事件的标识。利用这一点，也可以基于匹配的标签分别关闭问题。

换句话说，同一个触发器可以基于事件标签create生成单独的事件。因此，问题事件可以逐一识别，并基于事件标签的标识分别关闭。

在日志监控中，您可能会遇到类似以下的行：

Line1: 服务 1 已停止
       Line2: 服务 2 已停止
       Line3: 服务 1 已重启
       Line4: 服务 2 已重启

事件关联的思路是能够将 Line1 中的问题事件与 Line3 中的解决事件匹配，以及将 Line2 中的问题事件与 Line4 中的解决事件匹配，并逐个关闭这些问题：

Line1: 服务 1 已停止
       Line3: 服务 1 已重启 # 来自 Line 1 的问题已关闭
       
       Line2: 服务 2 已停止
       Line4: 服务 2 已重启 # 来自 Line 2 的问题已关闭

为此，您可以将这些相关事件标记为例如 "服务 1" 和 "服务 2"。这可以通过对日志行应用正则表达式来提取标记值来实现。然后，当事件被创建时，它们将分别被标记为 "服务 1" 和 "服务 2"，从而可以将问题与解决事件进行匹配。

首先，你可能需要设置一个监控项来监控一个日志文件，例如：

log[/var/log/syslog]

配置好监控项后，等待一分钟以使配置更改生效，然后前往 Latest data 确认监控项已经开始收集数据。

当监控项正常运行时，您需要配置trigger。关键在于确定日志file中哪些条目值得关注。例如，以下触发器表达式将搜索类似"Stopping"的string来标识潜在问题：

find(/My 主机/log[/var/log/syslog],,"regexp","Stopping")=1

为确保包含string"Stopping"的每一行都被视为问题，还需在触发器配置中将问题事件生成模式设置为'多事件'。

接着定义恢复表达式。以下恢复表达式将在日志行中找到包含string"Starting"时解决所有问题：

find(/My 主机/log[/var/log/syslog],,"regexp","Starting")=1

为避免误判，必须确保仅关闭对应的根本问题而非所有问题。这时标签功能就能发挥作用。

通过在触发器配置中指定标签，可实现问题与解决的匹配。需进行以下设置： - 问题事件生成模式：多事件 - 正常事件关闭：标签值匹配的所有问题 - 输入用于事件匹配的标签名称

配置成功后，您可在监控→问题中看到按应用标记的问题事件及其匹配的解决方案。

由于可能因配置错误为不相关问题创建相似事件标签，请务必审阅以下情况！

索引宏始终引用触发器配置的表达式字段，而非恢复表达式。例如在恢复事件中，{ITEM.VALUE1}将解析为恢复时问题表达式中第一个监控项的最新值。若恢复表达式基于不同监控项且问题表达式监控项的值在恢复时发生变化，事件将get不同标签导致无法关联。
当两个应用将错误和恢复消息写入同一日志file时，用户可能尝试在同一个触发器中使用两个不同值的服务标签，通过正则表达式从{ITEM.VALUE}宏分别提取服务A和服务B的名称（例如消息格式不同时）。但若正则表达式不匹配，此方案可能失效。未匹配的正则表达式会产生空标签值，而问题事件和正常事件中的单个空标签值就足以关联它们，导致服务A的恢复消息意外关闭服务B的错误消息。
实际标签和标签值仅在触发器触发时可见。若使用的正则表达式无效，系统会静默替换为*UNKNOWN* string。若初始带有*UNKNOWN*标签值的问题事件被遗漏，后续可能出现带有相同*UNKNOWN*标签值的正常事件错误关闭本不应关闭的问题事件。
若用户直接使用{ITEM.VALUE}宏（无宏函数）作为标签值，将受255字符限制。当日志消息较长且前255字符无特异性时，也可能导致不相关问题产生相似事件标签。

Documentation