кста, с помошью параметра ResolveNodeName наверняка можно отключить обновление названия при принудительном опросе конфигурации ноды (сам еще не пробовал)

Дело в том, что при при Poll Configuration все надписи, которые делаешь руками, затираются.

Было бы здорово добавить функцию изменения статуса всех дочерних объектов на Managed/Unmanaged.

Можно выбрать объект ноды, закладку Subordinates, выделить все нужные объекты и сделать им Manage/Unmanage.

Нужно при падении node видеть об этом информацию а вот при падении интерфейсов на этом ноде не видеть этого.

Простой пример - Свитч с подключенными компьютерами которые постоянно включаются и выключаются %)

У меня такая же фигня сделана. Сделал так. У свитча есть uplink полюбому. Его оставляю как есть. Остальные порты на этом коммутаторе через Status Calculation устанавливаю в Normal. И таким образом отключайся не отключайся, придет сообщение об этом (тут ещё можно с events поиграться) нод у тебя не будет целиком в дауне.

2 prx. А что мешает нажать правую клавишу на node или же на всей сети и сказать Unmanaged?

Нужно при падении node видеть об этом информацию а вот при падении интерфейсов на этом ноде не видеть этого.

Простой пример - Свитч с подключенными компьютерами которые постоянно включаются и выключаются %)

Рассылка по нескольким e-mail адресам, разделённым ";" или пробелом. Можно, конечно, сделать несколько экшенов, как я сейчас и делаю, но была бы фича полезна.

Sdelal, v CVS versii uze est'. Adresa nado razdeljat' ";". Toze samoe rabotaet i v rassilke SMS-ov. Esli ochen' hochetsja etu funkcional'nost' v tekushej versii, to mozno zamenit' fail src/server/core/actions.cpp na tot kotorij v attache i peresobrat' server.

actions.cpp

так и сделано, но всеравно узлы "красные" и alarmы приходят

красные они как раз из-за алармов - поскольку severity алармов учитывается при вычислении статуса узла. Ну а появление алармов (и их приоритет) можно контролировать через event processing policy.

Еще ода мысль пришла - делать интерфесы опрашиваемыми но unmanaged - т.е. чтоб их состояние невлияло на "покраснение" узла но его можно было посмотреть. Для чего - есть клиенты которых ненужно мониторить 24х7, но при обращении было бы удобно посмотреть статистику падений и текущее состояние.
Хотя наверно это можно сделать через "Status calculation"

Это действительно можно сделать через status calculation — в properties интерфейса, который не должен влиять на статус хоста, выставить в Status Cаlculation -> Propagate as variant "Fixed" и выбрать статус "Normal".

7. С устройства можно получить description интерфейса - то что админ прописал в конфиге. имеет смысл его хранить в отдельном поле и сделать опцию "добавлять к имени интерфейса при выводе в дереве" и оборажать его как часть поля Note
   в результате получим fastethernet0/1 - [Internet] ClientName

ну я наверно вообще о другом говорил выше?
https://www.netxms.org/forum/index.php/topic,74.msg465.html#msg465

@vbolshakov said in [features] Идеи и предложения по функционалу NetXMS:

1. Настройка версии SNMP по умолчанию - сейчас нужно создать узел и после создания менять версию

2. Получение description интерфейса при добавлении node и сохранение его в note, а вообще нужно отдельное поле чтоб можно было апдейтить небоясь потерять содержимое note

1. Вообще-то NetXMS сервер при добавлении ноды должен саи определять какая версия SNMP должна использоваться. Если он этого не делает, то это баг.

2. Можно поподробнее, я не до конца понял в чей note надо сохранять description - ноды или интерфейса?

1. Вот у меня несработало автоопределение, пробовало опрашивать v2 узел v1 протоколом.

2. С устройства можно получить description интерфейса - то что админ прописал в конфиге. имеет смысл его хранить в отдельном поле и сделать опцию "добавлять к имени интерфейса при выводе в дереве" и оборажать его как часть поля Note
   в результате получим fastethernet0/1 - [Internet] ClientName

1. Настройка версии SNMP по умолчанию - сейчас нужно создать узел и после создания менять версию
2. Настройка SNMP community по умолчанию - сейчас это можно сделать "хитро" - включить автодискавери но не применять, задать community, выключить автодискавери и применить
3. Настройка "unmanaged by default" - чтоб свежесозданные/обнаруженные ноды непортили картину
4. Возможность сделать unmanaged для сети, не меняя настроки managed/unmanaged для node приписанной  к этой сети. Вобщемнто эта фича будет иметь смысл для всех структур.
5. Возможность прятать сети - у меня в сети много MPLS VPN с дублирующимися адресами и эти сети "ненужны" с точки зрения мониторинга (или пока ненужны).
6. 64битные счетчики интерфейсов - для жирных каналов обычные 32 битные показывают ерунду
7. Получение description интерфейса при добавлении node и сохранение его в note, а вообще нужно отдельное поле чтоб можно было апдейтить небоясь потерять содержимое note

1. Вообще-то NetXMS сервер при добавлении ноды должен саи определять какая версия SNMP должна использоваться. Если он этого не делает, то это баг.
2. Это можно сделать в консоли через Control Panel -> Server Configuration -> отредактировать параметр DefaultCommunityString
   3-6. Хорошие идеи, приму к сведению.
3. Можно поподробнее, я не до конца понял в чей note надо сохранять description - ноды или интерфейса?

Ситуацыя:
NetXMS server , количество Nod  ~200+.
При Node UP|Down отсылаются SMS & Mail.

Проблема:
Проблема при перезагрузке сервера , потери сети сервером уходят лавиной сообщения.

Решение:
При потери сети NetXMS сервером формировать только один аларм.
При посылкe 5< маилов в секунду на один адресс, посылать 1 маил ,"всё плохо". остальные отбросить.
После перезагрузки NetXMS сервера оповещать только об изменившихся статусах.

Имхо той же лавинной и придет аля типа все устройства изменили статус с down на up.. Тут надо как-то по другому думать...

Проблема:
Проблема при перезагрузке сервера , потери сети сервером уходят лавиной сообщения.

Решение:
При потери сети NetXMS сервером формировать только один аларм.
При посылкe 5< маилов в секунду на один адресс, посылать 1 маил ,"всё плохо". остальные отбросить.
После перезагрузки NetXMS сервера оповещать только об изменившихся статусах.