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', чтобы сигнализировать о потенциальных проблемах:

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

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

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

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

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

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

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

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

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

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

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

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

Documentation