NetXMS Forum

Здравствуйте. Возможно ли будет реализовать функцию информирования о статусе Netxms сервера по почте, с выбором нескольких почтовых адресов доставки и периодичность отправления. На мой взгляд в сообщении необходимо указывать число активных и неактивных нодов, список не активных нодов, ошибки зарегистрированные сервером и не отмеченные как решённые, возможно информацию с заданных DCI.

Было бы неплохо заменить скрипт запуска для FreeBSD. тот который есть сейчас не дает запустить агента с какими либо ключами. #!/bin/sh # PROVIDE: nxagentd # REQUIRE: DAEMON # BEFORE: LOGIN # KEYWORD: shutdown nxagentd_enable=${nxagentd_enable-"NO"} nxagentd_flags=${nxagentd_flags-"-c /usr/local/etc/nxagentd.conf -d"} . /etc/rc.subr name="nxagentd" rcvar=`set_rcvar` command="/usr/local/bin/nxagentd" load_rc_config $name start_cmd="echo \"Starting ${name}.\"; ${command} ${nxagentd_flags}" run_rc_command "$1" Вот с таким скриптом все прекрасно работает. В /etc/rc.conf можно использовать различные флаги: nxagentd_enable="yes" nxagentd_flags="-M 10.1.10.18 -d"

Можно в перспективе реализовать в NetXMS поддержку динамической адресации при мониторинге по SNMP?

А вот бы было здорово реализовать для мониторинга сервиса DNS что-то в таком роде: [image: check_dns.gif]

Премного благодарен Буду помогать чем смогу. Могу предоставить исходник нашего мониторинга, возможно это будет полезно в плане реализации нового протокола.

вот спасибо!

@anth0ny said in Индивидуальный параметр "PollCountForStatusChange" для DCI: Когда ждать релиза 0.2.23? Ja dumaju chto v konce oktjabrja ili nachale nojabrja. Do etogo objazatel'no budet neskol'ko rc versij.

UP тема всё ещё актуальна. как можно создать универсальный рестартер сервисов? что бы не прописывать имя сбойнувшего сервиса в скрипте рестарта в явном виде?

В случае с шаблонами всё достаточно очевидно: при применении шаблона на Объект в свойствах Data Collection Объекта видно, откуда им унаследованы текущие настройки DCI. А вот с локальными DCI, созданными для интерфейса Объекта (именно только для интерфейса) всё не так хорошо: при просмотре списка DCI нельзя однозначно понять, для чего же служит созданный DCI, для всего Объекта или же только для конкретного отдельно взятого интерфейса. Можно ли при создании DCI для интерфейса как-то их идентифицировать в списке всех DCI Объекта? По аналогии с шаблонами.

Дополнение по Шаблонам: просьба при Дублировании или Перемещении индивидуального DCI в Шаблон по умолчанию выставлять для него состояние Выключено (Disabled) и менять имя на Dublicate of: Название оригинального DCI.

Прошу по возможности реализовать следующее в консоли: Доделать отображение: нужен ещё один контейнер верхнего уровня, в котором находились бы абсолютно все ноды, не взирая на то, как они управляются (Агент или SNMP или вообще не управляются). А то сейчас приходится искать созданную ноду по разным спискам, если заранее не известно, что на ней стоит (Агент, SNMP или вообще ничего пока не стоит). Позволить переносить уже существующие ноды на верхнем уровне из контейнера в контейнер. Т.е. если нода уже есть и она фигурирует в любом из списков (Agent, SNMP, Networks), то нужна возможность не пересоздавая перенести её в контейнер Кластера. Прошу переделать Refresh мониторинга, чтобы при рефреше не сворачивались все контейнеры верхнего уровня..

2 prx а можешь привести по указаному вопросу пример скрипта?

V 0.2.23 sdelal poisk po IP. Pered adresom nado dobavljat' prefiks ip:, naprimer dlja poiska hosta s adresom 10.0.0.2 mozno napisat' ip:10.0.0.2

Спасибо за ответ, Виктор. А я-то решил, что отсутствие реакции = отсутствию интереса. Понял.

UP!

да я и не говорю, что серверов должно быть больше одного, просто важно что в случае выхода сервера монитора из строя его легко заменить. вот что важно. Спасибо за сведения!

спасибо!

  совсем больше никому не нужно?

Идея хорошая, согласен.