1 基于触发器的事件关联

概述

基于触发器的事件关联,允许关联一个触发器报告的各个不同问题。

在Zabbix中,通常一个正常(恢复)事件会关闭一个触发器生成的所有问题事件,但在某些情况下需要更加细致的方法。例如,当监控日志文件时,在日志文件中想要发现某些问题,并将它们单独关闭,而不是一起关闭。

这需要在触发器配置页面将 生成多重问题事件 选项置为启用。通常适用于日志监控、被动采集(trap)处理等。

如果这么做了,zabbix 可以根据事件标签关联问题事件。事件标签被用于提取值并创建问题事件的标签。利用这一点,还可以根据匹配的标签关闭个别问题。

工作原理

在日志监控中,可能会遇到下面类似地输出:

  1. Line1: 应用1停止
  2. Line2: 应用2停止
  3. Line3: 应用1重启
  4. Line4: 应用2重启

事件关联地过程是将 Line1 的问题事件关联到 Line3 的恢复事件, Line2 的问题事件关联到 Line4 的恢复事件。除了完成匹配,还能能逐个关闭这些问题:

  1. Line1: 应用1停止
  2. Line3: 应用1重启#问题来自于Line1关闭
  3. Line2: 应用2停止
  4. Line4: 应用2重启#问题来自于Line2关闭

为此,需要通过标签将这些事件相关联,例如,可以标识为”Application 1”和”Application 2”。这个过程也可以将正则表达式应用于日志中,来提取标签的值。然后,当事件创建时,他们分别给打上为”Application 1”和”Application 2”的标签,并且问题可以与解决方法相匹配

配置

监控项

首先,你需要设置一个监控日志文件的监控项,例如:

  1. log[/var/log/syslog]

1 基于触发器的事件关联 - 图1

当这个监控项设置完毕,等待一分钟让配置变更被Zabbix Server读取到,然后去 最新数据 页面确认数据有开始采集

触发器

在监控项运行正常后,你需要配置 触发器

配置前,确认日志文件中哪些条目值得关注非常重要。
举个例子:
以下触发器表达式将搜索“ Stopping”之类的字符串以表示潜在问题:

  1. {My host:log[/var/log/syslog].regexp("Stopping")}=1

为了确保包含字符串 “Stopping” 的每一行都被视为问题,还需要将触发器中的事件生成模式设置为 ‘多重事件’。

然后顶一个恢复表达式。下面的恢复表达式将会在有一行包含字符串 ‘Starting’ 日志即恢复所有问题事件:

  1. {My host:log[/var/log/syslog].regexp("Starting")}=1

由于不希望因为关闭所有问题,而导致一些关键的故障根源问题也被以某种方式关闭。这时候就需要标签功能登场。

问题事件和恢复事件可以通过触发器配置中指定的标签匹配。以下配置会达成这一目的:

  • 设定 问题事件生成模式多重

  • 设定 正常事件关闭标签匹配的所有问题

  • 配置特定tag的名称用于事件匹配

  • 配置事件标签从日志中提取标签的值

1 基于触发器的事件关联 - 图2

如果配置成功,你能够看到依据应用打上的问题事件标签,并在监测中问题页面看到结果相匹配的问题被解决

1 基于触发器的事件关联 - 图3

因为当为不相关的问题创建相似的事件标签时,有可能出现错误配置,请依据下面方法研究配置!

  • 在两个应用程序将错误和恢复消息写入同一日志文件的情况下,用户可以在标签配置中,使用{ITEM.VALUE}宏,并使用特定的正则表达式过滤宏的值(例如,日志的不同消息格式),以获取应用程序A和应用程序B的名称。从而在一个触发器中配置匹配具有不同标签的应用程序。但是,如果与正则表达式不匹配,则这可能无法按计划进行。不匹配的正则表达式将在问题和OK事件中产生空标记值,并且单个空标记值足以将它们关联起来。因此,来自应用程序A的恢复消息可能会意外关闭来自应用程序B的错误消息。

  • 实际上标签和标签的值只有在触发器触发时才会显示。如果所使用的正则表达式无效的话,则会使用默认的字段“UNKNOWN”进行替换。如果错过了标签值“UNKNOWN”的初始问题事件,那么可能会出现与标签值“UNKNOWN”的后续正常事件,并有可能导致关闭不应该关闭的问题事件。

  • 如果用户使用没有宏功能的宏{ITEM.VALUE}作为标签值,则会有255个字符串的限制。当日志消息很长,并且前面255个字符串是不明确的话,就有可能导致类似的事件标签用于不相关的问题上。