Filtering script for rule in Event Processing Policy

[victor]

Когда-то раньше main() был обязателен, теперь уже нет. Но старая форма все равно поддерживается.

Еще можно использовать регулярные выражения, например так:

return $event->message ~= ".*Interface \"Vi.*";

Ну и если речь идет о событиях SYS_IF_UP и SYS_IF_DOWN, то имя интерфейса передается как параметр номер 2, и можно сравнивать только его (тогда условие не будет зависеть от того, что текст сообщения поменяют в шаблоне):

return $2 like "Vi*";

или

return substr($2, 1, 2) == "Vi";

ну и если в названии могут быть прописные и строчные буквы:

return upper(substr($2, 1, 2)) == "VI";

[enp]

Спасибо! Я верно понимаю, все возможные параметры к событиям описаны в Configuration -> Event configuration?

И вопрос о запуске скриптов вручную по-прежнему актуален.

[victor]

@enp said in Filtering script for rule in Event Processing Policy:

Спасибо! Я верно понимаю, все возможные параметры к событиям описаны в Configuration -> Event configuration?

да, верно.

@enp said in Filtering script for rule in Event Processing Policy:

И вопрос о запуске скриптов вручную по-прежнему актуален.

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

nxevent -u admin 192.168.64.1 5 101 eth0 10.10.10.2 255.255.255.0 1

[enp]

А скрипт может что-либо вывести в лог/консоль? Как это увидеть?

[enp]

Просто ваши примеры не работают - такое ощущение, что в $2 попадает совсем не имя интерфейса

[victor]

Можно вывести в лог, функцией trace. Например так:

trace(0, "$2='" . $2 . "'");

[enp]

Спасибо!

С помощью trace удалось сформулировать правило так:

return !($event->name like "SYS_IF_*" && $event->parameters[2] like "Vi*");

Наверное, это самый правильный вариант.

[enp]

А куда и в каких случаях выводит данные функция println?

[victor]

println выводит данные на консоль, ее имеет смысл использовать либо в тестовых скриптах, которые запускаются из nxscript, либо в скриптах, которые запускаются из дебаг консоли сервера командой exec.

[enp]

$ nxscript
NetXMS Scripting Host  Version 1.2.10
Copyright (c) 2005-2013 Victor Kirhenshtein

Usage: nxscript [options] script [arg1 [... argN]]

Valid options are:
   -d         Dump compiled script code
   -e <name>  Entry point
   -r         Print script return value

Что такое entry point? Объекты вроде $event в nxscript передать нельзя?

[glebofff]

enp, настоятельно рекомендую уже быстрее проникнуться концепцией NetXMS.

Передать $event из командной строки нельзя, но можно сгенерировать событие (из скрипта - PostEvent, из командной строки - утилитой nxevent), на которое среагирует обработчик, в котором есть фильтрующий скрипт.

Создай тестовый объект, тестовое событие, тестовый обработчик, и т.д.

[enp]

Не вижу, чем передача $event и любых объектов вообще из командной строки идет поперек концепции. Это просто более прямой способ отладки скриптов. Похоже, он действительно не востребован из-за того, что скрипты обычно маленькие и отлаживать там особо нечего.

Я ж не с претензиями, я всего лишь вопросы задаю

[glebofff]

nxevent + trace - куда прямее?