1. Корреляция событий на основе триггеров

Обзор

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

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

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

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

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

Как это работает

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

Строка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

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

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

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

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

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

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

настройка тегов для извлечения значений тегов из строк журнала

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

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

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

Фактические теги и значения тегов становятся видны только при срабатывании триггера. Если используемое регулярное выражение ошибочно, оно автоматически заменится на строку *НЕИЗВЕСТНО*. Если изначальное событие о проблеме с *НЕИЗВЕСТНО* пропущено, могут появиться последующие события OK с таким же значением тега *НЕИЗВЕСТНО*, которые могут закрыть события о проблеме, которые они не должны были бы закрывать.

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

Documentation