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

Обзор

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

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

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

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

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

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

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

Строка1: Service 1 stopped
Строка2: Service 2 stopped
Строка3: Service 1 was restarted
Строка4: Service 2 was restarted

Идея корреляции событий заключается в том, чтобы сопоставить событие проблемы из Строки1 с устранением из Строки3, а событие проблемы из Строки2 с устранением из Строки4 и закрыть эти проблемы по одной:

Строка1: Service 1 stopped
Строка3: Service 1 was restarted #проблема из Строки 1 закрыта

Строка2: Service 2 stopped
Строка4: Service 2 was restarted #проблема из Строки 2 закрыта

Для этого необходимо пометить эти связанные события, например, тегами "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 

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

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

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

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

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

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

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

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

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