NetXMS в бою: NXSL-скрипты, Grafana, мониторинг 1С и миграция с Zabbix и PRTG — интеграции без бюджета

Коробки хватает на 80% — разбираем оставшиеся 20%

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

А происходит всегда одно и то же. Клиент привыкает, что «упал сервер — пришло сообщение», и начинает просить большего. Список «хотелок» у наших клиентов повторяется с точностью до формулировок:

• «Предупредите заранее, что сертификат протухает» — после того как у кого-то встала сдача отчётности из-за просроченного сертификата на терминальном сервере.
• «Проверяйте, что ночной бэкап реально сделался» — обычно после истории, когда бэкап «делался» три недели в никуда.
• «Следите за 1С, а не только за железом» — потому что для бухгалтерии живость rphost важнее, чем загрузка процессора.
• «Покажите директору красивую картинку» — дашборд со статусом всего офиса, желательно на телевизоре.

Хорошая новость: всё это в NetXMS решается штатными механизмами, без единой купленной лицензии. Плохая (для любителей «поставил и забыл»): решается руками — скриптами, порогами и обвязкой. Ниже я показываю, как именно мы это делаем на реальных инсталляциях, и во сколько инженерных часов обходится каждая доработка.

NXSL — встроенный язык, который проще, чем звучит

Главный инструмент кастомизации в NetXMS — встроенный скриптовый язык NXSL (NetXMS Scripting Language). Если вы хоть раз писали на чём-то C-подобном — на PHP, JavaScript, да хоть в 1С с фигурными скобками, — синтаксис вы прочитаете сразу: переменные, if, for, функции. Скрипты складываются в библиотеку скриптов прямо в консоли управления и дальше используются везде: как источник данных для метрики (DCI с типом «Script»), как трансформация собранного значения, как условие в правилах обработки событий.

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

Пример 1: срок действия сертификата в хранилище Windows

Задача: за три недели до истечения сертификата (RDP, публикация 1С, TLS веб-сервера) должно прийти предупреждение. Мы решаем её через механизм внешних метрик агента: в конфигурацию nxagentd на Windows-сервере добавляется параметр ExternalParameter, который запускает короткий PowerShell-однострочник — тот проходит по хранилищу LocalMachine\My, находит ближайший к истечению сертификат и возвращает число дней до его конца. Дальше это обычная числовая метрика NetXMS:

# фрагмент nxagentd.conf на Windows-сервере
ExternalParameter = Cert.MinDaysLeft : powershell -NoProfile -Command ^
  "(Get-ChildItem Cert:\LocalMachine\My | Sort-Object NotAfter | ^
  Select-Object -First 1).NotAfter - (Get-Date) | ^
  ForEach-Object { [int]$_.TotalDays }"

На метрику вешаем два порога: «меньше 21 дня» — предупреждение инженеру, «меньше 7 дней» — критика с эскалацией. Идея не нова — похожие кейсы админы описывали ещё много лет назад, — но в актуальной версии NetXMS 6.2 всё собирается за 20 минут: параметр в конфиг агента, перезапуск службы, DCI с порогами в шаблоне. Один раз положили в шаблон — применилось ко всем терминальным серверам всех клиентов.

Пример 2: свежесть файла бэкапа

Проверять надо не «задача бэкапа отработала без ошибок», а «файл бэкапа существует и он свежий». Это разные вещи: задача может честно отработать и сложить архив на отвалившийся диск. У агента NetXMS есть семейство метрик File.* — размер, количество, время изменения файла. Берём File.Time.Modify по маске каталога с бэкапами, в трансформации превращаем «время последнего изменения» в «возраст в часах» и ставим порог: старше 26 часов — алерт. Почему 26, а не 24: ночное окно бэкапа плавает, и лишние два часа запаса убирают ложные срабатывания в понедельник утром.

Сюда же — контроль размера: если вчерашний бэкап весил 80 ГБ, а сегодняшний 2 МБ, формально файл свежий, но доверять ему нельзя. Второй DCI по File.Size с порогом «упал больше чем на 70% от вчерашнего» ловит и это.

Пример 3: вычисляемые метрики и трансформации

Классика: агент отдаёт свободное место в байтах и общий объём в байтах, а порог хочется в процентах. Вместо двух порогов на абсолютные числа создаём вычисляемый DCI: скрипт трансформации на NXSL берёт значения двух соседних метрик, делит одно на другое и возвращает проценты. Дальше один порог «меньше 10% свободного» работает одинаково и на диске в 120 ГБ, и на томе в 4 ТБ. Тот же приём мы используем для «процента занятых RDP-сессий от лимита» и «доли ошибок печати от общего числа заданий».

Мониторим 1С и MS SQL — то, ради чего малый бизнес вообще нас зовёт

Честно: клиенту до 50 рабочих мест почти безразлична загрузка CPU на файловом сервере. Звонит он тогда, когда «1С не открывается». Поэтому слой мониторинга 1С мы считаем обязательным минимумом, и собирается он из простых кирпичей:

• Процессы кластера 1С. Метрика Process.Count(ragent.exe) и Process.Count(rphost.exe) — агент 1С и рабочие процессы должны существовать. Порог «rphost меньше одного» — критика. Полезен и верхний порог: если рабочих процессов внезапно стало втрое больше обычного, кластер, скорее всего, лихорадит рестартами.
• Службы Windows. Служба агента сервера 1С и служба SQL Server проверяются как состояние службы — не «процесс есть», а именно «служба в состоянии Running». Разница всплывает при зависших службах.
• TCP-порты кластера. Проверка доступности порта 1541 (менеджер кластера) и диапазона rphost — сетевые сервисные проверки NetXMS делают это с самого сервера мониторинга, что честнее локальной проверки: заодно проверяется и сеть до сервера.
• Место под базами. Отдельные DCI на тома с файлами данных, журналами транзакций и tempdb. Порог по журналам транзакций жёстче: они умеют съедать диск за одну ночь при сбившемся плане обслуживания.

Проверка публикации 1С: HTTP-check с ключевым словом

Если базы опубликованы на IIS или Apache для веб-клиента и мобильных пользователей, добавляем HTTP-проверку: NetXMS запрашивает страницу публикации и ищет в ответе ожидаемую строку. Просто «код 200» недостаточно — сервер может отдавать красивую страницу ошибки с кодом 200. Поиск по ключевому слову в теле ответа отсекает и этот случай. Одна такая проверка однажды поймала у клиента ситуацию, когда после обновления платформы публикация поднялась, но с пустым default.vrd — снаружи всё выглядело живым.

Почему мы не лезем в счётчики производительности SQL

Можно собирать сотни счётчиков MS SQL: кэш-хиты, ожидания, блокировки. Мы на этом классе клиентов сознательно этого не делаем. Принцип разумной достаточности: цель мониторинга у фирмы на 30 рабочих мест — узнать о проблеме раньше пользователя, а не провести перформанс-аудит СУБД. Для «1С тормозит» есть отдельная экспертиза с замерами АПДЕКС, и это уже проектная работа, а не мониторинг. Перегруженная метриками система умирает первой: в ней тонут действительно важные алерты.

Уведомления следующего уровня

Базовое «письмо на почту админа» перестаёт работать примерно на десятом алерте. Дальше начинается настоящая настройка:

• Каналы уведомлений. В NetXMS канал — это абстракция с драйверами: SMTP-почта, Telegram, Slack, Microsoft Teams, SMS через GSM-шлюз. Для наших клиентов стандарт — Telegram-канал: драйвер встроенный, достаточно токена бота. Для экзотики есть shell-драйвер — любой скрипт с curl до любого API.
• Эскалация. Правила обработки событий позволяют строить цепочку: алерт ушёл дежурному; если событие не обработано за 15 минут — повтор с пометкой «эскалация» уже в общий канал смены. Ночью у критики короче цепочка и громче канал.
• Подавление шторма. Самое важное. Когда падает роутер филиала, наивный мониторинг шлёт 20 алертов по всем узлам за ним. NetXMS использует топологию сети для корреляции: узлы за упавшим шлюзом помечаются как недостижимые, а не «упавшие», и событие приходит одно — про шлюз. Это надо один раз настроить (система должна знать топологию — маршруты и зависимости), но именно это отличает мониторинг, которому доверяют, от чата, который замьютили.

Плановые окна обслуживания

Ночные работы — обновления, перезагрузки, тесты бэкапов — не должны будить дежурного. Перед работами узел переводится в режим обслуживания: события копятся, но уведомления не рассылаются. Можно руками из консоли, можно по расписанию — на регулярные ночные перезагрузки терминальных серверов у нас заведены запланированные окна. Мелочь, но именно такие мелочи определяют, читает команда алерты или нет.

Grafana поверх NetXMS — красивый дашборд директору за час

Встроенные графики NetXMS функциональны, но директору показывать их бесполезно: это инструмент инженера. Когда клиент хочет «картинку здоровья компании», мы ставим рядом Grafana. Связка официальная: у NetXMS есть плагин-источник данных для Grafana (radensolutions-netxms-datasource), который общается с сервером через REST API — компонент netxms-websvc, разворачиваемый как WAR-приложение в сервлет-контейнере рядом с сервером мониторинга.

Схема выглядит так:

Grafana ──HTTP──▶ netxms-websvc (REST API, war в Jetty/Tomcat)
                      │
                      ▼
                netxmsd (сервер NetXMS) ──▶ PostgreSQL (собранные метрики)

Дальше — обычная работа в Grafana: панели с метриками по любому узлу, таблица активных алармов, цветовые пороги. Наш типовой «дашборд директора» — это шесть плиток: интернет-каналы офисов, терминальный сервер, сервер 1С, почта, бэкапы, ИБП. Всё зелёное — можно не звонить в поддержку. Такой экран на телевизоре в переговорке даёт неожиданно сильный эффект при сдаче проекта: мониторинг из невидимой услуги превращается в осязаемую.

Важная оговорка: Grafana — это опция, а не необходимость. Если потребителей дашбордов двое инженеров, встроенных дашбордов NetXMS достаточно, и лишний компонент в контуре (со своими обновлениями и своей аутентификацией) мы не разворачиваем. Инструмент добавляется тогда, когда у него есть зритель.

Миграция с других систем: наш опыт

За последние годы мы переводили клиентов на NetXMS с трёх стартовых позиций, и у каждой своя специфика.

С PRTG: когда кончились 100 бесплатных сенсоров

Типовая история: PRTG поставили на бесплатном тарифе, он отличный, но лимит в 100 сенсоров у растущей компании кончается за год — а дальше ценник за лицензию, который для фирмы на 30 рабочих мест выглядит как бюджет всего IT за квартал. Переезд мы делаем через карту соответствия: выгружаем список сенсоров PRTG и для каждого решаем, чем он станет в NetXMS — метрикой агента, SNMP-запросом, сервисной проверкой. Что теряем: отчёты PRTG действительно красивее из коробки, и их отсутствие надо честно проговорить (частично закрывается той же Grafana). Что выигрываем: лимита нет вообще — хоть 5000 метрик, ноль рублей лицензий.

С Zabbix: чужой огород без садовника

Второй сценарий деликатнее: Zabbix поставил предыдущий админ, админ ушёл, и никто в компании не понимает, почему триггеры срабатывают и что значат их имена. Технически Zabbix — сильная система, мы про неё писали отдельный обзор, и если у клиента она настроена и понятна — мы её оставляем. Мигрируем тогда, когда стоимость реверс-инжиниринга чужой конфигурации превышает стоимость настройки с нуля. Правило миграции: 2–4 недели параллельной работы двух систем. NetXMS разворачивается рядом, наполняется по нашему стандарту, и пока обе системы шлют алерты, мы сверяем: всё ли, что ловил старый мониторинг, ловит новый. Только после этого старый выключается.

С «мониторинга не было»: самый частый и самый простой случай

Парадоксально, но чистый лист — лучшая стартовая позиция: нет ни легаси-конфигурации, ни привычек «у нас всегда так алертило». Ставим по нашему стандартному шаблону, две недели тюним пороги под конкретную инфраструктуру — готово.

Шаблоны как код: перенос конфигурации между инсталляциями

Для аутсорсера с десятком клиентов ключевая функция — экспорт и импорт конфигурации: шаблоны, события, правила обработки выгружаются в файл и переносятся на другую инсталляцию. Наш «золотой набор» шаблонов (Windows-сервер, сервер 1С, сетевое железо, ИБП, принтеры) хранится в git и накатывается новому клиенту за минуты. Это тот же подход «инфраструктура как код», только для мониторинга — и одна из причин, почему внедрение у нас занимает часы, а не недели.

Автоматическое реагирование: система чинит сама

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

• Зависшая служба печати. Порог «очередь печати не двигается» → действие: рестарт спулера на терминальном сервере. У одного нашего клиента-бухфирмы это срабатывает несколько раз в месяц, и пользователи перестали замечать проблему вообще.
• Переполнение временных файлов. Порог «на системном диске меньше 5%» → скрипт чистки временных каталогов и старых логов. Затем — обычный алерт, если после чистки места всё ещё мало: значит, проблема настоящая.
• Профилактический сбор диагностики. При событии «rphost перезапустился» агент собирает хвост технологического журнала 1С в архив — когда инженер сядет разбираться, улики уже зафиксированы.

И граница, которую мы не переходим: никакой автоматики с перезагрузкой продуктивных серверов. Перезапуск службы печати обратим и безопасен; перезагрузка сервера 1С посреди рабочего дня из-за ложного срабатывания порога — это авария, которую мониторинг устроил сам. Всё, что затрагивает данные или сессии пользователей, делает человек после взгляда на график.

Итог: матрица интеграций и трудозатрат

Сводим всё описанное в одну таблицу — она же наш внутренний чек-лист доработок после базового внедрения:

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

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