NetXMS Support Forum

Здравствуйте. Возникла необходимость создать исключения для обработки 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.

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


Quote from: Harun on October 30, 2015, 02:46:34 PM
Для абонентских портов можно делать unmanage при помощи Hook::ConfigurationPoll например так:

Code Select Expand


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

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

Quote from: Harun on October 31, 2015, 09:35:47 PM
Кстати вопрос - если я ставлю для интерфейса expected state = ignore, то изменение состояния не должно генерировать event, но его состояние все равно опрашивается. Почему у интерфейсов в состоянии down все равно зеленая иконка?

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

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

Quote from: hsvt on November 05, 2015, 10:47:44 PM
Ну и с почтой и эвентом SYS_NODE_DOWN тоже не понятно, надо чтобы от одних устройств были только алармы, а от других и алармы и письма еще...

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

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

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

Quote from: Victor Kirhenshtein on November 06, 2015, 12:52:07 PM

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

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

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

Quote from: hsvt on November 10, 2015, 03:52:48 PM
А пример фильтрации в 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.

Quote from: hsvt on November 10, 2015, 03:52:48 PM
И правильно ли я понимаю, если мне нужно для этой же группы серверов и клиентских интерфейсов сделать SYS_IF_DOWN с severity Normal, я создал еще одно EPP и поместил туда группу этих серверов (в Source Object) ну и далее Alarm Severity Normal, но как правильно сделать чтобы не пересекалось с основным EPP ?

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

Quote from: Victor Kirhenshtein on November 10, 2015, 10:46:10 PM

Quote from: hsvt on November 10, 2015, 03:52:48 PM
А пример фильтрации в EPP можете привести ?

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

Code Select Expand


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.

Quote from: hsvt on November 10, 2015, 03:52:48 PM
И правильно ли я понимаю, если мне нужно для этой же группы серверов и клиентских интерфейсов сделать SYS_IF_DOWN с severity Normal, я создал еще одно EPP и поместил туда группу этих серверов (в Source Object) ну и далее Alarm Severity Normal, но как правильно сделать чтобы не пересекалось с основным EPP ?

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

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

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


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


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