[comment]: # ({69aa4121-69aa4121})
# 1 基于触发器的事件关联

[comment]: # ({/69aa4121-69aa4121})

[comment]: # ({61c380c5-f01b1f93})
#### 概述

基于触发器的告警关联功能允许将单个触发器报告的多个独立问题进行关联处理。

虽然通常一个OK事件可以关闭由单个触发器生成的所有问题事件，但在某些场景下需要更精细的处理方式。例如，在监控日志文件时，您可能希望针对日志file中的特定问题进行独立发现和单独关闭，而非批量处理。

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

Zabbix支持基于[tagging](/manual/config/tagging)来关联问题事件。系统通过标签提取数值，并利用create功能对问题事件进行标识。基于此机制，还可以通过匹配标签来单独关闭特定问题。

换言之，同一个触发器可以通过事件标签create来区分不同事件。因此，系统能够基于事件标签逐个识别问题事件，并进行独立关闭操作。

[comment]: # ({/61c380c5-f01b1f93})

[comment]: # ({12f3de38-12f3de38})
#### 工作原理

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

    Line1: Application 1 stopped
    Line2: Application 2 stopped
    Line3: Application 1 was restarted
    Line4: Application 2 was restarted

事件关联的理念在于能够将Line1的问题事件
与Line3的解决措施相匹配，以及将Line2的问题事件
与Line4的解决措施相匹配，并逐个关闭这些问题：

    Line1: Application 1 stopped
    Line3: Application 1 was restarted #problem from Line 1 closed

    Line2: 应用程序2已停止

    Line4: Application 2 was restarted #problem from Line 2 closed

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

[comment]: # ({/12f3de38-12f3de38})

[comment]: # ({5d32b87c-5d32b87c})
#### 配置

[comment]: # ({/5d32b87c-5d32b87c})

[comment]: # ({8d1971f2-8d1971f2})
##### 监控项

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

    log[/var/log/syslog]

![](../../../../assets/en/manual/config/event_correlation/correlation_item.png)

设置好监控项后，等待一分钟让配置变更生效，
然后前往[Latest
data](/manual/web_interface/frontend_sections/monitoring/latest_data)确认
监控项已开始收集数据。

[comment]: # ({/8d1971f2-8d1971f2})

[comment]: # ({57e60c4e-57e60c4e})
##### 触发器

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

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

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

:::

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

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

由于我们不希望这种情况发生，必须确保对应的根问题被关闭，而不仅仅是所有问题。这时标签功能就能发挥作用。

通过在触发器配置中指定标签，可以匹配问题和解决方案。需进行以下设置：

-   *问题事件生成模式*: Multiple
-   *OK事件关闭*: 所有标签值匹配的问题
-   输入用于事件匹配的标签名称

![](../../../../assets/en/manual/config/event_correlation/correlation_trigger.png)

-   配置[tags](/manual/config/tagging)以提取标签值

    from log lines

![](../../../../assets/en/manual/config/event_correlation/correlation_trigger2.png)

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

![](../../../../assets/en/manual/config/matched_problems.png){width="600"}

::: notewarning
由于可能存在配置错误，当为**不相关**的问题创建相似事件标签时，请仔细检查以下情况！

:::

-   当两个应用程序同时向
    same log file a user may decide to use two *Application* tags in the
    same trigger with different tag values by using separate regular
    expressions in the tag values to extract the names of, say,
    application A and application B from the {ITEM.VALUE} macro (e.g.
    when the message formats differ). However, this may not work as
    planned if there is no match to the regular expressions.
    Non-matching regexps will yield empty tag values and a single empty
    tag value in both problem and OK events is enough to correlate them.
    So a recovery message from application A may accidentally close an
    error message from application B.

写入错误和恢复消息时

```{=html}
<!-- -->
```
-   实际标签和标签值仅在触发器触发时可见

    If the regular expression used is invalid, it is silently replaced
    with an \*UNKNOWN\* string. If the initial problem event with an
    \*UNKNOWN\* tag value is missed, there may appear subsequent OK
    events with the same \*UNKNOWN\* tag value that may close problem
    events which they shouldn't have closed.

```{=html}
<!-- -->
```
-   如果用户使用{ITEM.VALUE}宏作为标签值而不使用宏函数，将受到255字符限制。当日志消息较长且前255字符非特异性时，也可能导致不相关问题产生相似事件标签。

[comment]: # ({/57e60c4e-57e60c4e})