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 

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

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

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

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

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

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

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

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

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

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

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