NetXMS Support Forum

Прошу прощения за поздний ответ:



в обведенном поле надо написать

DC_%i_%5

остальное вроде все правильно.

Hi!

QuoteХотелось бы немного изменить схему parent-child. Чтоб интерфейс был child'ом у сети. А сеть была child'ом у маршрутизатора. Тогда при проблеме на интерфейсе загорится красным ну или желтым только маршрутизатор и проблемная сеть.
Мне кажется это было бы разумным.

При реализации предложенной схемы ломается логика системы: если мы используем иерархию

[root] -- router -- subnet -- interface

то во первых, не видно кому принадлежат интерфейсы, а во вторых - что делать с обычными хостами.  Если тоже [root] -- host -- subnet -- interface, то открыв объект subnet, увидим много скажем eth0, что ничего полезного нам не скажет. Если хосты биндить по другому, то тогда теряется единая концепция, что плохо.

Для решения проблемы со статусами субнетов, я бы предложил следующее:
1. Иногда может помочь правильная настройка правил status calculation/status propagation;
2. Реализовать возможность описывать свои алгоритмы для подсчета и передачи (propagation) статуса объекта (через скрипты). Тогда можно будет реализовать все что угодно, включая желаемый вариант. Идеология сохранится, плюс появится дополнительная гибкость.

Best regards,
Victor

It's not possible now. I see that this is a common requirement (along with possibility to create calculated DCIs), so I definitely will implement this in one of the future versions.

Best regards,
Victor

Проблема в том, что ключи не совпадают. При генерации аларма мы даем ему ключ THRESHOLD_REACHED_%i, а terminate пытаемся сделать для алармов с ключами DC_%i_%3, которых естественно не находим. Если в правиле создающем аларм заменить THRESHOLD_REACHED_%i на DC_%i_%5, то все должно работать.

Теоретически это должно работать, надо только правильно выставить code page для сервера (параметр CodePage в файле netxmsd.conf, по умолчанию ISO-8859-1) и для базы. И сервер должен быть скомпилирован с поддержкой iconv - в Linux'е и FreeBSD скорее всего так и будет.

Unfortunately, it's impossible now. I have a plans (and pending requests) for implementing "table" DCIs, which will be suitable for this task. Most likely it will not be in upcoming 0.2.19, but I hope that I will be able to implement it in 0.2.20.

Best regards,
Victor

Unfortunately not. However, I can add it in 0.2.19 - there are no much work, just nobody asking about such feature before.

Best regards,
Victor

В выделенном правиле должно быть DC_%i_%3. Можно ли прислать следующую инфу:
1. скриншот конфигурации аларма для правила 1;
2. скриншот конфигурации threshold для DCI (список threshold'oв и настройки конкретного threshold'a).

И в самом деле удивительно  Буду думать...

Реализована, так что похоже на баг. Возможно агент по каким-то причинам не понимает ответа на HELLO. А можно ли прислать лог сессии?

Hello!

"Calculate status as" determines how object's status should be calculated based on child objects statuses. For objects without child objects (like conditions) it has no meaning.
"Propagate status as" determines how object present it's status to parent object(s). For example, you have a switch with various interfaces. Normally, when interface goes down, it's status changes to CRITICAL, and status of entire node object changes to CRITICAL (and so on up to the root). However, if you have not very important interfaces and wish that node status changes not to CRITICAL, but to WARNING when this interface  goes down, you can change "Propagate status as" property of interface object so it will propagate it's CRITICAL status as WARNING.

Best regards,
Victor

Пока никак, он просто делает connect. В  будущем планируем начать использовать.

Добрый день!

SMTP:
request = адрес для отсылки мейла, response не используется.

SSH:
оба поля игнорируются, проводится ssh handshake без логина.

POP3:
request = user:password, response не используется.

FTP пока не реализован.

Скорее всего остается активным какой-то аларм со статусом CRITICAL (статус ноды складывается из статусов интерфейсов и алармов). Если этому аларму сделать terminate, то статус ноды должен изменится на NORMAL.

Релиз будет в августе, постараюсь учесть как можно больше пожеланий. В последнее время в связи со всяческими рабочими и домашними проблемами работа над проектом замедлилась, но я надеюсь что скоро ситуация изменится.