Некорректное разрешение значения ITEM.LASTVALUE<1-9> в имени триггера

[Alex S]

Есть шаблон, в котором собираются разные события из Eventlog Windows (например создание пользователя, удаление, блокировка и т.д.)
В качестве примера вот такой триггер

Name:
Админ {ITEM.LASTVALUE2} создал пользователя {ITEM.LASTVALUE3} на {HOST.NAME}
Expression:
{Template App_ EventLogUserAD:eventlog[Security,,,,4720].last()}<>0 and {Template App_ EventLogUserAD:eventlog.user.create.masteraccount. last()}<>0 and {Template App_ EventLogUserAD:eventlog.user.create.targetaccount. last()}<>0 and {Template App_ EventLogUserAD:eventlog[Security,,,,4720].nodata(60)}=0

Идея в том, чтобы в имени триггера были данные о том кто какого пользователя создал
Идея работает, но не так, как предполагается.
Почему-то макросы {ITEM.LASTVALUE2} и {ITEM.LASTVALUE3} разрешаются не в ПОСЛЕДНЕЕ значение из History а во второе (предпоследнее) значение
т.е. создаем пользователя, получаем запись в логе, заббикс видит ее, получает корректные значения (видно в History) приходит триггер, но в имени триггера - предыдущие значения

Подскажите, куда копать? Не понимаю, почему так происходит.

[Semiadmin]

А eventlog.user.create.masteraccount и eventlog.user.create.targetaccount - айтемы, зависимые от eventlog[Security,,,,4720] ?

[Alex S]

А eventlog.user.create.masteraccount и eventlog.user.create.targetaccount - айтемы, зависимые от eventlog[Security,,,,4720] ?

Да.
eventlog[Security,,,,4720] - это то, что прилетает из Windows Eventlog в чистом виде
eventlog.user.create.masteraccount - это зависимый айтем, который через препроцессинг и Regexp получает имя администратора, который создал пользователя
eventlog.user.create.targetaccount - также зависимый айтем, который тоже через препроцессинг и Regexp получает targetname - имя нового созданного пользователя

[Semiadmin]

Я бы, наверное, не брал из зависимых, а макрофункцией {{ITEM.VALUE}.regsub(pattern, output)} тащил нужное прямо из eventlog[Security,,,,4720] в имя триггера

[Alex S]

Я бы, наверное, не брал из зависимых, а макрофункцией {{ITEM.VALUE}.regsub(pattern, output)} тащил нужное прямо из eventlog[Security,,,,4720] в имя триггера

Попробовал.
но что-то не получается. Не обрабатывает он Regsub - пишет ее просто текстом и все, может я синтаксис где-то напутал...

Вот так назвал макрос:
Админ {{ITEM.VALUE}.regsub(Account Name:\t\t(.*), \1)} создал пользователя {{ITEM.VALUE}.regsub(New Account.|\n)*\tAccount Name:\t\t(.*), \2)} на {HOST.NAME}

где
Account Name:\t\t(.*) это regexp для выборки имени админа
New Account.|\n)*\tAccount Name:\t\t(.*) это regexp для выборки имени пользователя

на выходе получил вот такое (т.е. он берет нормальное последее значение всего события, но не обрабатывает его regsub а просто дописывает в конце этот regsub и все

Админ {A user account was created. Subject: Security ID: DOMAIN\adminaccount Account Name: adminaccount Account Domain: DOMAIN Logon ID: 0x522E5F28 New Account: Security ID: DOMAIN\qwas Account Name: qwas Account Domain: DOMAIN Attributes: SAM Account Name: qwas Display Name: qwas User Principal Name: [email protected] Home Directory: - Home Drive: - Script Path: - Profile Path: - User Workstations: - Password Last Set: <never> Account Expires: <never> Primary Group ID: 513 Allowed To Delegate To: - Old UAC Value: 0x0 New UAC Value: 0x15 User Account Control: Account Disabled 'Password Not Required' - Enabled 'Normal Account' - Enabled User Parameters: - SID History: - Logon Hours: <value not set> Additional Information: Privileges -.regsub(Account Name:\t\t(.*), \1)} создал пользователя {A user account was created. Subject: Security ID: DOMAIN\adminaccount Account Name: adminaccount Account Domain: DOMAIN Logon ID: 0x522E5F28 New Account: Security ID: DOMAIN\qwas Account Name: qwas Account Domain: DOMAIN Attributes: SAM Account Name: qwas Display Name: qwas User Principal Name: [email protected] Home Directory: - Home Drive: - Script Path: - Profile Path: - User Workstations: - Password Last Set: <never> Account Expires: <never> Primary Group ID: 513 Allowed To Delegate To: - Old UAC Value: 0x0 New UAC Value: 0x15 User Account Control: Account Disabled 'Password Not Required' - Enabled 'Normal Account' - Enabled User Parameters: - SID History: - Logon Hours: <value not set> Additional Information: Privileges -.regsub(New Account.|\n)*\tAccount Name:\t\t(.*), \2)} на DC02

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

[Alex S]

Ага
Кажется получилось
Кавычек не хватало для шаблона регекспа

Тогда получается зависимые айтемы не нужны вовсе? я их делал исключительно чтоб удобно было получать имена пользовтаелей...

[Semiadmin]

Если только для этого - то да. А предположение насчет запаздывания создания зависимых айтемов - верное.

[Alex S]

Если только для этого - то да. А предположение насчет запаздывания создания зависимых айтемов - верное.

Спасибо большое, очень помогли!
Остановился на варианте с макрофункцией - его пока достаточно, и шаблон упрощается (уходят все эти зависимые айтемы)
Про запаздывание - ок, но тогда вариант с триггером на основе уже зависимого айтема должен был сработать (он же случится когда зависимый айтем УЖЕ создастся) - но у меня почему то результат был тот же
Ну да ладно.

А может еще подскажете, если делается массовое действие (выделили несколько учеток и забанили их) то триггер прилетает только на одну, условно последнюю.
Можно сделать так, чтоб на все забаненные прилетал?
У меня в триггере условие - {Template App_ EventLogUserAD:eventlog[Security,,,,4720].nodata(60)}=0 - чтоб проблема автозакрывалась через минуту
И полагаю именно это условие не дает создавать дополнительные триггеры, которые случаются почти что в ту же самую секунду при массовых действиях

Можно как-то это победить?
Чтобы на каждую забаненную учетку прилетат триггер, даже если ее банили "в массовом режиме" (в пределах 1-2 сек)

[Semiadmin]

Обычно это решается через PROBLEM event generation mode - Multiple.

[Kos]

Alex S, приветствую!

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

По второй проблеме - сочетание "PROBLEM event generation mode - Multiple" и временнЫх триггерных функций (включая nodata()) - давняя проблема.
К сожалению, такое сочетание работает плохо и поэтому официально не поддерживается.
Я ещё во времена версии 2.0.x создал тикет на эту тему с подробным описанием проблемы, примерами и предлагаемым решением, после чего неоднократно призывал голосовать за него (один из типичных примеров, последний - тут), но пока что воз и ныне там. Разве что теперь документировано "костыльное" решение, как это можно обойти (см. последнюю ссылку).

[Alex S]

Alex S, приветствую!

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

По второй проблеме - сочетание "PROBLEM event generation mode - Multiple" и временнЫх триггерных функций (включая nodata()) - давняя проблема.
К сожалению, такое сочетание работает плохо и поэтому официально не поддерживается.
Я ещё во времена версии 2.0.x создал тикет на эту тему с подробным описанием проблемы, примерами и предлагаемым решением, после чего неоднократно призывал голосовать за него (один из типичных примеров, последний - тут), но пока что воз и ныне там. Разве что теперь документировано "костыльное" решение, как это можно обойти (см. последнюю ссылку).

Ооооо...
Круто, спасибо за развернутое описание. в FAQ прямо по полочкам разложено все.
Про Problem-Multiple - да, я уже попробовал и понял что не подойдет.
Что ж... зарегистрировался, проголосовал за тикет )