Зачем компании на 20–50 рабочих мест вообще мониторинг
Меня зовут Евгений Семёнов, я технический директор ITfresh. Пятнадцать с лишним лет мы занимаемся IT-аутсорсингом для московских компаний до пятидесяти рабочих мест, держим собственные серверы в дата-центре МТС — и за эти годы я перепробовал на клиентах, кажется, все системы мониторинга, какие бывают. Эта статья открывает серию про NetXMS — систему, которая стала нашим дефолтным ответом для заказчиков без выделенного инженера. Но начну не с неё, а с вопроса, который слышу на каждой второй встрече: «Зачем нам мониторинг, у нас же всё работает?»
Отвечаю всегда одинаково. Без мониторинга о переполненном диске сервера 1С аутсорсер узнаёт от главного бухгалтера — в момент, когда база уже не проводит документы и отдел из десяти человек пьёт чай за счёт работодателя. Посчитайте сами: час простоя терминального сервера — это зарплата всех, кто на нём работает, плюс невыставленные счета, плюс нервы. У компании на тридцать человек одна такая авария легко стоит больше, чем годовое сопровождение всей системы мониторинга. Которая, в случае NetXMS, бесплатна.
И главное — статистика по нашим клиентам стабильно показывает: около 80% инцидентов предсказуемы за дни и недели. Диск не переполняется внезапно — он заполняется месяцами. Сертификат не истекает неожиданно — дата известна за год. Бэкап не «вдруг» отсутствует в день аварии — он молча не выполнялся три недели. Всё это ловится примитивными порогами и превращает аварию в плановую задачу на вторник. Ровно поэтому мониторинг — первое, что мы разворачиваем у нового клиента, ещё до наведения порядка в остальном.
Свежий пример из практики. Приняли на сопровождение компанию на 25 рабочих мест: сервер 1С, файловый сервер, терминалка. В первую же неделю после установки мониторинга система показала: на сервере 1С осталось 8% места, и заполняется он на процент в неделю — журналы регистрации никто не чистил года три. Плановая чистка заняла двадцать минут в обеденный перерыв. Без мониторинга через два месяца это была бы классическая авария «1С не работает, все стоят» с восстановлением на полдня. Разница между этими сценариями и есть ответ на вопрос «зачем».
Что такое NetXMS и кто за ним стоит
NetXMS — open-source система мониторинга сети и инфраструктуры, которую с 2003 года развивает латвийская компания Raden Solutions. Лицензия — GPLv2: сервер, агенты и клиент бесплатны, в том числе для коммерческого использования, без ограничений по числу узлов, метрик или пользователей. Модель бизнеса вендора — платная техподдержка и доработки, сам продукт полнофункционален в открытой версии, никаких «community edition с урезанными фичами».
Проект живой, и это важный критерий выбора: актуальная ветка 6.2.x получает релизы каждые несколько недель — на момент написания статьи свежая версия 6.2.4 вышла 2 сентября 2026 года. Консервативная ветка 5.2.x получала патчи до февраля 2026-го, так что цикл поддержки предсказуем. Для установки есть подписанные APT- и YUM-репозитории под Debian, Ubuntu и RHEL-семейство — обновления приезжают штатным пакетным менеджером, а не «скачайте архив с форума».
Архитектура на пальцах: агент → сервер → консоль
Устроен NetXMS просто, и это его сила. В центре — сервер netxmsd, который хранит конфигурацию и собранные метрики в СУБД: поддерживаются PostgreSQL, MySQL/MariaDB, Oracle и SQLite. На наблюдаемые машины ставится лёгкий агент nxagentd — есть под Windows, Linux и ещё десяток платформ. Управляется всё из десктопного клиента или веб-интерфейса — функционально они почти эквивалентны, инженеры у нас живут в десктопном, заказчикам показываем веб.
Чем агентный сбор лучше чистого SNMP для Windows-парка
Для сетевых железок SNMP — родной язык, но мониторить по нему Windows-сервер — мучение. Агент NetXMS снимает состояние служб, читает журналы событий, выполняет WMI-запросы и произвольные команды, следит за процессами и файлами — всё то, ради чего с чистым SNMP пришлось бы танцевать с бубном или ставить сторонние расширения. Плюс канал агент-сервер шифруется, а агент умеет работать в режиме push через firewall.
Прокси-агенты и зоны: недооценённая фича для филиалов
Отдельно выделю механизм, о котором редко пишут в обзорах, а для распределённого малого бизнеса он решающий: зоны и прокси-агенты. Филиал за NAT, куда нет VPN? Ставим в филиале один агент в режиме прокси — и он собирает данные со всей локальной сети филиала (включая SNMP-опрос местных железок) и отдаёт их центральному серверу через единственное исходящее соединение. Не нужно ни пробрасывать порты, ни городить туннели ради мониторинга. У нас так наблюдаются филиалы клиентов, где из инфраструктуры — роутер, свитч, принтер и три компьютера.
Ключевые возможности, за которые мы его выбираем
Автообнаружение сети
Указали подсеть офиса — через час карта построена: серверы, рабочие станции, коммутаторы, принтеры, ИБП. NetXMS сам определяет тип устройства, снимает топологию по LLDP/CDP и раскладывает связи между узлами. Для аутсорсера, который приходит в новый офис с неизвестным «зоопарком», это первый диагностический инструмент: карта сети до всякой документации.
Мониторинг серверов Windows и Linux
Стандартный набор через агента: процессор, память, диски, службы и процессы, журналы событий, сроки действия сертификатов, статусы задач планировщика. Наш типовой шаблон для сервера 1С отслеживает полтора десятка параметров — от свободного места под базами до состояния службы агента сервера 1С.
SNMP-оборудование
Коммутаторы, ИБП, принтеры, NAS — всё, что говорит по SNMP, встаёт на мониторинг из коробки. Для распространённых вендоров есть готовые определения; под экзотику придётся разобрать MIB руками — об этом честно скажу в минусах.
Карты сети и дашборды
Карты в 5.x/6.x серьёзно переработали — теперь они пристойно выглядят и на инфраструктуре в несколько сотен узлов: слои, группировка, автоматическая укладка. Дашборды собираются из готовых виджетов мышкой; у нас на каждого клиента есть экран «здоровье офиса», который мы показываем на квартальных встречах.
Пороги, шаблоны и история метрик
Сбор метрик организован через DCI — элементы сбора данных с индивидуальными интервалами, порогами и правилами хранения. Пороговые условия гибче примитивного «больше/меньше»: можно требовать удержания значения в течение времени (процессор выше 90% дольше десяти минут — а не мгновенный пик), сравнивать с средним за период, ловить отсутствие данных как отдельное событие. Настройки оформляются в шаблоны и применяются к группам узлов разом: наш шаблон «Windows-сервер» вешается на новую машину за секунды, и она сразу мониторится по всем стандартам. История метрик хранится в БД с настраиваемой глубиной — графики за год для разговора «пора ли расширять диск» всегда под рукой.
События, эскалации и уведомления
Механизм обработки событий гибкий: правила фильтруют поток по важности, источнику и времени, эскалация поднимает уровень, если алярм не взят в работу. Каналы уведомлений — от классической почты до встроенного Telegram-драйвера, который для наших клиентов стал стандартом: критика падает в общую группу с клиентом, предупреждения — только дежурному инженеру.
Бизнес-сервисы и SLA
Фича, которая продаёт мониторинг собственнику: узлы группируются в бизнес-сервис («работа 1С» = сервер + СУБД + сеть + терминалка), и система считает его доступность в процентах. В договоре сопровождения появляется измеримый SLA, а в отчёте за месяц — честная цифра, а не «вроде всё работало».
Что нового в NetXMS 6.x, о чём не писали русскоязычные обзоры
Русскоязычные статьи про NetXMS в массе своей описывают версии пяти-семилетней давности. Между тем в шестой ветке появилось то, чего от скромной опенсорсной системы мониторинга никто не ждал: встроенный AI-ассистент. Прямо в консоли можно спросить на естественном языке «что случилось с файловым сервером за ночь» или «какие алярмы сейчас требуют внимания» — ассистент анализирует состояние инфраструктуры и отвечает по существу. Работает поверх LLM на выбор: локальной модели или облачного провайдера.
Интегрировано это и в скриптовый движок: функция QueryAIAssistant в NXSL позволяет дёргать ассистента из любого скрипта, передавая объект инфраструктуры как контекст, а через библиотеку скриптов ассистенту можно добавлять собственные инструменты — фактически расширять его действия своим кодом.
Теперь честная оценка, как я её проговариваю клиентам: фича ранней стадии. В продакшен у заказчиков мы AI-ассистента пока не тащим — для типового офиса на 30 машин достаточно детерминированных порогов, а каждый новый компонент — это поверхность отказа и вопросы к тому, куда уходят данные при облачной LLM. Но сам вектор показателен: вендор развивает продукт в актуальную сторону, а не поддерживает legacy. Плюс из практичного в 6.x — улучшенная миграция данных с 5.x: переезд между мажорными версиями стал рутиной, а не проектом.
NetXMS против Zabbix: сравнение без фанатизма
Мы активно используем обе системы — про Zabbix у нас есть отдельный обзор — поэтому сравниваю не по форумным холиварам, а по своим трудозатратам:
| Критерий | NetXMS | Zabbix |
|---|---|---|
| Время до первого работающего мониторинга | у нас — около 3 часов | 1–2 дня с настройкой шаблонов |
| Порог входа | ниже: логика «поставил — обнаружил — следишь» | выше: items, triggers, macros — своя вселенная |
| Готовые шаблоны сообщества | мало, базовое — из коробки | тысячи, почти под любую железку |
| Комьюнити и статьи | компактное | на порядок больше, включая русскоязычное |
| Русская документация | нет (консоль переведена) | официальная документация переведена |
| Аппетиты к железу | скромные: 2 vCPU/4 GB на сотню узлов | сопоставимо, но растут быстрее с числом метрик |
| Масштаб | уверенно до сотен узлов, зоны для филиалов | тысячи узлов, прокси, кластеризация |
Мой вывод за годы эксплуатации обеих: до двухсот узлов и без выделенного инженера по мониторингу — NetXMS, время до результата в разы меньше. DevOps-команде с тысячами метрик, кастомными экспортёрами и жаждой готовых шаблонов — Zabbix. Это не «лучше/хуже», это разные точки на кривой «мощность против трудозатрат».
Честные минусы
Чтобы обзор не превратился в рекламу, перечислю то, обо что спотыкаются:
- Документация только на английском. Консоль переведена на русский, у вендора есть официальный YouTube-плейлист на русском языке — но админгайд придётся читать по-английски. Для инженера это норма, для «админа поневоле» — барьер.
- Меньше готовых интеграций, чем у Zabbix или Prometheus. Экспортёров «под всё на свете» нет; штатно закрыты типовые случаи, остальное — руками через агента или скрипты.
- Компактное комьюнити. Ответ на нестандартный вопрос ищется в официальном форуме и исходниках, а не в тысяче статей на Хабре.
- Нестандартные железки — через разбор MIB. Если ваш китайский ИБП не определился, придётся импортировать MIB-файл и описывать метрики самостоятельно.
- NXSL. Скриптовый язык системы — ещё один язык для изучения. Синтаксис C-подобный и простой, но это всё равно время инженера.
Насколько эти минусы критичны — зависит от того, кто эксплуатирует. Для аутсорсера вроде нас они почти не ощущаются: английская документация читается, MIB разбирали сотню раз, а компактность комьюнити компенсируется отзывчивостью разработчиков на официальном форуме — на вопросы там нередко отвечают сами авторы системы. Для компании, где мониторингом займётся «самый компьютерный» сотрудник без опыта, каждый пункт списка превращается в стену. Это стоит трезво оценить до выбора системы.
Кому подходит, кому нет — и что дальше в серии
Идеальный профиль: офис или небольшая компания до 50 рабочих мест, пара-тройка серверов, сетевые железки, филиалы за NAT — и приходящий админ или аутсорсер, которому нужно знать о проблемах раньше пользователей, не тратя недели на настройку. Сюда же — управляемый мониторинг многих маленьких клиентов: бесплатная лицензия и зоны делают NetXMS отличным инструментом аутсорсера.
Кому не подходит: как APM для разработчиков — трассировок и профилирования приложений здесь нет; для метрик с секундным разрешением и долгих time-series аналитик — это территория Prometheus и VictoriaMetrics; для NOC-центров на тысячи узлов со штатом инженеров — Zabbix даст больше готового.
Дальше в серии — практика: пошаговое развёртывание сервера на Debian 12 с агентами на Windows и автообнаружением (по нашему внутреннему регламенту), интеграции с Telegram и Active Directory, регламент эксплуатации и кейс внедрения у клиента. Если мониторинг нужен уже сейчас и без чтения серии — контакты внизу, развернём и отдадим под ключ.
Оставить комментарий