NetXMS: мониторинг и инвентаризация сети

NetXMS — открытая платформа для мониторинга сети и учёта оборудования. Она не привязана к одному протоколу: сервер одновременно опрашивает устройства по ICMP и SNMP, принимает данные от собственных агентов и выполняет скрипты, а результаты складывает в общую базу. Из этой базы строятся графики, отчёты, карты сети и инвентарный список. Ниже — практический маршрут от установки сервера до первого опроса коммутатора и настройки уведомлений.

Из чего состоит система

NetXMS делится на четыре части. Сервер netxmsd хранит конфигурацию, опрашивает узлы и принимает данные. Агент nxagentd устанавливается на компьютеры и серверы, которые нужно наблюдать изнутри: он отдаёт загрузку процессора, память, диски, службы и установленное ПО. Консоль управления — отдельное приложение на Java, а веб-консоль даёт доступ к тем же данным из браузера. Всё состояние хранится в СУБД, поэтому резервное копирование сводится к дампу базы и копии каталога конфигурации.

По умолчанию сервер и агент используют TCP-порт 4700, SNMP — привычный 161/UDP. Порт 4700 откройте только для своих подсетей: это не тот сервис, который стоит публиковать в интернет.

Установка сервера и базы данных

Для небольшой сети достаточно одной виртуальной машины с двумя ядрами и 4 ГБ памяти. В качестве СУБД удобнее всего PostgreSQL: она предсказуемо работает с большими таблицами метрик. Пакеты из репозитория дистрибутива могут отставать, поэтому при возможности подключайте официальный репозиторий проекта.

sudo apt install netxms-server netxms-agent netxms-db-driver-pgsql
sudo -u postgres createuser -P netxms
sudo -u postgres createdb -O netxms netxms

После создания базы отредактируйте /etc/netxms/netxmsd.conf. Минимальный набор параметров выглядит так:

DBDriver = pgsql
DBName = netxms
DBLogin = netxms
DBPassword = <пароль>
LogFile = /var/log/netxmsd

Точные имена ключей зависят от сборки, поэтому рядом обычно лежит файл-образец — сверьтесь с ним. Затем запустите службу и проверьте журнал:

sudo systemctl enable --now netxmsd
systemctl status netxmsd --no-pager
journalctl -u netxmsd -n 100 --no-pager

При первом старте сервер инициализирует схему и создаёт учётную запись администратора. Пароль по умолчанию менять нужно сразу, до подключения консоли к рабочей сети.

Агенты на хостах

Агент даёт то, чего не видно по SNMP: список пакетов, состояние служб, содержимое таблиц, произвольные команды. На управляемом хосте правится /etc/netxms/agent.conf:

MasterServers = 10.10.0.5
LogFile = /var/log/nxagentd

В поле MasterServers указывается адрес сервера, который имеет право опрашивать агент. Это важная настройка безопасности. После правки перезапустите службу и убедитесь, что порт слушается только на нужном интерфейсе.

sudo systemctl restart nxagentd
ss -lntp | grep 4700

Обнаружение устройств и SNMP

В консоли есть мастер обнаружения: вы задаёте диапазон адресов, список community-строк и порты, после чего система сама создаёт узлы и определяет тип устройства. Для начала ограничьте сканирование одним этажом или стойкой — так проще разобраться с ошибками.

На Linux-хостах, которые должны отвечать по SNMP, установите snmpd и опишите доступ:

sudo apt install snmpd snmp
sudo tee /etc/snmp/snmpd.conf <<'EOF'
rocommunity public 10.10.0.0/24
sysLocation Server room A
sysContact admin@example.org
EOF
sudo systemctl restart snmpd

Строка public допустима только внутри изолированного сегмента. Для сколько-нибудь серьёзной сети используйте SNMPv3 с отдельным пользователем и шифрованием, а старые версии протокола отключите. Проверить доступность можно штатной утилитой snmpwalk и инструментом NetXMS nxsnmpwalk:

snmpwalk -v3 -l authPriv -u monitor -a SHA -A '<пароль>' -x AES -X '<пароль>' 10.10.0.10 sysDescr
nxsnmpwalk -v2c -c public 192.168.10.1

Метрики, пороги и события

Основной кирпичик мониторинга в NetXMS — элемент сбора данных, или DCI. У каждого элемента есть источник, период опроса и способ хранения. Для температуры коммутатора достаточно SNMP-запроса раз в пять минут, для загрузки канала — раз в минуту, для свободного места на диске — раз в десять минут. Не ставьте везде одинаковый интервал: именно частота опроса чаще всего перегружает и сервер, и устройства.

Порог привязывается к элементу и порождает событие, а событие — тревогу. Разумная схема: предупреждение при 80 процентах занятости диска, критическое событие при 92, автоматическое закрытие тревоги при возврате ниже 75. Такие «коридоры» избавляют от дребезга уведомлений.

Уведомления настраиваются через SMTP-сервер в конфигурации и правило обработки событий. Фильтруйте по важности: если отправлять письмо на каждое событие, через неделю почту начнут игнорировать.

Инвентаризация и карты

Инвентарь собирается из трёх источников: SNMP-таблиц ENTITY-MIB, данных агента и полей, которые администратор заполняет вручную. Устройства, отдающие ENTITY-MIB, сообщают модель, серийный номер и версию прошивки — этого достаточно для отчёта об оборудовании. Хосты с агентом добавляют список пакетов и параметры железа.

• Заполните обязательные поля: расположение, ответственный, дата ввода в эксплуатацию.
• Настройте автоматическое привязывание шаблонов по типу ОС или OID, иначе новые узлы останутся без метрик.
• Раз в месяц выгружайте отчёт и сравнивайте с фактическим наличием техники.
• Удаляйте узлы, которые не отвечают больше месяца, иначе карта превратится в свалку.

Карта сети строится по связям, которые система определяет через таблицы коммутации и ARP. Автоматическая топология почти всегда требует ручной правки: подпишите сегменты, уберите служебные адреса и задайте понятные имена.

Диагностика и обслуживание

Если узлы пропали с карты, сначала смотрите журнал сервера и статус опроса конкретного узла. Частые причины — неверная community-строка, ACL на устройстве, переполненный диск и рассинхронизация времени. Проверить базу и место на диске можно так:

sudo -u postgres psql -d netxms -c 'SELECT pg_size_pretty(pg_database_size(current_database()));'
df -h /var/lib/postgresql
timedatectl status

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

Чек-лист внедрения

• Сервер и база размещены в отдельном сегменте, порт 4700 закрыт извне.
• Пароль администратора изменён, для SNMP заведён отдельный пользователь v3.
• Агенты ограничены списком MasterServers.
• Настроены шаблоны, пороги и тестовое уведомление на дежурного.
• Есть расписание дампа базы и проверка свободного места.
• Инвентарь сверен с фактическим оборудованием хотя бы один раз.

Итог

NetXMS закрывает сразу две задачи: наблюдение за доступностью и учёт оборудования. Начинайте с одного сегмента и десяти узлов, настройте SNMPv3 и агенты, затем расширяйте охват. Главное — не экономить на разграничении доступа и не включать опрос всего подряд: аккуратная схема из нескольких десятков метрик полезнее, чем сотни графиков, на которые никто не смотрит.