NetXMS Support Forum

Quote from: Weird on September 07, 2007, 05:50:32 PM
Object Properties -> Polling -> Disable usage of SNMP for all polls -- это не оно ли?

Не совсем. Это запретит использование SNMP вообще - т.е. status poll тоже не будет использовать SNMP. Я в следующей версии добавлю опцию Disable configuration poll (работы минут на 15), тогда будет то что надо.

Ну да, я в общем и имел ввиду что это будет возможным.

Hello!

NetXMS server polls for configuration changes (configuration polls) not instantly, but with interval (1 hour by default). If you just install agent on host, NetXMS server will know about it when next configuration poll occurs. You can also manually run configuration poll by right-clicking host object and selecting Poll -> Configuration.

Best regards,
Victor

Hello!

We plan this feature (custom maps) for the next major development branch. However, with current version you can create custom map, but this is a bit tricky. Below is an instruction:

1. Create new container object under "All Services", and look at container's object id.
2. Stop NetXMS server.
3. Perform the following SQL query in NetXMS database

UPDATE maps SET root_object_id=<place container object id here> WHERE map_id=1

4. Start server again. After that, all objects added to container created in step one will be shown on map.

With upcoming 0.2.19, you also will be able to create links between objects. And remember, it's just a hack, not a complete custom map implementation!

Best regards,
Victor

Quote from: Ndk669 on August 22, 2007, 05:47:48 AM

Quote from: Victor Kirhenshtein on August 17, 2007, 10:04:59 AM
Если  аларму сделать terminate, то статус ноды должен изменится на NORMAL.

хм. убиваю аларм Critical, тогда NODE UP не отображается в Alarm Notifier'е. В чем может быть дело?

в event processing policy для события SYS_NODE_UP по умолчанию аларм не создается. Если хочется его видеть, то надо добавить соответствующее правило в policy.

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



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

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. А можно ли прислать лог сессии?