Приоритет алярма в зависимости от номера интерфейса

[wonderboy]

Все привет!

Такой вопрос:
Есть ли какая-нибудь возможность выставлять приоритет алярма в зависимости от интерфейса на коммутаторе?

Например:
На циске порт 1 подключен к серверу, а порт 2 к обычному пользователю. Нужно чтобы после падения порта 1 алярм был CRITICAL, а при падении порта 2 был MAJOR.

Спасибо.

[rostyslav]

Здравствуйте.
Да, можно. Надо в Event Policy Editor'e создать два правила. В Source прописываем ту железку для которой создаем правила, в поле Alarm создаем в обоих один тот же аларм, но с разными приоритетами. В поле Script пишем скрипт такого плана:

sub main()
{
  if ($2 == 1)
  {
      return 1;
  }
}

Будет приходить либо индекс интерфейса (SNMP_LINK_DOWN - трапы), либо его имя (SYS_IF_DOWN - опрос). В зависимости от этого и надо писать условие.

[alk]

Кстати, для таких простых скрипров можно не писать "sub main ...", достаточно $2 == 1

[wonderboy]

Спасибо за помощь, но сразу возник еще один вопрос.

Так как на разном оборудовании разные порты могут быть серверными, транковыми и т.д.
Решил в дескрипшенах писать что-то типа Trunk ... , User ... , Server ...
И иметь всего 3 правила на все устройства.

Пишу в политике для эвента SYS_IF_DOWN скрипт ($2 - содержит имя интерфейса в указанном выше формате):

sub main() {
if ($2 ~= "Trunk")
{
   return 1;
}
}

Но вот видимо не срабатывает, потому что алярмы свой приоритет не меняют.

PS: Stdout куда выводятся print, println это где? Куда нужно смотреть?

[wonderboy]

Попытался выяснить в чем дело и получил вот что:

Даже если не стоит никаких скриптов в policy event editor алярмы выскакивают с severity minor, тоесть ни major, ни critical не отрабатывает. В опциях для политик поставил stop processing if rule match.

 ???

[victor]

В заголовке окна видна пометка "modified". Event processing policy вступает в силу только после того, как она сохранена на сервере. Эти тестовые изменения были сохранены?

[victor]

@wonderboy said in Приоритет алярма в зависимости от номера интерфейса:

Спасибо за помощь, но сразу возник еще один вопрос.

Так как на разном оборудовании разные порты могут быть серверными, транковыми и т.д.
Решил в дескрипшенах писать что-то типа Trunk ... , User ... , Server ...
И иметь всего 3 правила на все устройства.

Пишу в политике для эвента SYS_IF_DOWN скрипт ($2 - содержит имя интерфейса в указанном выше формате):

sub main() {
if ($2 ~= "Trunk")
{
   return 1;
}
}

Но вот видимо не срабатывает, потому что алярмы свой приоритет не меняют.

PS: Stdout куда выводятся print, println это где? Куда нужно смотреть?

Скрипт выглядит правильно. Stdout доступен только если скрипт запущен через nxscript. Приведенный выше скрипт можно протестировать например так:

1. создать файл test.nxsl, скопировать в него скрипт;
2. запустить команду

nxscript -r test.nxsl param1 param2

Результат будет примерно такой:

C:\Source\NetXMS\debug>nxscript -r test6.nxsl param1 param2
NetXMS Scripting Host  Version 1.1.0-rc10
Copyright (c) 2005-2009 Victor Kirhenshtein

Result = (null)

C:\Source\NetXMS\debug>

C:\Source\NetXMS\debug>nxscript -r test6.nxsl param1 Trunk
NetXMS Scripting Host  Version 1.1.0-rc10
Copyright (c) 2005-2009 Victor Kirhenshtein

Result = 1

C:\Source\NetXMS\debug>

Если в скрипте для отладки нужна печать на экран, то можно использовать print / println:

sub main()
{
   println "$2='" . $2 . "'";
   if ($2 ~= "Trunk")
   {
      println "match";
      return 1;
   }
   println "no match";
}

Получим

C:\Source\NetXMS\debug>nxscript -r test6.nxsl param1 param2
NetXMS Scripting Host  Version 1.1.0-rc10
Copyright (c) 2005-2009 Victor Kirhenshtein

$2='param2'
no match
Result = (null)

C:\Source\NetXMS\debug>

C:\Source\NetXMS\debug>nxscript -r test6.nxsl param1 Trunk
NetXMS Scripting Host  Version 1.1.0-rc10
Copyright (c) 2005-2009 Victor Kirhenshtein

$2='Trunk'
match
Result = 1

C:\Source\NetXMS\debug>

[wonderboy]

Всем спасибо! Сейчас все работает как надо. Видимо куда-то очень спешил  и забыл сохранить Event processing policy!