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

Обзор

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

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

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

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

Иными словами, один и тот же триггер может создавать отдельные события, идентифицируемые по тегу события. Поэтому события проблемы можно идентифицировать по одному и закрывать отдельно на основе идентификации по тегу события.

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

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

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

Идея корреляции событий заключается в том, чтобы сопоставить событие проблемы из Line1 с решением из Line3, а событие проблемы из Line2 с решением из Line4, и закрывать эти проблемы по одной:

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

Line2: Service 2 stopped
Line4: Service 2 was restarted #problem from Line 2 closed

Для этого нужно пометить эти связанные события, например, как "Service 1" и "Service 2". Это можно сделать, применив регулярное выражение к строке журнала, чтобы извлечь значение тега. Затем, когда события создаются, им присваиваются теги "Service 1" и "Service 2" соответственно, и проблема может быть сопоставлена с решением.

Конфигурация

Элемент данных

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

log[/var/log/syslog]

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

Триггер

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

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

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

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

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

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

• Режим генерации событий Problem: Multiple
• Событие OK закрывает: Все проблемы, если значения тегов совпадают
• Введите имя тега для сопоставления событий

• настройте теги, чтобы извлекать значения тегов из строк журнала

Если настройка выполнена успешно, вы сможете видеть события проблем, помеченные по приложению и сопоставленные с их устранением в Monitoring > Problems.

• Индексированные макросы всегда относятся к полю Expression в настройках триггера, а не к Recovery expression. Например, в событии восстановления {ITEM.VALUE1} будет разрешен в последнее значение первого элемента данных в выражении проблемы на момент восстановления. Если выражение восстановления основано на другом элементе данных, а значение элемента данных из выражения проблемы изменится к моменту восстановления, события получат разные теги и не будут сопоставлены.

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

• Фактические теги и значения тегов становятся видимыми только при срабатывании триггера. Если используемое регулярное выражение недопустимо, оно без предупреждения заменяется строкой *UNKNOWN*. Если исходное событие проблемы со значением тега *UNKNOWN* было пропущено, могут появиться последующие события OK с тем же значением тега *UNKNOWN*, которые закроют события проблемы, которые не должны были быть закрыты.

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