[comment]: # ({69aa4121-69aa4121})
# 1. Корреляция событий на основе триггеров

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

[comment]: # ({61c380c5-f01b1f93})
#### Обзор

Корреляция событий на основе триггеров позволяет сопоставлять отдельные проблемы, о которых сообщает один триггер.

В то время как в большинстве случаев события ОК могут закрывать все события о проблеме, созданные одним триггером, бывают случаи, когда необходим более обстоятельный подход. Например, при мониторинге файлов журналов вы можете захотеть обнаруживать некоторые проблемы в файле журнала и закрывать их по отдельности, а не все разом.

Это тот случай, когда у триггеров параметр *Режим генерации событий ПРОБЛЕМА* выставлен в значение *Множественный*. Такие триггеры обычно используются для мониторинга журналов, обработки трапов и т.п.

В Zabbix имеется возможность сопоставить события о проблемах, основываясь на [тегах событий](/manual/config/tagging). Теги используются для извлечения значений и создания метки по событиям о проблемах. Используя преимущества такого подхода, проблемы могут быть закрыты отдельно на основании совпадения тега.

Другими словами, один триггер может создавать отдельные события, которые идентифицируются при помощи тега событий. Следовательно, события о проблемах могут быть идентифицированы каждый по отдельности и закрыты индивидуально на основании метки тега события.

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

[comment]: # ({12f3de38-12f3de38})
#### Как это работает

В мониторинге журналов вы можете встретиться со строками, похожими на эти:

    Строка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» соответственно, и проблема может быть сопоставлена с решением.

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

[comment]: # ({5d32b87c-5d32b87c})
#### Настройка

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

[comment]: # ({8d1971f2-8d1971f2})
##### Элемент данных

Для начала вы можете настроить элемент данных, который мониторит файл журнала, например:

    log[/var/log/syslog]

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

Когда элемент данных будет настроен, подождите минуту, пока изменения конфигурации вступят в силу, и затем перейдите в [Последние данные](/manual/web_interface/frontend_sections/monitoring/latest_data), чтобы убедиться, что элемент данных начал собирать данные.

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

[comment]: # ({57e60c4e-57e60c4e})
##### Триггер

Когда элемент данных заработал, вам необходимо настроить [триггер](/manual/config/triggers/trigger). Важно решить, на какие записи в файле журнала необходимо обратить внимание. Например, следующее выражение триггера будет искать строки, которые содержат 'Stopping', для предупреждения о возможных проблемах:

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

::: noteimportant
Чтобы убедиться, что каждая строка, которая содержит подстроку «Stopping», считается проблемой, также в настройках триггера выставьте *Режим генерации событий ПРОБЛЕМА* в значение «Множественный».
:::

Затем определим выражение восстановления. Следующие выражение решит все проблемы, если в журнале будет найдена строка, содержащая подстроку «Starting»:

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

Поскольку мы этого не хотим, важно каким-то образом убедиться, что закрываются только нужные проблемы, а не просто все проблемы. Вот где могут помочь теги.

Проблемы и решения можно сопоставить, указав в настройках триггера тег. Необходимо выполнить следующие настройки:

-   *Режим генерации событий ПРОБЛЕМА*: Множественный
-   *ОК событие закрывает*: Все проблемы если значения тегов совпадают
-   Введите имя тега для сопоставления событий

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

-   настройка [тегов](/manual/config/tagging) для извлечения значений тегов из строк журнала

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

Если настройка выполнена успешно, вы сможете увидеть события о проблемах с тегами по приложению и сопоставление с их решением в *Мониторинг* → *Проблемы*.

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

::: notewarning
Посколько возможна некорректная настройка, когда аналогичные теги событий могут быть созданы по **не связанным** проблемам, пожалуйста, ознакомьтесь со случаями, которые описаны ниже!
:::

-   При наличии двух приложений, которые пишут сообщения об ошибках и восстановлениях в один и тот же файл журнала, пользователь может решить использовать два тега *Application* в одном и том же триггере с разными значениями тегов с использованием отдельных регулярных выражений в значениях тегов, чтобы извлечь имена (скажем, приложение A и приложение B) из макроса {ITEM.VALUE} (например, когда форматы сообщений отличаются). Однако, такой подход может не сработать как планируется, если не будет соответствия регулярным выражениям. Не соответствующие регулярные выражения дадут пустые значения тегов, а одного пустого значения тега в событиях как проблемы, так и OK, будет достаточно, чтобы сработала корреляция. Таким образом, сообщение о восстановлении с приложения A может случайно закрыть сообщение об ошибке от приложения B.

```{=html}
<!-- -->
```
-   Фактические теги и значения тегов становятся видны только при срабатывании триггера. Если используемое регулярное выражение ошибочно, оно автоматически заменится на строку \*НЕИЗВЕСТНО\*. Если изначальное событие о проблеме с \*НЕИЗВЕСТНО\* пропущено, могут появиться последующие события OK с таким же значением тега \*НЕИЗВЕСТНО\*, которые могут закрыть события о проблеме, которые они не должны были бы закрывать.

```{=html}
<!-- -->
```
-   Если пользователь для значения тега использует макрос {ITEM.VALUE} без функций макросов, то будет применяться ограничение по длине строки в 255 символов. Когда в журнале имеются длинные сообщения и первые 255 символов не конкретизируют проблему, это может привести к одинаковым тегам событий по не связанным проблемам.

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