NetXMS Support Forum

Сделал карту в NetXMS. Но почему-то устройства имеют статус Critical, если у них есть down интерфейс, хотя я поменял severity таких alarm'ов на minor в Event Processing Policy.

Похоже этот статус с алармами не связан, так как он остается критическим даже после acknowledge/resolve аларма?

Лечится только если ставить Changed interface expected state = ignore или down, первое как я понимаю приведет к потере алармов на интерфейсе, а второе делать муторно.

Есть ли варианты, как это поднастроить?

Можете попробовать по этой теме - https://www.netxms.org/forum/oe-oo/ooee-o-1-2-6/msg9783/#msg9783

QuoteЧтобы убрать статус CRITICAL на портах, статус которых не интересует, можно поменять им expected state на IGNORE.
Это можно делать даже автоматически через configuration poll hook,
используя функцию SetInterfaceExpectedState (http://wiki.netxms.org/wiki/NXSL:SetInterfaceExpectedState

Сами столкнулись с данной проблемой. Но решение тоже не совсем удобное - получается нужно смотреть информацию об интерфейсе чтобы понять на самом деле его состояние сейчас DOWN или же он IGNORE.

Карту какую используете ? Wolrd map или обычную? Когда уже появится интерактивная карта со связими в реальном времени, например, как в The dude

QuoteНо решение тоже не совсем удобное - получается нужно смотреть информацию об интерфейсе чтобы понять на самом деле его состояние сейчас DOWN или же он IGNORE.

Я б сказал, что это вообще не решение, так как приводит к потере мониторинга портов.

QuoteКарту какую используете ? Wolrd map или обычную? Когда уже появится интерактивная карта со связими в реальном времени, например, как в The dude

Если вы про динамическое показывание нагрузки на каналах между устройствами, то NetXMS это умеет (Data Source в Property линка на карте).

Это ещё какое решение, просто вам надо бы поглубже посмотреть в сторону nxsl, посоны.

http://wiki.netxms.org/wiki/NXSL:Interface

У объекта Interface появилось свойство alias, есть name, появились незадокументированные методы setStatusPropagation / setStatusCalculation.

http://wiki.netxms.org/wiki/NXSL_Function_Reference#Object_Management

Тут есть SetInterfaceExpectedState, ManageObject, UnmanageObject.

Cначала прикинем типовой сценарий: вот если это маршрутизатор Cisco, а интерфейс Tu* или Fa*, то этот интерфейс мне не особо критичен, если это Di*, Nu0, Lo* - то вообще игнорим, а вот Gi* мне очень интересны.

Осталось - написать скрипт, который, в зависимости от ваших предпочтений, сделает интерфейсу i:
  - если совсем не интересует - UnmanageObject (i),
  - если интересует, но не совсем - SetInterfaceExpectedState (i, "IGNORE"),
  - если интересует - i->setStatusPropagation (4,1,2,3,3),
  - если интересует очень - оставит всё по-умолчанию.


if (i->node->sysDescription ~= "^Cisco")
{
  if (i->name ~= "^Nu|^Di|^Lo")
  {
    UnmanageObject (i);
  } else  if (i->name ~= "^Fa|^Tu")
  {
    i->setStatusPropagation (4,1,2,3,3);
  } else  if (! i->name ~= "^Gi")
  {
    SetInterfaceExpectedState (i, "IGNORE");
  }
}


Можно без всей этой автоматизации, врукопашную. Но, если узлов тысячи, а тут у некоторых есть такие инсталляции, то придётся тяжко.

PS:

setStatusPropagation (4,1,2,3,3) соответствует картинке, которую я приаттачил.

Quote from: glebofff on January 16, 2015, 06:02:12 AM
Это ещё какое решение, просто вам надо бы поглубже посмотреть в сторону nxsl, посоны.

http://wiki.netxms.org/wiki/NXSL:Interface

У объекта Interface появилось свойство alias, есть name, появились незадокументированные методы setStatusPropagation / setStatusCalculation.

http://wiki.netxms.org/wiki/NXSL_Function_Reference#Object_Management

Тут есть SetInterfaceExpectedState, ManageObject, UnmanageObject.

Cначала прикинем типовой сценарий: вот если это маршрутизатор Cisco, а интерфейс Tu* или Fa*, то этот интерфейс мне не особо критичен, если это Di*, Nu0, Lo* - то вообще игнорим, а вот Gi* мне очень интересны.

Осталось - написать скрипт, который, в зависимости от ваших предпочтений, сделает интерфейсу i:
  - если совсем не интересует - UnmanageObject (i),
  - если интересует, но не совсем - SetInterfaceExpectedState (i, "IGNORE"),
  - если интересует - i->setStatusPropagation (4,1,2,3,3),
  - если интересует очень - оставит всё по-умолчанию.

Code Select Expand


if (i->node->sysDescription ~= "^Cisco")
{
  if (i->name ~= "^Nu|^Di|^Lo")
  {
    UnmanageObject (i);
  } else  if (i->name ~= "^Fa|^Tu")
  {
    i->setStatusPropagation (4,1,2,3,3);
  } else  if (! i->name ~= "^Gi")
  {
    SetInterfaceExpectedState (i, "IGNORE");
  }
}


Можно без всей этой автоматизации, врукопашную. Но, если узлов тысячи, а тут у некоторых есть такие инсталляции, то придётся тяжко.

PS:

setStatusPropagation (4,1,2,3,3) соответствует картинке, которую я приаттачил.

Ага, спасибо большое за наводку. Но вот человеку который не знаком и не умеет программировать - тяжеловато даётся данные надстройки...

Мне вот под D-Link надо, пробую написать так:


i = GetInterfaceObject($node);
if (i->node->driver == DLINK)
{
  if (i->slot == 1 && i->port <= 24)
  {
    SetInterfaceExpectedState (i, "IGNORE");
  } else  if (i->port ~= "^25|^26|^27|^28" & i->slot = "1")
  {
    i->setStatusPropagation (4,1,2,3,3);
  } else  if (! i->name ~= "^ge")
  SetInterfaceExpectedState (i, "IGNORE");
  }


Или даже так:

foreach(i : GetNodeInterfaces($node))
{
if (i->operState == 0)
SetInterfaceExpectedState(i, "IGNORE");
}


Но что-то ничего не срабатывает. Есть ли какая то отладка кода или дебаг\проверка на ошибки при компиляции?

Я чего хотел бы получить: Отображение всех клиентских портов с 1-24 и их состоянием (если UP значит UP, если DOWN значит DOWN, но при этом чтобы красненьким было отмечено что интерфейс DOWN, а вся нода была NORMAL. "Если интересует, но не совсем", подходит к этому варианту, да ставим IGNORE, но тогда в списке интерфейсов он отображается как зелёный и нужно лезть во вкладки и смотреть там его состояние.

Для магистральных портов сделать условие и  i->setStatusPropagation (4,1,2,3,3)

Я пытаюсь взять за основу ваш вариант с кошкой, но ничего не выходит...

Ну тут всё просто. Надо понять netxms, прежде, чем что-то от него хотеть. В который раз уж пишу. :-)

Quote from: glebofff on April 03, 2015, 11:48:51 PM
Ну тут всё просто. Надо понять netxms, прежде, чем что-то от него хотеть. В который раз уж пишу. :-)

Вам легко говорить, а я тут головой бьюсь )) с программированием на "ВЫ" это мягко сказано. Но я пытаюсь учиться.

Ну вы хотя бы поправьте меня пожалуйста если я ошибся где-то...

foreach(i : GetNodeInterfaces($node))

{

if (i->node->sysDescription ~= "^DES|^D-Link DES-3028")
{
println(i->node->sysDescription);
if (i->slot == "1" && i->port <= "24")
    {
SetInterfaceExpectedState (i, "IGNORE");
}

  else  if (i->port ~= "^25|^26|^27|^28" & i->slot = "1")
    {
  i->setStatusPropagation (4,1,2,3,3);  
    }

}

}

Вот так оно вроде бы работает с Hook::ConfigurationPoll

Если мне всё равно у некоторых портов надо поставить expected state вручную (IGNORE) - сохраниться ли МОЁ ручное состояние или при вызове скрипта он сделает по своему?

Quote
setStatusPropagation (4,1,2,3,3) соответствует картинке, которую я приаттачил.

Я не совсем понял, вы для всех интерфейсов изменили Severity based ? Где можно узнать какая цифру какому состоянию соотвествует?

И еще вы пишите:

Quoteесли интересует - i->setStatusPropagation (4,1,2,3,3),

Но у вас это условие относится к "^Fa|^Tu" - как раз он вам не особо критичен.

Немного поправил скрипт:


println($node->sysDescription);

if ($node->sysDescription ~= "^DES|^D-Link DES-3028")
{
   println "Node passed filter";
foreach(i : GetNodeInterfaces($node))
{
   if (i->slot == 1 && i->port <= 24)
   {
   SetInterfaceExpectedState(i, "IGNORE");
   }
      else if (i->port >= 25 && i->port <= 28 && i->slot == 1)
      {
   i->setStatusPropagation(4,1,2,3,3);
   }
}
}


Там было несколько мелких ошибок по синтаксису (& вместо &&, = вместо ==, пробел перед скобкой в вызове функции, и т.д.), но в целом идея правильная.
Скрипты удобно проверять через меню "Run server script" в контекстном меню ноды - можно видеть результат выполнения и вывод trace/println.

Quote from: Victor Kirhenshtein on April 08, 2015, 11:24:53 PM
Немного поправил скрипт:

Code Select Expand


println($node->sysDescription);

if ($node->sysDescription ~= "^DES|^D-Link DES-3028")
{
   println "Node passed filter";
foreach(i : GetNodeInterfaces($node))
{
   if (i->slot == 1 && i->port <= 24)
   {
   SetInterfaceExpectedState(i, "IGNORE");
   }
      else if (i->port >= 25 && i->port <= 28 && i->slot == 1)
      {
   i->setStatusPropagation(4,1,2,3,3);
   }
}
}


Там было несколько мелких ошибок по синтаксису (& вместо &&, = вместо ==, пробел перед скобкой в вызове функции, и т.д.), но в целом идея правильная.
Скрипты удобно проверять через меню "Run server script" в контекстном меню ноды - можно видеть результат выполнения и вывод trace/println.

Спасибо за исправления, вы имеете в виду "Execute server script" ?

Если выставлять для некоторых портов epected state вручную -  скрипт всё равно в приоритете проходит и выставляет свои значения. Как быть в таком случае, для каждой ноды писать в скрипте свои исключения? Бывает, например такое, что не на всех коммутаторов и магистральных портах нужно ожидаемый статус выставлять на UP.

Можно добавить свой custom attribute на таких интерфейсах и в скрипте проверять - если он выставлен, то ничего не делать.

Quote from: Victor Kirhenshtein on April 28, 2015, 10:03:22 PM
Можно добавить свой custom attribute на таких интерфейсах и в скрипте проверять - если он выставлен, то ничего не делать.

апну тему...

Продолжаю дальше продумывать логику ожидаемых состояний интерфейса и вернулся к custom attribute.

QuoteEvery object can have custom attributes defined either by user or integrated application via NetXMS API. Custom attributes distinguished by names (an attribute name can contain up to 127 printable characters), and have string values of unlimited length. However, if you wish to access custom attributes in NXSL scripts as properties of node object, you should name them conforming to NXSL identifier naming constraints. To create or change value of custom attribute manually, right-click object in NetXMS console, and select Properties ‣ Custom Attributes tab.

Я так понимаю имя и строка, но что вы имеете в виду под добавить "свой" какие значения мне необходимо указать?

Можно любое имя выбрать для атрибута - как-то специально описывать их не надо.

Quote from: Victor Kirhenshtein on September 08, 2015, 05:41:02 PM
Можно любое имя выбрать для атрибута - как-то специально описывать их не надо.

А вы случайно ни какие изменения не вводили, например, на приоритет, если Excepted state выставлен вручную то тогда скрипт Hook::ConfigurationPoll не будет выставлять по своему. Потому что сейчас если я выставляю на некоторых портов в ручную Excepted state - он таким и остаётся, не смотря на работу скрипта поверх. Может быть тогда так и должно быть? Меня этот вариант больше устраивает т.к. осилить нужную логику скрипта с атрибутами проблематично

И если я правильно понял то функция GetCustomAttribute(node, attributeName) только для ноды, тогда как проверять аттрибут для интерфейса?

Еще заметил у всех коммутаторов Dlink автоматически выставляется атрибут .dlink.slotSize со значением 48 - что это означает? Slot как я понимаю может быть 1 или 2 если коммутатор поддерживает stack

QuoteУ объекта Interface появилось свойство alias, есть name, появились незадокументированные методы setStatusPropagation / setStatusCalculation.

А документации на эти методы не появилось случайно?