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 

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

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

• Режим генерации событий 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 символов не содержат специфики, это также может привести к похожим тегам событий для несвязанных проблем.