基于触发器的事件关联

概述

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

通常，一个 OK 事件可以关闭由同一触发器创建的所有问题事件，但在某些情况下，需要更细致的方法。例如，在监控日志文件时，您可能希望发现日志文件中的某些问题，并分别关闭它们，而不是将它们全部一起关闭。

这适用于将 PROBLEM event generation mode 参数设置为 Multiple 的触发器。这类触发器通常用于日志监控、trap 处理等场景。

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

换句话说，同一个触发器可以根据事件标签创建彼此独立的事件。因此，问题事件可以逐个识别，并根据事件标签的标识分别关闭。

工作原理

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

第1行：服务 1 已停止
第2行：服务 2 已停止
第3行：服务 1 已重启
第4行：服务 2 已重启

事件关联的思路是能够将第1行中的问题事件与第3行中的恢复事件匹配起来，并将第2行中的问题事件与第4行中的恢复事件匹配起来，然后逐一关闭这些问题：

第1行：服务 1 已停止
第3行：服务 1 已重启 #第1行中的问题已关闭

第2行：服务 2 已停止
第4行：服务 2 已重启 #第2行中的问题已关闭

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

配置

监控项

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

log[/var/log/syslog]

设置好监控项后，请等待一分钟，让配置更改被接收，然后转到 最新数据，确认该监控项已开始收集数据。

触发器

在监控项正常工作后，您需要配置 触发器。重要的是要决定日志文件中的哪些条目值得关注。例如，下面的触发器表达式会搜索类似于 'Stopping' 的字符串，以提示潜在问题：

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

然后定义恢复表达式。下面的恢复表达式会在找到包含字符串 "Starting" 的日志行时解决所有问题：

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

由于我们不希望这样，因此重要的是以某种方式确保相应的根问题被关闭，而不仅仅是所有问题。此时，标签就能派上用场。

可以通过在触发器配置中指定一个标签来匹配问题和恢复。需要进行以下设置：

• Problem event generation mode: Multiple
• OK event closes: All problems if tag values match
• 输入用于事件匹配的标签名称

• 配置 标签，从日志行中提取标签值

如果配置成功，您将能够在 Monitoring > Problems 中看到按应用程序标记并与其恢复相匹配的问题事件。

• 索引宏始终引用触发器配置中的 Expression 字段，而不是 Recovery expression。 例如，在恢复事件中，{ITEM.VALUE1} 将解析为恢复时刻问题表达式中第一个监控项的最新值。 如果恢复表达式基于不同的监控项，并且在恢复时问题表达式对应监控项的值发生了变化，那么这些事件将具有不同的标签，因而不会被关联。

• 当两个应用程序向同一个日志文件写入错误和恢复消息时，用户可能会决定在同一个触发器中使用两个 service 标签，并通过在标签值中使用单独的正则表达式来提取服务 A 和服务 B 的名称（例如，当消息格式不同的时候）。但是，如果正则表达式没有匹配，这种做法可能不会按预期工作。 不匹配的正则表达式会产生空的标签值，而问题事件和 OK 事件中只要有一个空的标签值，就足以将它们关联起来。 因此，来自服务 A 的恢复消息可能会意外关闭来自服务 B 的错误消息。

• 只有在触发器触发时，实际的标签和标签值才会变得可见。 如果所使用的正则表达式无效，它会被静默替换为 *UNKNOWN* 字符串。如果带有 *UNKNOWN* 标签值的初始问题事件被遗漏，后续可能会出现具有相同 *UNKNOWN* 标签值的 OK 事件，从而关闭本不应被关闭的问题事件。

• 如果用户将不带宏函数的 {ITEM.VALUE} 宏用作标签值，则适用 255 个字符的限制。当日志消息很长且前 255 个字符没有特异性时，这也可能导致无关问题出现相似的事件标签。