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

Обзор

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

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

Это тот случай, когда у триггеров включена опция Формирование множественных Проблема событий. Такие триггеры обычно используются для мониторинга журналов, обработки трапов и т.п.

В 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

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

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

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

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

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

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

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

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

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

Documentation