LibreNMS в бою: обновления, бэкапы, безопасность и масштабирование — регламент эксплуатации, по которому мы живём

Мониторинг тоже надо обслуживать: почему «поставили и забыли» не работает

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

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

Необслуживаемый мониторинг умирает тремя типовыми способами, все три мы разбирали у клиентов, пришедших к нам «по наследству»:

• Диск. База и RRD-файлы растут, диск заполняется, опрос молча останавливается. Графики замирают, алерты не приходят — и никто не замечает, потому что «нет новостей — хорошие новости». Правду узнают при первой аварии, которую мониторинг «проспал».
• Забытые обновления. Инсталляция трёхлетней давности с известными CVE в веб-интерфейсе, до которой страшно дотрагиваться: обновление через три мажорные версии — это уже не апдейт, а миграция.
• Сертификат и мелочи. Истёк сертификат — веб-интерфейс начал пугать браузер — в него перестали заходить — журнал validate никто не читает — деградация накапливается. Смерть от тысячи мелких порезов.

Вывод простой: мониторинг — это не продукт, а процесс. Ниже — регламент, по которому этот процесс у нас устроен.

Обновления: ежемесячные релизы как преимущество и обязанность

Как устроены релизы LibreNMS

LibreNMS живёт в ритме ежемесячных релизов со схемой версионирования «год.месяц.патч»: на момент написания актуальна 26.8.2 — вторая заплатка августовского релиза 2026 года. Месячные релизы несут поддержку новых устройств (каждый месяц добавляются вендоры и модели), исправления опроса и безопасность; патч-версии внутри месяца — оперативные фиксы. Для эксплуатации это одновременно подарок и обязательство: свежая поддержка железа приезжает быстро, но и отставать надолго нельзя — чем больше пропущено релизов, тем рискованнее прыжок.

Наш регламент обновления

Мы ставим LibreNMS в Docker, поэтому обновление — это смена тега образа и перезапуск:

# снапшот ВМ или бэкап до любых действий
docker compose pull
docker compose up -d
# после подъёма — самодиагностика
docker compose exec librenms php validate.php

Три правила, выстраданные практикой:

• Снапшот ВМ до обновления. Откат за две минуты стоит дешевле любой диагностики. Снапшот удаляем через сутки после успешной проверки.
• Клиентские инсталляции обновляем раз в квартал, а не каждый месяц. Ежемесячно обновляется только наша собственная «канарейка» — внутренняя инсталляция, на которой релиз обкатывается две-три недели. Квартальный ритм даёт баланс: отставание максимум на два-три релиза, при этом на клиентов едет уже проверенная версия. Исключение — security-фиксы: они накатываются вне очереди.
• Проверка после обновления обязательна: validate.php без ошибок, графики продолжают рисоваться, тестовый алерт проходит.

daily.sh и validate.php — самодиагностика, которую надо читать

У LibreNMS есть два встроенных механизма самоконтроля. Скрипт daily.sh ежедневно чистит старые данные и обслуживает базу. А validate.php — диагност, который проверяет версии PHP и базы, права на каталоги, расписание опроса, отставание поллера — и прямо пишет, что не так и как чинить. Мы прогоняем его после каждого обновления и еженедельно по расписанию; вывод с ошибками уходит инженеру площадки. Большинство «внезапных» смертей мониторинга validate предсказывает за недели.

Если релиз сломал опрос конкретной железки

Бывает: после обновления какая-нибудь экзотическая железка перестаёт опрашиваться или датчики уезжают. Порядок действий: откат на предыдущий тег образа (данные не трогаем — схема базы совместима в соседних версиях), проверка, что опрос восстановился, и issue в GitHub-репозиторий проекта с выводом snmpwalk по проблемной железке. Сообщество реагирует быстро — дважды наши фиксы входили в следующий же месячный релиз.

Бэкапы: три сущности, которые надо сохранять

Классическая ошибка — бэкапить только базу данных. В LibreNMS три независимых слоя данных, и потеря любого из них болезненна по-своему.

MySQL: конфигурация и история событий

В базе живут устройства, правила алертов, транспорты, пользователи, журнал событий. Это «мозг» инсталляции. Бэкапится штатно:

mysqldump --single-transaction librenms | gzip > /backup/librenms-db-$(date +%F).sql.gz

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

RRD-файлы: сами графики

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

Конфиги окружения

Третий слой — файлы, которые не в базе: .env с ключом приложения и реквизитами БД, config.php, docker-compose.yml, кастомные шаблоны алертов и транспорты, крон-задания. Их немного, меняются редко — храним в git вместе с остальной документацией площадки.

Правило 3-2-1 и тест восстановления

Схема стандартная: три копии данных, на двух разных носителях, одна вне площадки. Для серверов мониторинга мы её не смягчаем — именно мониторинг нужен живым в момент большой аварии, когда остальная инфраструктура лежит. И главное, что отличает бэкап от надежды на бэкап: тест восстановления. Раз в квартал разворачиваем копию на тестовой ВМ: база из дампа, rrd из синхронизации, конфиги из git — и проверяем, что веб-интерфейс открывается, устройства на месте и графики с историей. Наш замер: полное восстановление типовой площадки занимает около 40 минут, из них большая часть — заливка RRD. Эти 40 минут, измеренные заранее, честнее любого «должно взлететь».

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

SNMP-гигиена

SNMP v2c передаёт community открытым текстом, поэтому минимальный стандарт такой: community только read-only, на каждой железке — ACL, разрешающий SNMP-запросы исключительно с адреса сервера мониторинга, и никаких «public». Там, где железо умеет SNMPv3 — а его умеет большинство управляемых коммутаторов последних десяти лет, — переходим на v3 с аутентификацией и шифрованием: LibreNMS поддерживает его полноценно. Отдельный пункт регламента — ротация community при увольнении админов, знавших их: см. чек-лист ниже.

Веб-интерфейс

HTTPS с нормальным сертификатом (Let's Encrypt решает вопрос бесплатно), обязательная двухфакторка для админских учёток — TOTP поддержан из коробки. Роли: инженерам — admin, клиенту — read-only пользователь с дашбордом его площадки. Клиент видит «светофор» и графики, но не видит community и не может ничего сломать.

Сегментация сети

Сервер мониторинга живёт в management-VLAN вместе с интерфейсами управления железок. Снаружи он недоступен вообще: доступ инженеров — только через VPN. Проброс порта веб-интерфейса наружу «чтобы удобно смотреть с телефона» — запрещён без обсуждений; для телефона есть VPN-профиль.

API-токены

Каждой интеграции — свой токен от отдельного пользователя с минимальными правами: скрипту инвентаризации не нужен admin. Токены попадают в реестр и ротируются вместе с остальными кредами площадки. Осиротевшие токены (скрипт умер, токен жив) вычищаются на квартальной ревизии.

Мысленный эксперимент: что даёт злоумышленнику ваш мониторинг

Полезное упражнение для приоритизации: представьте, что сервер мониторинга скомпрометирован. Атакующий получает карту сети со всеми адресами и ролями, SNMP-доступ ко всем железкам (а если где-то остался RW-community — то и запись конфигурации), версии прошивок для подбора эксплойтов и удобную точку разведки, с которой весь трафик выглядит легитимным опросом. После этого упражнения тезис «мониторинг надо защищать как контроллер домена» перестаёт звучать паранойей.

Производительность и масштабирование

Симптомы деградации

Главный индикатор здоровья — укладывается ли цикл опроса в свои пять минут. Когда poller перестаёт успевать, появляются характерные симптомы: дыры и «гребёнка» в графиках, растущее время опроса на странице производительности поллера, предупреждения в validate.php. Это не «косметика», а прямой сигнал: часть метрик уже теряется.

Что тюнить по порядку

1. Диск под RRD. Десятки тысяч мелких файлов, перезаписываемых каждые пять минут, — худшая нагрузка для HDD. Перенос rrd-каталога на SSD — самое дешёвое и самое результативное ускорение; на большинстве площадок этого хватает навсегда.
2. Воркеры диспетчера. Число параллельных потоков опроса подбирается под количество устройств: если поллер упирается не в диск, а в «ждём ответов по SNMP», добавляем воркеров.
3. Лишние модули опроса. LibreNMS по умолчанию опрашивает много: для конкретных устройств ненужные модули (например, опрос таблиц маршрутизации на офисном свитче) отключаются per-device — цикл заметно худеет.

Распределённый polling для филиалов

Когда у клиента филиал за медленным или нестабильным каналом, опрашивать его железки из центра — значит ловить таймауты и ложные «недоступен». Для этого у LibreNMS есть распределённый опрос: на площадке филиала ставится выносной poller, который опрашивает локальные устройства и отдаёт результаты центральному серверу. Алерты и графики остаются в одном месте, а опрос идёт по локальной сети. Мы применяем эту схему для загородных складов и производственных площадок — там, где канал «как повезёт».

Реальные цифры

Чтобы был ориентир: типовая ВМ на 2 vCPU и 4 ГБ памяти с SSD спокойно тянет офисную площадку на 50–70 устройств с парой тысяч портов и датчиков — poller укладывается в цикл с большим запасом. Ресурсы добавляем, когда время опроса стабильно переваливает за половину цикла или устройств становится больше пары сотен; до трёхсот устройств обычно хватает 4 vCPU / 8 ГБ и SSD. Дальше начинается территория распределённых поллеров — но это уже масштаб, на котором у клиента есть собственная IT-служба.

Рутина сопровождения: наш чек-лист

Всё перечисленное складывается в короткий регламент. Он занимает немного времени, но только если выполняется регулярно — запущенная инсталляция съедает часы на разгребание.

Итого в среднем 2–3 часа инженерного времени в месяц на площадку. Дальше покажу, почему эти часы — самая выгодная строчка в бюджете сопровождения.

Разбор инцидентов с самим мониторингом из нашей практики

Три реальных кейса, каждый из которых закончился новым пунктом в регламенте.

Кейс 1: RRD забили диск, опрос молча встал

Симптом: дежурные заметили, что с площадки сутки нет ни одного алерта — подозрительно тихо. Диагноз: диск ВМ заполнен на 100% RRD-файлами (автообнаружение находило новые устройства, каталог рос), поллер и база остановились. Мониторинг умер молча — сам о себе он уже сообщить не мог. Фикс: расширили диск, вычистили RRD давно удалённых устройств. Вывод в регламент: внешний healthcheck — маленький скрипт на другой машине, который дёргает API каждые 15 минут и шлёт алерт, если мониторинг не отвечает или последний опрос старше 10 минут. Мониторинг мониторинга звучит смешно ровно до первого такого случая.

Кейс 2: контейнер базы не поднялся после обновления

Симптом: после планового обновления стека контейнер MariaDB падает в рестарт-цикл. Диагноз: в docker-compose стоял тег latest, и вместе с LibreNMS приехала новая мажорная версия MariaDB, несовместимая с форматом данных в volume без процедуры апгрейда. Фикс: откат на предыдущую версию образа базы, штатный апгрейд по инструкции, после — успешный переход. Вывод в регламент: в compose-файлах все образы прибиты к конкретным версиям; база обновляется отдельным осознанным шагом, не паровозом.

Кейс 3: ночной шторм алертов от флапающего канала

Симптом: дежурный получает за ночь полсотни сообщений «филиал недоступен» / «восстановился». Диагноз: WAN-канал филиала деградировал и флапал каждые несколько минут; каждое падение честно порождало пару алертов. Формально система права, фактически — DoS на дежурного. Фикс: на группу устройств филиала подняли delay, добавили правило-агрегат «канал филиала нестабилен: N падений за час» — одно сообщение вместо пятидесяти; днём канал заменили. Вывод в регламент: для каждой площадки за нестабильным каналом — отдельная группа с собственными порогами; правила-агрегаты для повторяющихся событий.

Сколько это стоит в часах: честная экономика эксплуатации

LibreNMS бесплатна как софт, но не как процесс — и честнее сказать это прямо, чем прятать за словом «open source». Посчитаем. Сопровождение типовой площадки по нашему регламенту — 2–3 часа инженера в месяц: еженедельные проверки, ежемесячные ревизии, квартальные обновления и тесты восстановления, размазанные по году. Даже по ставкам хорошего московского инженера это несколько тысяч рублей в месяц.

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

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

Когда выгоднее отдать это на аутсорс, а не тащить своим админом? Арифметика простая: если у вас нет выделенной IT-службы, которая и так дежурит по сменам, — свой сотрудник ради 2–3 часов в месяц регламента не окупается, а «между делом» регламенты не живут (см. три способа смерти мониторинга в начале статьи). Мы забираем площадки на сопровождение вместе с дежурной сменой, регламентом и ответственностью за то, что о падении сети вы узнаёте от нас. Контакты — ниже.