Filtering script и эвент исключения

hsvt

Здравствуйте. Возникла необходимость создать исключения для обработки EPP SYS_IF_DOWN, есть нода, например, там сабинтерфейсы (клиентские) могут подниматься и опускать по много раз. В связи с этим их не хотелось бы обрабатывать и получать кучу алармов, нужно прибегнуть к Filtering Script или дописывать исключения по интерфейсам в Hook::ConfigurationPoll ? Хотелось бы попробовать с помощью Filtering Script, можете подсказать как это сделать на примере интерфейса eth0.1 eth02.3 и т.д.

И еще вопрос по исключениям из обработки SYS_NODE_DOWN, необходимо сделать следующее: есть коммутаторы, по которым должны приходить alarm SYS_NODE_DOWN и есть сервера по которым должны приходить как alarm так и action email. Если я делаю Inverted Rule - то не совсем подходит, мне нужно получать только алармы и только от коммутаторов если они down и получать алармы и письма от серверов если они down.

Harun

Для абонентских портов можно делать 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);
	    }
	}
}

hsvt

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

Для абонентских портов можно делать 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 ? Или мне теперь еще и под каждый сервер в этот скрипт дописывать? Как то хочется менее костыльно, может в будущем разработчики реализуют основную часть таких моментов в клиенте ? Ну чтобы такую логику и гибкость можно было реализовать...

Harun

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

hsvt

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

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

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

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

Victor Kirhenshtein

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

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

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

Victor Kirhenshtein

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

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

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

hsvt

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

@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 ?

Victor Kirhenshtein

@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" - тогда обработка события для этого контейнера будет остановлена на этом правиле.

hsvt

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

@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 ?

Victor Kirhenshtein

например так:

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

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

NetXMS Forum

Filtering script и эвент исключения