Эксплуатация NetXMS: обновления, бэкап конфигурации, безопасность и производительность — регламент на годы вперёд

Почему «поставил и забыл» не работает

Меня зовут Евгений Семёнов, я технический директор ITfresh — мы делаем IT-аутсорсинг для компаний до 50 рабочих мест в Москве, свои серверы держим в дата-центре МТС. Это четвёртая статья серии про NetXMS. В предыдущих мы выбирали систему, внедряли её с нуля и дотягивали скриптами и Grafana до реальных задач. Сегодня — самая скучная и самая важная тема: как эксплуатировать систему мониторинга годами, чтобы она не умерла тихой смертью.

Мониторинг, за которым никто не следит, живёт около полугода. Мы принимали на обслуживание инфраструктуры, где «мониторинг вроде был», и вскрытие показывало один из трёх типовых сценариев смерти:

• Переполнилась база данных. Диск под PostgreSQL кончился, сервер мониторинга перестал писать данные, алерты — уходить. Никто не заметил: система, которая должна кричать о переполнении дисков, не мониторила собственный.
• Протух сертификат веб-консоли. Браузер начал пугать инженеров красным экраном, в консоль перестали заходить, через месяц о ней забыли. Формально всё работало.
• После обновления ОС не поднялся netxmsd. Плановый апдейт Debian, несовместимость, сервис в рестарт-цикле. Тишина в канале алертов была воспринята как «всё хорошо» — худшая из возможных интерпретаций.

Общий корень всех трёх историй: у системы мониторинга не было своего надзирателя. Отсюда главный принцип нашего регламента — мониторинг обслуживается по расписанию, как боевой сервер, и за ним следит кто-то внешний. Разберём регламент по частям.

Стратегия обновлений

NetXMS развивается быстро: на момент написания актуальна ветка 6.2 (свежий релиз 6.2.4 вышел в начале сентября 2026-го), и патчи с исправлениями выходят почти ежемесячно. Наша схема разделяет обновления на два потока.

Минорные обновления (6.2.3 → 6.2.4) ставим ежемесячно из APT-репозитория проекта. Процедура отработана до автоматизма:

# плановое минорное обновление сервера NetXMS
systemctl stop netxmsd
apt update && apt upgrade
nxdbmgr upgrade        # миграция схемы БД до новой версии
systemctl start netxmsd
journalctl -u netxmsd -n 50   # убедиться, что поднялся чисто

Ключевой шаг — nxdbmgr upgrade: утилита приводит схему базы к версии сервера. На минорных апдейтах это секунды, но пропускать шаг нельзя — сервер с несовпадающей схемой просто не стартует, и вы узнаете об этом в самый неудобный момент.

Мажорный переезд 5.2 → 6.x: только со снапшотом

Мажорное обновление — отдельная дисциплина. Мы прошли переезд с ветки 5.2 на 6.x на всех обслуживаемых инсталляциях, и правила выработались такие:

• Снапшот ВМ обязателен. Не бэкап базы, а именно снапшот всей машины перед началом: откат при проблеме — минута, а не вечер восстановления.
• Читаем release notes за все пропущенные версии. В мажорных ветках меняется поведение — от форматов конфигурации до логики обработки событий.
• Миграция схемы на большой базе — это долго. На базе в десятки гигабайт nxdbmgr upgrade может работать десятки минут: закладывайте окно с запасом и не прерывайте процесс.
• Порядок: сначала сервер, потом агенты. Проект сохраняет совместимость старых агентов с новым сервером, поэтому парк из сотни агентов может спокойно догоняться неделями — мониторинг при этом работает.

Агенты: обновляет сам NetXMS

Обновлять агенты руками на 100 машинах — путь в никуда. Штатный механизм — централизованное обновление через сам сервер: пакет нового агента загружается в NetXMS, и система раскатывает его на выбранные узлы. Это рекомендуемый проектом способ, и он же наш основной. Резервный вариант для Windows-доменов — GPO/скрипт установки MSI: пригождается на машинах, куда агент ставится впервые.

Когда НЕ обновляться

Свежий релиз x.y.0 первые две-три недели мы не трогаем — пусть обкатается на чужих инсталляциях. Исключение одно: если в релизе закрыта уязвимость безопасности (а в changelog проекта такие пункты прямо помечаются — например, недавно исправлялись проблемы раскрытия информации в веб-API), обновляемся немедленно, вне графика.

Резервное копирование и восстановление за 30 минут

Цель формулируем не как «бэкап делается», а как «инсталляция восстанавливается на чистой ВМ за 30 минут». Из этой цели следует список того, что копируем ежедневно:

Экспорт конфигурации — момент, который многие пропускают. Дамп БД восстанавливает всё, но он монолитен: из него нельзя достать «только шаблон, который сломали вчера». XML-экспорт шаблонов и правил, сложенный в git, даёт поштучный откат и заодно документирует, кто и когда что менял.

Тест восстановления — раз в полгода

Бэкап, который ни разу не восстанавливали, — это лотерейный билет. По регламенту дважды в год мы разворачиваем инсталляцию из бэкапа на чистой ВМ: установка пакетов из APT, восстановление дампа, подкладывание конфигов и сертификатов, запуск. Последний такой тест у нас занял 24 минуты до состояния «консоль открывается, данные на месте, агенты переподключились». Если ваш тайминг сильно больше — чаще всего дело в том, что процедура нигде не записана и инженер вспоминает её на ходу.

Housekeeper и retention: чтобы база не съела диск

Размер базы — функция от политики хранения. За чистку отвечает встроенный housekeeper, а сроки задаются политикой хранения данных в DCI. Наш стандарт для клиентских инсталляций: сырые данные — 90 дней. Этого хватает на разбор любого инцидента и на сезонные сравнения «а как было в прошлую отчётность», при этом база клиента на ~100 узлов и несколько тысяч метрик стабильно держится в районе 10–15 ГБ. Если храните «всё и навсегда» — готовьтесь к базе в сотни гигабайт и деградации выборок. Отдельно раз в квартал стоит смотреть на метрики, у которых retention переопределён руками: они имеют свойство накапливаться.

Безопасность сервера мониторинга

Неудобная правда: сервер мониторинга — цель номер один для атакующего. Он знает всю карту сети, в нём лежат SNMP-коммьюнити и учётки к железу, его агенты стоят на каждом сервере и умеют выполнять команды. Компрометация мониторинга — это компрометация всего, поэтому защищаем его строже, чем рядовой сервер.

• Консоль — только изнутри. Веб-консоль и порт сервера не публикуются в интернет. Доступ инженеров — через VPN; если VPN невозможен, то reverse-proxy с TLS, ограничением по IP и отдельной аутентификацией. «Временно откроем 8080 наружу» — так не делаем никогда.
• Двухфакторная аутентификация. В NetXMS встроена 2FA по TOTP: включается на уровне системы, привязывается в свойствах пользователя, коды генерирует любое приложение-аутентификатор. Для учёток с административными правами у нас она обязательна.
• Роли и минимальные права. Инженеру дежурной смены не нужны права на изменение шаблонов — достаточно просмотра и подтверждения алармов. Разделение ролей стоит полчаса настройки и снимает целый класс проблем «кто-то что-то поменял».
• Шифрование агент-сервер. Связь агентов с сервером шифруется, агент доверяет только серверам из своего списка (MasterServers), при необходимости добавляется shared secret. При увольнении администратора клиента, знавшего секреты, — меняем их, как поменяли бы пароль.
• Аудит-лог. Консоль ведёт журнал действий: кто подтвердил аларм, кто заглушил узел, кто поменял порог. При разборе «почему мы не узнали о проблеме» этот журнал экономит часы и снимает конфликты: видно, что аларм в пятницу вечером заглушили, а не «система не сработала».

Производительность и ёмкость: когда одной ВМ мало

Спойлер: малому бизнесу — почти никогда. Реальные цифры с типовой нашей инсталляции — около 100 узлов и порядка 4000 метрик: ВМ с 2 vCPU и 4 ГБ памяти, загрузка процессора в единицы процентов, памяти сервер и СУБД съедают около половины. Узкое место — не CPU и не память, а диск под базой: PostgreSQL постоянно пишет собранные значения, и на медленном хранилище именно запись становится тормозом. SSD для тома БД — единственное «железное» требование, которое мы предъявляем.

Тюнинг очевидного

Прежде чем думать о масштабировании, стоит перестать собирать лишнее:

• Интервалы опроса. Дефолтные 60 секунд нужны единицам метрик (доступность критичных сервисов). Температуре в серверной, тонеру принтера и месту на архивном томе достаточно 300–600 секунд. Перевод «толстых» метрик на редкий опрос снижает нагрузку в разы.
• Сбор «на всякий случай». Каждая метрика должна отвечать на вопрос «какое действие мы предпримем по её порогу». Нет ответа — метрика не нужна. Это и про производительность, и про гигиену алертов.
• Пороговые события вместо частых графиков: там, где важен факт «стало плохо», а не форма кривой, редкий опрос с порогом дешевле частого сбора.

Признаки деградации

NetXMS отдаёт внутренние метрики о самом себе — очереди на обработку данных, среднее время ожидания в очереди, отставание поллеров. Мы выводим их на служебный дашборд: устойчивый рост очередей — ранний признак того, что сервер перестаёт успевать (обычно это сигнал про диск БД). Второй маркер — «рваные» графики с пропусками при живых узлах: данные собираются быстрее, чем записываются. Оба симптома появляются за недели до реальных проблем — успеете отреагировать спокойно.

Мониторинг мониторинга

Вернёмся к корню всех историй из начала статьи. Кто следит за самим сторожем? Ответ регламента: внешний и максимально тупой watchdog — настолько простой, чтобы ему нечем было сломаться. У нас это два уровня:

• Cron-скрипт на другом хосте (у нас — на сервере вне площадки клиента), который раз в 10 минут проверяет: порт сервера NetXMS отвечает, веб-консоль отдаёт страницу логина, в базе появлялись свежие значения за последние полчаса. Любой провал — сообщение в Telegram дежурному по каналу, не зависящему от самого NetXMS.
• Бесплатный внешний uptime-сервис как третье мнение — на случай, когда лежит вся площадка вместе с нашим скриптом.

Проверка «свежести данных» принципиальна: процесс netxmsd может быть жив, порт — открыт, а сбор данных — стоять. Живость процесса не равна работоспособности системы. И общее правило, которое мы повторяем клиентам: система мониторинга, которая молчит неделю, вероятно, мертва, а не идеальна. Тишину надо проверять так же, как и шум.

Типовые проблемы эксплуатации и их решения

Пять граблей, на которые мы наступали сами или разгребали за другими:

1. Агент перестал отвечать после смены IP сервера. Агент доверяет серверам из директивы MasterServers в своём конфиге. Переехал сервер на новый адрес — агенты вежливо отказывают ему в доступе. Лечение: перед миграцией добавить новый IP вторым значением на всех агентах (через сам NetXMS, пока он ещё «старый»), после переезда — убрать старый.
2. Рассинхрон времени и «дырявые» графики. Узел с уехавшими часами присылает значения «из прошлого» или «из будущего», график превращается в решето, пороги срабатывают невпопад. Лечение: NTP на всех узлах — и отдельная метрика смещения времени с порогом; она копеечная, а ловит проблему до того, как та испортит данные.
3. Шторм событий от flapping-узла. Узел с умирающим блоком питания уходит и приходит каждые две минуты, генерируя тысячи событий и раздувая журнал. Лечение: гистерезис на порогах (срабатывание после N повторов), а для хронического пациента — режим обслуживания до замены железа. Журнал событий чистится housekeeper'ом, но лучше не создавать ему работу.
4. Конфликт версии схемы БД после отката. Откатили пакет сервера на версию ниже, а схема базы уже мигрирована новой nxdbmgr — сервер не стартует. Лечение: откатываться только вместе с базой (тот самый снапшот ВМ) либо вперёд — доустановкой новой версии. Схема БД мигрирует только вверх, это надо принять как закон.
5. Веб-консоль падает по памяти Java. Веб-интерфейс — Java-приложение в сервлет-контейнере; при большом числе одновременных сессий дефолтного heap может не хватать. Лечение: поднять -Xmx в параметрах JVM и перезапустить контейнер. Симптом узнаваем: консоль «замирает» и отваливается, при этом сам netxmsd и сбор данных живут как ни в чём не бывало.

Годовой регламент одним листом

Итоговая арифметика: 2–4 часа инженерного времени в месяц на клиентскую инсталляцию — и мониторинг работает годами, переживая обновления ОС, переезды и смену команды. Для сравнения: разбор одного-единственного «тихо умершего» мониторинга с восстановлением доверия к нему стоит дороже года такого обслуживания.

В следующей — финальной — статье серии будет сквозной кейс: полная конфигурация мониторинга бухгалтерской фирмы на 30 рабочих мест, с узлами, порогами и честной статистикой за квартал. А если регламент из этой статьи хочется получить «как услугу» — это ровно то, чем мы в ITfresh занимаемся каждый день.