Внедряем NetXMS с нуля: сервер на Debian 12, агенты на Windows и автообнаружение сети — пошаговый регламент ITfresh

Что понадобится: требования и план работ

Меня зовут Евгений Семёнов, я технический директор ITfresh. В обзоре NetXMS я объяснял, почему эта система — наш дефолтный мониторинг для офисов до 50 рабочих мест. Сегодня выкладываю внутренний регламент, по которому инженер ITfresh поднимает мониторинг у нового клиента за полдня: от apt install до первых алертов в Telegram. Формат — «повтори за мной»: реальные команды, реальные параметры, и отдельно — грабли, на которые мы наступали за вас.

Ресурсов NetXMS просит по-спартански: одна виртуалка с 2 vCPU, 4 GB RAM и 40 GB диска уверенно тянет сотню с лишним узлов с историей метрик. Наш стандартный выбор — Debian 12 и PostgreSQL 15 из штатных репозиториев: связка скучная, предсказуемая и живущая годами без сюрпризов. SQLite для «попробовать» технически возможен, но мы его не используем даже на стендах — о причине ниже.

До начала работ запрашиваем у клиента чек-лист доступов — это экономит день переписки в середине проекта:

• список подсетей офиса и филиалов (что вообще сканируем);
• SNMP community существующих железок — коммутаторов, ИБП, принтеров (а если SNMP нигде не включён — доступ к железкам, чтобы включить);
• доменная учётка с правом установки ПО — для раскатки агентов на Windows через GPO;
• токен Telegram-бота или согласие создать нового — для алертов;
• окно, когда можно шуметь сканированием сети (active discovery — это заметный трафик опроса).

Установка сервера из официального APT-репозитория

NetXMS ставится из подписанного репозитория проекта. Подключается он пакетом netxms-release, который приносит и source-list, и ключ подписи:

wget https://packages.netxms.org/netxms-release-latest.deb
dpkg -i netxms-release-latest.deb
apt update
apt install netxms-server netxms-dbdrv-pgsql

Создание БД и инициализация схемы

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

apt install postgresql
su - postgres -c "createuser -P netxms"   # зададим пароль
su - postgres -c "createdb -O netxms netxms"

Дальше говорим серверу, где его база, — правим /etc/netxmsd.conf. Ключевых параметров четыре:

DBDriver = pgsql.ddr        # драйвер PostgreSQL
DBServer = 127.0.0.1        # хост СУБД
DBName = netxms             # имя базы
DBLogin = netxms            # пользователь
DBPassword = ВашПароль
LogFile = /var/log/netxmsd  # лог сервера — первым делом смотрим сюда при проблемах

Инициализируем схему и запускаем сервер:

nxdbmgr init
systemctl enable --now netxmsd
systemctl status netxmsd    # ждём active (running)

Веб-интерфейс и публикация через nginx

Инженеры ITfresh работают в десктопном клиенте (ставится на рабочую машину с сайта netxms.org), но клиенту всегда публикуем веб-консоль. Ставим веб-компоненты и прячем их за nginx с сертификатом Let's Encrypt:

apt install netxms-websvc nginx certbot python3-certbot-nginx
# nginx: проксируем 443 → локальный порт веб-консоли
certbot --nginx -d monitor.client-domain.ru

Наша грабля из ранних внедрений: certbot в режиме standalone хочет сам занять 80-й порт и падает, если nginx уже запущен. Лечится штатно — используем authenticator=nginx (как в команде выше): certbot договаривается с работающим веб-сервером и ничего останавливать не нужно.

Первый вход и базовая гигиена

Подключаемся клиентом к серверу: логин admin, пароль по умолчанию — netxms. Первые пять минут — гигиена, одинаковая для любой системы:

• сменить пароль admin на длинный из менеджера паролей;
• завести именные учётки инженеров со своими правами — в логах должно быть видно, кто что менял;
• проверить часовой пояс сервера: алерт «в 03:12» вместо «в 06:12» на разборе инцидента путает всех;
• настроить SMTP для почтовых уведомлений — штатный канал, работающий даже когда Telegram недоступен.

Русский интерфейс: что переведено, а что нет

Язык консоли переключается в настройках клиента — русский перевод есть и вполне рабочий. Останутся английскими серверные логи, документация и часть глубоких диалогов. Для дежурного инженера это не барьер; если консоль будет смотреть сотрудник клиента — предупредите его честно, мы всегда так делаем.

Автообнаружение: заставляем систему найти офис самостоятельно

Самая эффектная часть внедрения. В конфигурации Network Discovery указываем диапазон — типовой офис живёт в 192.168.0.0/24 — и включаем комбинированный режим: passive подхватывает узлы из ARP-таблиц и трафика, active методично опрашивает диапазон. Через час-полтора карта офиса построена: серверы, рабочие станции, коммутаторы, принтеры, ИБП — с типами устройств и связями.

SNMP-учётки — до запуска discovery, не после

Порядок действий принципиален: сначала внести в конфигурацию discovery все используемые SNMP credentials — community для v2c (у половины офисов это так и не изменённый public) и учётки v3, где железо поновее, — и только потом запускать сканирование. Если сделать наоборот, половина оборудования определится безликим «unknown node», и придётся передобавлять узлы или ждать переопроса. Мы на этом потеряли пару часов на первых внедрениях — теперь пункт стоит в чек-листе жирным.

Грабля: дубли узлов с двумя сетевыми интерфейсами

Сервер с двумя NIC (например, отдельная сеть для бэкапов) при сканировании двух подсетей появится на карте дважды — как два независимых узла. Лечение: во-первых, в NetXMS есть механизм обнаружения дублей по совпадающим идентификаторам системы; во-вторых, мы просто исключаем служебные подсети из discovery-диапазона фильтром — мониторить сервер достаточно по основному интерфейсу.

Что делать с найденным зоопарком

Плоский список из полусотни узлов неуправляем. Раскладываем найденное по контейнерам: «Серверы», «Сеть», «Печать», «Рабочие станции», «ИБП». Вручную это делается перетаскиванием за минуты, а на потоке мы вешаем автоматическое правило привязки на NXSL — скрипт смотрит на тип и имя узла и сам кладёт его в нужный контейнер. Шаблоны мониторинга потом применяются на контейнер целиком, а не на узлы поштучно.

Агенты на серверы и ключевые рабочие станции

SNMP и ICMP хороши для железок, но серверы мониторим только агентом — он видит службы, журналы и диски изнутри. Наше правило: агент — на все серверы и на рабочие станции ключевых сотрудников (главбух, директор), остальным станциям хватает discovery.

Windows: тихая установка через GPO на весь домен

Скачиваем MSI-пакет агента с netxms.org, кладём в сетевую шару и раскатываем одной групповой политикой. Ручная тихая установка выглядит так:

msiexec /i nxagent-6.2.4-x64.msi SERVER=192.168.0.10 /qn

Параметр SERVER сразу прописывает адрес сервера мониторинга в конфиг агента — после установки узел готов к опросу без единого клика. В брандмауэре Windows должен быть открыт входящий TCP 4700 — порт агента; MSI создаёт правило сам, но доменные политики файрвола бывают строже, проверьте это заранее.

Linux: пакет и MasterServers

apt install netxms-agent
# /etc/nxagentd.conf:
#   MasterServers = 192.168.0.10
systemctl enable --now nxagentd

Параметр MasterServers определяет, какие серверы имеют полный доступ к агенту — управление, обновление, выполнение действий. Указываем адрес нашего сервера мониторинга — и точка: любой другой узел сети агенту не команда.

Проверка связи и типовые причины Agent Unreachable

На узле в консоли запускаем Poll → Configuration и смотрим статус. Если агент недоступен, причина почти всегда одна из трёх: файрвол между сервером и агентом (проверяем 4700-й порт обычным telnet/Test-NetConnection), узел за NAT (тогда нужен прокси-агент или push-режим), либо несовпадение shared secret, если на агенте включали аутентификацию, а на сервере ключ не указали.

Филиал за NAT: прокси-агент вместо VPN

Если у клиента есть филиал без VPN до офиса, не спешите его строить ради мониторинга. Ставим на любую машину филиала агент в режиме прокси: он опрашивает локальную сеть филиала — и агентов, и SNMP-железки — и отдаёт всё центральному серверу одним исходящим соединением. На стороне филиального роутера не нужно ни одного проброса портов. Для сети из роутера, свитча, принтера и трёх компьютеров это решение на десять минут работы.

Что мониторим агентом сразу

Наш стартовый шаблон для любого Windows-сервера: свободное место всех дисков, загрузка CPU и памяти, состояние критичных служб (для сервера 1С — агент сервера 1С и СУБД, для терминалки — службы RDS, для файлового — служба печати и теневые копии), ошибки в системном журнале событий. На Linux аналогично: диски, load average, память, systemd-юниты, плюс срок действия TLS-сертификатов, если машина что-то публикует.

Пороги и события: чтобы алерты были полезными, а не спамом

Мониторинг умирает двумя способами: молчит о важном или орёт обо всём. Против второго — дисциплина порогов. Наши стандартные: свободное место на диске меньше 10% — предупреждение, меньше 5% — критика; CPU выше 90% непрерывно дольше 10 минут (не мгновенный пик — им можно); служба не запущена дольше двух минут (перезапуск при обновлении — не инцидент). Пороги задаются в DCI и оформляются шаблонами (Templates): настроил один раз — применил на контейнер «Серверы» целиком, новая машина получает все пороги автоматически при попадании в контейнер.

Второй уровень — правила обработки событий (Event Processing Policy). Здесь фильтруем: какие события генерируют алярм, какие — только пишутся в журнал; какие уходят в уведомления, а какие нет. Обязательно настраиваем «часы тишины» для некритичных предупреждений: warning в три часа ночи не должен будить никого — он подождёт девяти утра. Критика будит всегда, на то она и критика.

Уведомления в Telegram и на почту

В NetXMS есть встроенный драйвер канала уведомлений для Telegram — внешние скрипты и вебхуки не нужны. Создаём бота у @BotFather, получаем токен, добавляем бота в группу и узнаём chat id; в консоли создаём notification channel с драйвером Telegram и этими реквизитами. Дальше в правилах обработки событий указываем, что и куда слать.

Наш стандарт раздачи: критика — в Telegram-группу, где сидят и наши дежурные, и ответственный со стороны клиента (клиент видит, что мы среагировали, раньше, чем успевает спросить); предупреждения — только дежурному инженеру; всё подряд не шлём никуда — для истории есть журнал событий. Почта через корпоративный SMTP остаётся резервным каналом: Telegram имеет свойство оказываться заблокированным или лежать именно тогда, когда что-то горит.

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

Внедрение считается законченным не когда «вроде работает», а когда пройдена приёмка. Наша таблица из двенадцати проверок:

Пункт 11 регулярно вызывает улыбку — «мониторинг мониторит всех, а кто мониторит мониторинг?» — но система, которая следит за инфраструктурой, сама часть инфраструктуры, и её база с историей и настройками стоит недельной работы.

Для калибровки ожиданий: последнее такое внедрение на реальном офисе в 30 рабочих мест — два сервера, терминалка, два коммутатора, три МФУ, ИБП — заняло у нашего инженера 4 часа 20 минут, с перерывом на кофе и разговором с бухгалтерией о том, почему принтер «сам по себе» перезагружается (спойлер: ИБП). Если не хочется тратить свои полдня — придём и сделаем: контакты ниже. А дальше в серии — интеграции NetXMS с Active Directory и эксплуатационный регламент.