Вышла система мониторинга NetXMS 1.2.6

кто-нить на сервера ставил? Как оно? Ищу замену всяким нагиосам и collectd в одном флаконе, не знаю на чём бы остановиться. Желательно что-то немонструозное.

А я вот заббикс юзаю вовсю.
Хотя надо бы и эту радость помацать.

Если не монструозное - глянь на проприетарный monit/mmonit.

Или zenoss.

monit/mmonit.

прикольно, monit есть в арче из коробки. Буду тестить.

Это только клиент, он опенсурсный. Серверная часть денег стоит, 200 евро чтоли. Но мне настолько понравилось, что я купил :)

омг, оно ipv6 не держит :(. С учётом того что это основной источник проблем у меня на сервере это очень плохо. А ведь про ipv6 им писали ещё года три назад.

У тебя работающий ipv6? O_O Свой префикс? С кем пиринг?

Забикс, хоть и монструозный но вполне годный

Ищу замену всяким нагиосам и collectd в одном флаконе, не знаю на чём бы остановиться.

Я не видел ещё такого.
А нагиос можно на исингу заменить.

С кем пиринг?

С самим сабой, но этого стесняется.

У тебя работающий ipv6?

Да, потому что дц хетцнер и они дают только один ipv4. Ну как работающий, я не могу заставить работать. Четыре дня в обнимку со снифером провёл. Похоже что тачка должна слать что-то вроде keep alive (router solicitication), иначе роутер «забывает» про тачку.

Отдельная песня это icmp redirect. Если в виртуалках прописать гейтом ip мастер-машины то ничего толком работать не будет т.к. периодически будет прилетать icmp redirect на fe80::1 (link-local адрес гейта), при этом пакет дропается. На линуксе я прописал fe80::1 в качестве гейта и всё заработало (плюс засунул accept_redirects=0) а вот виртуалка openbsd работать не хочет.

Напишу в саппорт, но, боюсь, дохлый номер.

У тебя работающий ipv6? O_O Свой префикс? С кем пиринг?

Вот не надо тут разводить, типа нет нигде ipv6 ещё. Есть. А у кого нет те используют локальных брокеров за бабки. Потому что очень вкусно это ipv6. Лично я сетку параллельно с ipv4 построил, работает на ура и больше не надо изврат делать чтобы в интранет из внешки ходить. И да, нат не нужен.

Вот не надо тут разводить, типа нет нигде ipv6 ещё. Есть. А у кого нет те используют локальных брокеров за бабки. Потому что очень вкусно это ipv6. Лично я сетку параллельно с ipv4 построил, работает на ура и больше не надо изврат делать чтобы в интранет из внешки ходить. И да, нат не нужен.

Полностью согласен, но ipv6 и правда еще очень мало.

где rpm? или это система мониторинга локалхостов?

./configure --help

Да это-ж NetCrunch! По скриншотам http://www.netxms.org/screenshots/ очень похоже, опять же, два клиента - под винду и web. Древовидный интерфейс и общая причёсанность - это то, чего не хватает Заббиксу для нормального юзабилити.

И по набору возможностей видно, что сразу нацелено на энтерпрайз, а не выросло из проекта для себя любимого: L2 и L3 network discovery, корреляция событий, автоматическое построение карт, аутентификация через RADIUS...

А, к стати, кто делает этот NetXMS? На некоторых скринах виден домен .lv. Тоже латыши, что ли, как и Zabbix? Ага, точно http://www.radensolutions.com/company.html Не тесно им там в маленькой стране? :)

Кто-нибудь реально сравнивал это с Заббиксом? Производительность, стабильность, наличие готовых шаблонов для оборудования, саппорт, вообще как оно работает?

и мне это делать на сотнях серверов? вопрос остался без ответа

Я так понимаю, это надо сделать на одной рабочей станции, чтобы собрать rpm.

и потом пересобирать самому? нет уж, мне работать надо.

Ну так работай, а не задавай вопросы, на которые есть очевидный ответ. А rpm-ки и deb-ы разрабы сделают. Может быть. Когда нибудь. Если руки дойдут. Их там двое всего разрабов. А пока юзай ping/mrtg/cacti/nagios/zabbix... Что там ещё в репе у центоса есть?

я сам для себя решу что мне юзать, но на эту систему даже не начну смотреть пока не появятся нормальные RPMки, желательно в EPEL, чтоб не тянуть лишнего в RHEL

Ставил, вот завершение попытки
http://www.netxms.org/forum/oe-oo/aka-sms-amam-ee-gammu-smsd/
для чего андроид агент так и не понял
дальше тыркаться уже не захотелось, а так все красивенько
к нагиосу нужен centreon

Пока только в тестовую сетку, и пока есть только первые впечатления

• Мне кажется, что netxms в первую очередь ориентирован на мониторинг сети. snmp, cdp, lldp. Вообще больше половины пунктов в большинстве меню относятся к сети :)
• автоматический network discovery работает только тогда, когда есть доступ к свичу по snmp. ( предположительно, ещё netxms может автообнаружить хосты, с которыми он сам взаимодействует - шлюз сети, хост на котором установлен клиент netxms ( в т.ч. java приложение под tomcat ), хост с которого подключались на порт netxmsd )
• Проверку сетевого сервиса можно назначить только на хост, но не на шаблон ( т.е. проверку ssh пришлось бы добавлять на каждый хост вручную )
• init скрипты из deb пакетов запускают и клиент, и сервер от рута
• готовых шаблонов нет ( или я не нашёл ), и это грустно, т.к. повышает порог вхождения
• веб консоль ( которая в виде java приложения для tomcat ) по умолчанию подключается к 127.0.0.1. Пока не нашёл где можно задать адрес по умолчанию, если консоль установлена на отдельном хосте.
• Судя по документации, для запросов можно использовать клиентские хосты как прокси, и это плюс в том плане, что разработчик изначально задумывался о масштабировании

Кстати, проверка ssh ( как сетевого сервиса ) у меня так и не заработала, пытаюсь понять что не так сделал.

веб консоль ( которая в виде java приложения для tomcat ) по умолчанию подключается к 127.0.0.1. Пока не нашёл где можно задать адрес по умолчанию, если консоль установлена на отдельном хосте.

Вариант а, «через универсальный интерфейс»

1. Задеплоить приложение ( по умолчанию в tomcat'ах включен автодеплой, достаточно скопировать .war файл в $CATALINA_BASE/webapps )
2. Остановить tomcat. Удалить .war файл из $CATALINA_BASE/webapps
3. распаковать $CATALINA_BASE/webapps/nxmc-1.2.6/WEB-INF/plugins/org.netxms.webui.core_1.2.6.jar во временный каталог ( перед распаковкой он должен быть пуст )

   mkdir /tmp/test; cd /tmp/test; unzip /var/lib/tomcat7/webapps/nxmc-1.2.6/WEB-INF/plugins/org.netxms.webui.core_1.2.6.jar

4. в этом временном каталоге в файле org/netxms/webui/core/nxmc.properties поменять параметр server vim org/netxms/webui/core/nxmc.properties
5. снова запаковать этот файл, плюс раскидать его по двум каталогам:

   zip -r ../org.netxms.webui.core_1.2.6.jar *
   cp ../org.netxms.webui.core_1.2.6.jar /var/lib/tomcat7/webapps/nxmc-1.2.6/WEB-INF/plugins/org.netxms.webui.core_1.2.6.jar
   cp ../org.netxms.webui.core_1.2.6.jar /var/lib/tomcat7/work/Catalina/localhost/nxmc-1.2.6/eclipse/plugins/org.netxms.webui.core_1.2.6.jar
   

6. Запустить tomcat. Ура, теперь по умолчанию мы будем подключаться к адресу, указанному в nxmc.properties

Да, мсье знает толк в извращениях. Я пробовал подкинуть nxmc.properties в $CATALINA_BASE/conf/Catalina/localhost/, но это ничего не дало. Возможно, нужно указывать какие-то параметры в JAVA_OPTS, чтобы приложение знало где искать свой конфиг. Это всё очень специфично для приложения и моего скила не хватит.

init скрипты из deb пакетов запускают и клиент, и сервер от рута

Я считаю, что клиента системы мониторинга недопустимо запускать от рута, потенциально это крупная дыра в безопасности. А серверу мониторинга права root вообще не нужны, если он не использует порты ниже 1024.

Умеряем аппетиты клиента:

1. создаём нового пользователя и блокируем его пароль. Хорошо бы ещё и шел отобрать, но тут сначала нужно проверить как он к этому отнесётся.

   adduser netxms
   usermod -L netxms

2. Права на логи и реестр (?)

   chown netxms:netxms /var/opt/netxms/agent -R
   chown netxms:netxms /var/log/nxagentd* 

3. Правим скрипт запуска:

   root@netxms:/usr/local/src/netxms-1.2.6# diff /root/nxagentd.2013.02.26 /etc/init.d/nxagentd 
   24a25,27
   > USER=netxms
   > GROUP=netxms
   > 
   47c50
   <         start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test > /dev/null \
   ---
   >         start-stop-daemon --start --quiet --pidfile $PIDFILE --chuid $USER:$GROUP --exec $DAEMON --test > /dev/null \
   49c52
   <         start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \
   ---
   >         start-stop-daemon --start --quiet --pidfile $PIDFILE --chuid $USER:$GROUP --exec $DAEMON -- \
   67c70
   <         start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --name $NAME
   ---
   >         start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --chuid $USER:$GROUP --name $NAME
   76c79
   <         start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec $DAEMON
   ---
   >         start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --chuid $USER:$GROUP --exec $DAEMON
   92c95
   <         start-stop-daemon --stop --signal 1 --quiet --pidfile $PIDFILE --name $NAME
   ---
   >         start-stop-daemon --stop --signal 1 --quiet --pidfile $PIDFILE --chuid $USER:$GROUP --name $NAME

4. Перезапускаем агента, проверяем. Всё ок

А серверу мониторинга права root вообще не нужны, если он не использует порты ниже 1024.

Использует, для получения snmp trap'ов. Пока придётся оставить.

А может достаточно дать ему CAP_NET_BIND_SERVICE?

http://stackoverflow.com/questions/413807/is-there-a-way-for-non-root-process... http://www.lst.de/~okir/blackhats/node125.html

новая и быстро развивающаяся система мониторинга сети, распространяемая по лицензии GPLv2

Почему не GPLv3?

Запустить tomcat. Ура, теперь по умолчанию мы будем подключаться к адресу, указанному в nxmc.properties

Да, это хоть и задокументированное (http://wiki.netxms.org/wiki/Web_Interface_Installation_Guide#Installing_web_i...), но неудобство. Ищем способ сделать проще.

Я считаю, что клиента системы мониторинга недопустимо запускать от рута, потенциально это крупная дыра в безопасности. А серверу мониторинга права root вообще не нужны, если он не использует порты ниже 1024.

Такие настройки по умолчанию нужны, чтобы всё работало «из коробки». Рут для сервера нужен для SNMP и ICMP, рут для агента тоже нужен для пингов. Если Вам эти вещи не нужны, или готовы сознательно ими пожертвовать - рута конечно можно отнять.

Почему не GPLv3?

Разработку начали еще при GPL2. Потом решили лицензию не менять, т.к. никаких преимуществ в нашем случае она не дает.

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

Проверку сервиса можно делать не только через объект типа Network service, но и шаблон с DCI ServiceCheck.SSH() (см. http://www.netxms.org/forum/configuration/web-site-monitoring/msg87/#msg87 вариант 2) и задать proxy node = сервер. В параметрах DCI задать %{node_primary_ip}. Тогда при наложении шаблона на хосты макрос раскроется в IP конкретного хоста, а проверка сервиса будет осуществляться с сервера. При этом DCI будет привязан к проверяемому хосту.