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 символов не конкретизируют проблему, может привести к одинаковым тегам событий по не связанным проблемам.