Регулярное выражение при поиске в логе

[m.hiriyanov]

Добрый день
Версия сервера - 6.0.20
Агент2 - 6.0.21
Необходимо найти Windows логи с определенным текстом внутри. Сам лог по номеру находится по ключу - eventlog[Security,,,,6273,,skip],
Как правильно составить регулярное выражение, чтобы найти логи с текстом внутри? Пробую eventlog[Security,*search_text*,,,6273,,skip] или eventlog[Security,\bsearch_text.*\b,,,6273,,skip]. Выдаёт пустое значение, как-будто не проходит проверка.
Спасибо

[Kos]

Что вы подразумеваете под "найти"?

Сам элемент данных с ключом eventlog[Security,,,,6273,,skip] должен выбирать из соответствующего лога все события с EventID, включающими в себя подстроку "6273" (поскольку пятый параметр - это регулярное выражение). Это у вас происходит? В Latest data соответствующие события из Event Log-а видны?
Если нет - нужно разбираться, почему. Если да - то нужно понять, что вы хотите дальше, поскольку возможны варианты.
Вариант1: используя существующий работающий элемент данных, настроить триггер, который бы реагировал только на конкретные события (содержащие нужную строку). Тогда это делается правильным выражением в триггерной формуле.
Вариант2: вы хотите вместо этого элемента данных (или дополнительно к нему) создать другой, который бы собирал только сообщения с данной подстрокой в тексте сообщения. Тогда вы идёте тем путём, который сами описали (только я бы второй параметр взял бы в кавычки).

[m.hiriyanov]

Добрый день
Спасибо за ответ
eventlog[Security,,,,6273,,skip] собирает события.
Дальше хотелось бы получать алерт при появлении определённого события.
Вариант1: Спасибо, попробую
Вариант2: Как раз по этому пути и шёл. Предполагал, что здесь eventlog[name,<regexp>,<severity>,<source>,<eventid>,<maxli nes>,<mode>] можно отсечь лишние события.

[Kos]

Спасибо за ответ, успехов!
Сразу хотел бы уточнить: при любом варианте нужно продумывать, при каком условии вы этот триггер будете гасить.
Самый простой вариант: гасить вручную (ибо версия 6.0 позволяет ручное закрытие проблемы, если в настройках триггера выставлен соответствующий флажок).
Далее опять же, возможны разные варианты и куча потенциальных граблей.

Например, если идти по Варианту1 выше, то можно в условии триггера проверять наличие нужной подстроки в тексте. Тогда, если такая строка есть, то триггер сгенерирует проблему, а если её нет - то закроет. Потенциальные грабли: закрытие проблемы будет зависеть от наличия других данных, которые к этой проблеме не относятся.

Если идти по Варианту2, то любые новые данные в данном айтеме будут относиться исключительно к интересующей вас проблеме (поскольку фильтрация делается ещё на стороне агента), т.е. проблему нужно генерировать на любое новое значение. Но по какому критерию закрывать такие проблемы - вопрос хороший. Один из распространённых вариантов - просто по таймеру (например, используя функцию nodata()), но тут потенциальные грабли - несовместимость временнЫх функций с параметром "Multiple event generation", который в данной ситуации как раз, как правило, нужен, чтобы не пропустить новые важные события даже если триггер уже сработал и ещё не закрыт (подробнее смотри в давнем тикете по этой ссылке).

[m.hiriyanov]

Так сказать, для самообразования
Как можно реализовать поиск нужной подстроке в самом итеме, таким ключом eventlog[name,<regexp>,<severity>,<source>,<eventid>,<maxli nes>,<mode>]
Спасибо

[Kos]

Так сказать, для самообразования
Как можно реализовать поиск нужной подстроке в самом итеме, таким ключом eventlog[name,<regexp>,<severity>,<source>,<eventid>,<maxlines>,<mode >]
Спасибо

Да, всё верно.
Например:

eventlog[Security,"искомая строка",,,"^6273$",,skip]

Такой элемент данных должен возвращать только события из Windows Security Log-а, у которых EventId=6273, а в тексте присутствует указанная подстрока.
Имейте в виду, что по умолчанию сравнения чувствительны к регистру букв (case-sensitive). Т.е., например, подстрока "Искомая Строка" будет проигнорирована.