value = GetCustomAttribute(int, "ImportantInterface");
if (value == null)  // нет такого атрибута
{
   int->setExpectedState(0); // UP
}

status propagation из скрипта поменять нельзя.

@hsvt said in Filtering script и эвент исключения:

А пример фильтрации в EPP можете привести ?

Вроде про hook скрипты шла речь? Скрипт из примера можно модифицировать так:

if ($node->snmpOID ~= "^.1.3.6.1.4.1.X")
{
	foreach(int : GetNodeInterfaces($node))
	{
		if ((int->name ~= "^eth[0-9]*\.") && (GetCustomAttribute(int, "ImportantInterface") != "yes"))
		{
                     // do what is needed
	        }
	}
}

Не будут обрабатываться интерфейсы у которых custom attribute ImportantInterface выставлен в yes.

@hsvt said in Filtering script и эвент исключения:

 И правильно ли я понимаю, если мне нужно для этой же группы серверов и клиентских интерфейсов сделать SYS_IF_DOWN с severity Normal, я создал еще одно EPP и поместил туда группу этих серверов (в Source Object) ну и далее Alarm Severity Normal, но как правильно сделать чтобы не пересекалось с основным EPP ?

Есть два варианта - либо в основном правиле добавить исключение для контейнера (добавить контейнер в список source и поставить negate), либо в первом правиле (для контейнера) добавить "stop processing" - тогда обработка события для этого контейнера будет остановлена на этом правиле.

Никак не могу сообразить, как бы в скрипте добавить проверку на то, что если Custom Attribute сняли с интерфейса - вернуть его прошлый SetInterfaceExpectedState и setStatusPropagation в default ?

А пример фильтрации в EPP можете привести ?

Вроде про hook скрипты шла речь? Скрипт из примера можно модифицировать так:

if ($node->snmpOID ~= "^.1.3.6.1.4.1.X")
{
	foreach(int : GetNodeInterfaces($node))
	{
		if ((int->name ~= "^eth[0-9]*\.") && (GetCustomAttribute(int, "ImportantInterface") != "yes"))
		{
                     // do what is needed
	        }
	}
}

Не будут обрабатываться интерфейсы у которых custom attribute ImportantInterface выставлен в yes.

@hsvt said in Filtering script и эвент исключения:

 И правильно ли я понимаю, если мне нужно для этой же группы серверов и клиентских интерфейсов сделать SYS_IF_DOWN с severity Normal, я создал еще одно EPP и поместил туда группу этих серверов (в Source Object) ну и далее Alarm Severity Normal, но как правильно сделать чтобы не пересекалось с основным EPP ?

Есть два варианта - либо в основном правиле добавить исключение для контейнера (добавить контейнер в список source и поставить negate), либо в первом правиле (для контейнера) добавить "stop processing" - тогда обработка события для этого контейнера будет остановлена на этом правиле.

@hsvt said in Filtering script и эвент исключения:

У меня для тех у кого ignore (абоненты, например) эвент не генерируется, состояние нормал, Иконки в разделе Ports - красные. Другой вопрос, если бывает, нужно поставить на мониторинг абонентский порт с какой нибудь плавающей проблемой, а у тебя по Hook::ConfigurationPoll всё равно будет ставиться Ignore. Как вот тут лучше сделать?

Можно проверять custom attribute интерфейса и не ставить ему ignore если атрибут выставлен в какое-то специальное значение.

А пример фильтрации в EPP можете привести ? И правильно ли я понимаю, если мне нужно для этой же группы серверов и клиентских интерфейсов сделать SYS_IF_DOWN с severity Normal, я создал еще одно EPP и поместил туда группу этих серверов (в Source Object) ну и далее Alarm Severity Normal, но как правильно сделать чтобы не пересекалось с основным EPP ?

У меня для тех у кого ignore (абоненты, например) эвент не генерируется, состояние нормал, Иконки в разделе Ports - красные. Другой вопрос, если бывает, нужно поставить на мониторинг абонентский порт с какой нибудь плавающей проблемой, а у тебя по Hook::ConfigurationPoll всё равно будет ставиться Ignore. Как вот тут лучше сделать?

Можно проверять custom attribute интерфейса и не ставить ему ignore если атрибут выставлен в какое-то специальное значение.

Ну и с почтой и эвентом SYS_NODE_DOWN тоже не понятно, надо чтобы от одних устройств были только алармы, а от других и алармы и письма еще...

А как эти устройства различаются? Самое простое - положить все устройства где нужна почта в отдельный контейнер, и в EPP отсылку писем фильтровать еще и по контейнеру. Другой вариант - использовать custom attributes для отметки устройств, по которым надо почту слать.

Кстати вопрос - если я ставлю для интерфейса expected state = ignore, то изменение состояния не должно генерировать event, но его состояние все равно опрашивается. Почему у интерфейсов в состоянии down все равно зеленая иконка?

У меня для тех у кого ignore (абоненты, например) эвент не генерируется, состояние нормал, Иконки в разделе Ports - красные. Другой вопрос, если бывает, нужно поставить на мониторинг абонентский порт с какой нибудь плавающей проблемой, а у тебя по Hook::ConfigurationPoll всё равно будет ставиться Ignore. Как вот тут лучше сделать?

Ну и с почтой и эвентом SYS_NODE_DOWN тоже не понятно, надо чтобы от одних устройств были только алармы, а от других и алармы и письма еще...

Для абонентских портов можно делать unmanage при помощи Hook::ConfigurationPoll например так:

if ($node->snmpOID ~= "^.1.3.6.1.4.1.X")
{
	foreach(int : GetNodeInterfaces($node))
	{
		if (int->name ~= "^eth[0-9]*\.")
		{
	      UnmanageObject (int);
	    }
	}
}

У меня такое сделано для абонентских портов на коммутаторе, но я решил мониторить в NetXMS так же сервера доступа (NAS,BRAS) в сеть интернет. Там так же для них создаются интерфейсы (сабинтерфейсы), так вот скрипт  Hook::ConfigurationPoll он и так уже достаточно большой, поэтому я думаю может лучше как то сделать в EPP через Filtering Script ? Или мне теперь еще и под каждый сервер в этот скрипт дописывать? Как то хочется менее костыльно, может в будущем разработчики реализуют основную часть таких моментов в клиенте ? Ну чтобы такую логику и гибкость можно было реализовать...

if ($node->snmpOID ~= "^.1.3.6.1.4.1.X")
{
	foreach(int : GetNodeInterfaces($node))
	{
		if (int->name ~= "^eth[0-9]*\.")
		{
	      UnmanageObject (int);
	    }
	}
}