LibreNMS: бесплатный мониторинг сети и оборудования по SNMP
Когда в офисе до 50 рабочих мест ломается свитч или забивается канал в интернет, первым об этом узнаёт не админ, а бухгалтер, у которого «зависла 1С». Мы в АйТи Фреш закрываем эту слепую зону LibreNMS — бесплатной системой мониторинга по SNMP, которая сама находит оборудование в сети, рисует графики трафика и присылает алерт раньше, чем позвонит клиент. Ниже — наша методология внедрения: от чистой ОС до порогов на перегрузку канала, с конкретными версиями, параметрами и конфигами.
Зачем офису до 50 РМ вообще нужен мониторинг сети
У типичного клиента нашего профиля — юрлицо на 15-50 рабочих мест — сетевая инфраструктура состоит из 1-3 управляемых свитчей, роутера или межсетевого экрана на границе, точки доступа Wi-Fi, сетевого принтера или МФУ и NAS для бэкапов и общих папок. Отдельного сетевого инженера в штате нет, а вопрос «почему опять тормозит интернет» звучит в среднем раз в неделю. Без мониторинга ответ на него — это удалённое подключение, ручной пинг десятка адресов и просмотр счётчиков на веб-морде свитча вручную. С мониторингом это занимает 30 секунд: открыл граф загрузки порта — увидел пик в 95% на аплинке в 14:20, дальше выясняем, кто качал.
Мы остановились на LibreNMS, а не на Zabbix или PRTG, по трём причинам. Во-первых, лицензия AGPLv3 — бесплатно и без ограничения по числу устройств, в отличие от PRTG, где бесплатный тариф упирается в 100 сенсоров (а один свитч на 24 порта съедает их за секунды). Во-вторых, LibreNMS — это сетевой NMS «из коробки»: автообнаружение по SNMP, CDP, LLDP, ARP и OSPF/BGP, готовые модули для конкретных вендоров (Cisco, MikroTik, HP/Aruba, Synology, QNAP, Zyxel и десятки других) уже встроены и не требуют написания шаблонов, как в Zabbix. В-третьих, порог входа ниже: разворачивается на одном небольшом сервере или даже виртуалке на 2 vCPU/4 ГБ для офиса на 20-30 устройств, и не требует отдельного специалиста для поддержки — это то, что можно один раз настроить и обслуживать по регламенту раз в квартал.
Проект LibreNMS — форк Observium (ветка 2013 года, лицензия GPL), сейчас живёт самостоятельно на GitHub, ядро на Laravel, официальная документация — docs.librenms.org. Именно по ней мы сверяем версии пакетов и имена параметров, потому что готовые гайды в интернете часто отстают на пару релизов.
Есть и практический управленческий аргумент, который мы проговариваем с директором клиента отдельно от технической части: мониторинг превращает разговор с провайдером интернета или с подрядчиком по СКС из «у нас всё тормозит, разберитесь» в предметный — «на аплинке в такое-то время устойчивая загрузка 97% на протяжении 40 минут, вот график». С графиком и таймстампом любая претензия по SLA решается быстрее, а без него это слово против слова. То же самое работает и внутрь компании: когда сотрудник жалуется на медленный интернет, за 30 секунд видно, локальная это проблема (загружен конкретный порт свитча в его кабинете) или общая (упёрлись в полосу канала), и куда именно идти чинить — не нужно гадать и переключаться между вкладками разных производителей оборудования.
Стек компонентов: из чего собираем сервер мониторинга
Разворачиваем LibreNMS на отдельной виртуальной машине или LXC-контейнере — совмещать с продуктивными сервисами клиента не стоит, чтобы падение мониторинга не тянуло за собой ничего критичного, и наоборот. Для офиса до 50 устройств хватает 2 vCPU, 4 ГБ RAM и 40 ГБ диска (основной расход места — исторические данные RRD и логи). Ниже — набор компонентов, который мы ставим, со сверкой по актуальной документации.
| Компонент | Что используем | Роль в системе |
|---|---|---|
| ОС | Ubuntu 24.04 LTS или Debian 12 | Базовая система, оба варианта официально поддержаны докой LibreNMS |
| Веб-стек | PHP 8.3 (cli, fpm, snmp, mysql, gd, gmp, mbstring, xml, zip) + Composer | Исполнение веб-интерфейса, poller и CLI-скриптов дискавери |
| СУБД | MariaDB 10.11 | Хранение конфигурации устройств, событий, алертов, инвентаря портов |
| Графики | RRDtool (+ опционально rrdcached) | Хранение и отрисовка временных рядов трафика, CPU, памяти |
| Веб-сервер | Nginx + php-fpm | Отдаёт UI и REST API (/api/v0) |
| Опрос (poller) | cron-задача librenms-scheduler (systemd timer) или Dispatcher Service (librenms.service) | Запуск опроса устройств по расписанию, при росте парка — переход на распределённый опрос через Redis |
| Очереди/кластер | Redis 7.x | Координация poller-узлов при распределённом опросе (обязателен, если poller больше одного) |
| SNMP-агент | net-snmp (snmpd на опрашиваемых устройствах) | Источник данных: интерфейсы, температура, диски, тонер и т.д. |
Для одиночного сервера без распределённого опроса Redis не строго обязателен, но мы ставим его сразу — переход на Dispatcher Service при расширении парка устройств тогда делается без пересборки инфраструктуры.
Установка: от чистой ОС до первого логина
Наш стандартный сценарий разворачивания — по официальному разделу Installation докиментации, адаптированный под типовой офисный стенд:
- Готовим ОС: обновляем пакеты, ставим временную зону сервера в соответствие с офисом клиента (влияет на метки времени на графиках).
- Ставим стек: MariaDB, PHP 8.3 с нужными расширениями, Composer, RRDtool, Nginx, SNMP-утилиты, ImageMagick (для экспорта графиков в PDF-отчёты) и Python 3 с модулями для systemd-снапшотов дискавери.
- Создаём системного пользователя librenms, клонируем репозиторий в
/opt/librenms, ставим праваchown librenms:librenms /opt/librenmsи запускаем./scripts/composer_wrapper.php install --no-devдля зависимостей PHP. - Создаём базу и пользователя MariaDB, прописываем реквизиты в
config.php` через мастер веб-установки (`/install.php`), либо через `lnms config:set`. - Настраиваем cron: копируем
/opt/librenms/librenms.nonroot.cronв/etc/cron.d/librenms— это базовый механизм опроса и дискавери на старте, пока не перешли на Dispatcher Service. - Настраиваем логротацию (
librenms.logrotateв/etc/logrotate.d/) и systemd-таймер librenms-scheduler, который триггерит опрос по расписанию, определяемому интервалом опроса устройства (по умолчанию 5 минут).
После установки первым делом идём в Validate (проверка через ./validate.php из директории установки) — скрипт сверяет права на файлы, версии PHP-расширений и доступность директорий rrd/, logs/, bootstrap/cache/. Мы включаем этот шаг в чек-лист обязательно: типовая ошибка — забытые права на rrd/ после ручного копирования файлов, из-за которой poller падает молча.
Отдельно уделяем внимание веб-серверу и сертификату: панель управления клиенту и его сотрудникам открываем только по HTTPS (Let's Encrypt на поддомене вида nms-<client>.itfresh.ru), а доступ к порту 443 ограничиваем списком IP или VPN, потому что панель LibreNMS отдаёт довольно много служебной информации об инфраструктуре — от версий прошивок до топологии сети — и не должна быть доступна из открытого интернета всем подряд. После первого логина заводим отдельную учётную запись для клиента с ограниченной ролью (только просмотр графиков и списка алертов), а полные административные права оставляем за собой — это стандартный подход, который мы используем во всех проектах с удалённым мониторингом инфраструктуры клиента.
SNMP на стороне оборудования: версии, community, шаблоны
LibreNMS ничего не увидит, пока на самом оборудовании не включён SNMP-агент. На Linux-хостах (сервер бэкапов, NAS на базе Linux, гипервизор) ставим net-snmp и правим конфиг из эталонного шаблона проекта:
cp /opt/librenms/snmpd.conf.example /etc/snmp/snmpd.conf
В файле меняем плейсхолдер community-строки на уникальную для клиента (не оставляем дефолтную «public» — это открытая дверь для чтения инвентаря сети снаружи, если SNMP-порт случайно доступен не только с сервера мониторинга):
rocommunity ITFR_<client_id>_ro 10.10.5.0/24
syslocation Офис, серверная, стойка 1
syscontact noc@itfresh.ru
На управляемых свитчах, роутерах и МФУ SNMP включается в веб-консоли или CLI устройства — там же прописываем community и, где поддерживается, ACL на конкретный IP сервера мониторинга. Для сетевого оборудования корпоративного класса и там, где это оправдано (клиент просит шифрование опроса), настраиваем SNMPv3 с authPriv (SHA + AES) вместо community-строки v2c — LibreNMS поддерживает оба варианта на уровне карточки устройства.
| Версия SNMP | Аутентификация | Когда используем |
|---|---|---|
| v1 | community, без шифрования | Только для legacy-устройств, которые не умеют v2c (редко) |
| v2c | community, без шифрования, но с 64-битными счётчиками | Базовый вариант для офисного парка внутри защищённого VLAN |
| v3 | authPriv: SHA/MD5 + AES/DES шифрование payload | Устройства на периметре, ситуации, где SNMP-трафик может пересекать недоверенный сегмент |
После включения агента добавляем устройство в LibreNMS: ./addhost.php 10.10.5.1 ITFR_<client_id>_ro v2c — CLI-скрипт сразу пытается определить OS-модуль (LibreNMS хранит YAML-определения для конкретных вендоров в includes/definitions/, там же прописаны OID для температуры, PSU, вентиляторов и специфичных счётчиков конкретной модели).
Отдельно стоит сказать про сегментацию: SNMP-трафик мы всегда пускаем внутри отдельного management-VLAN, а не вперемешку с пользовательским трафиком — так community-строка не гуляет по общей сети, и её не увидит любой сотрудник со сниффером в общем сегменте. На пограничном маршрутизаторе или межсетевом экране правило на SNMP-порт (UDP/161 для опроса, UDP/162 если настраиваем приём trap-уведомлений от самого оборудования) открываем строго с адреса сервера мониторинга, а не с целой подсети. Это занимает лишние 10 минут при внедрении, но снимает целый класс рисков «кто угодно из офисной сети может вычитать всю топологию и версии прошивок».
Автообнаружение: как устройства попадают в систему сами
Ручное добавление оправдано для первых 3-5 ключевых узлов (ядро сети, роутер, файловый сервер). Дальше включаем автообнаружение — это ключевая причина, по которой мы выбрали именно LibreNMS для небольших офисов: не нужно вручную инвентаризировать каждый принтер и точку доступа.
Discovery-процесс в LibreNMS запускается по расписанию — по умолчанию полный проход раз в 6 часов, а недавно обнаруженные соседи (по CDP/LLDP/ARP/маршрутным таблицам уже опрошенных устройств) подхватываются в течение ближайших 5 минут после появления записи. Для первичного наполнения сети мы используем SNMP-scan — сканер по диапазону CIDR, который пробует SNMP-community на всех адресах подсети и сам создаёт карточки устройств для тех, кто ответил:
cd /opt/librenms
./snmp-scan.py 10.10.5.0/24
Диапазоны для регулярного пересканирования (не только разового) прописываются в конфиге через параметр autodiscovery.nets (список CIDR), а сегменты, которые заведомо не нужно трогать — гостевой Wi-Fi, IoT-VLAN без SNMP — исключаем через autodiscovery.nets-exclude, чтобы не плодить бесполезные попытки опроса и не шуметь в логах.
Важный нюанс, который мы всегда проговариваем с клиентом на старте: чтобы автообнаружение вообще заработало, в системе уже должно быть хотя бы одно устройство, добавленное вручную — от него строится граф соседей через CDP/LLDP. Поэтому первый шаг всегда — ручное добавление ядра сети, а дальше система дорастает сама.
После того как первичное сканирование отработало, мы не оставляем автообнаружение полностью бесконтрольным — раз в квартал просматриваем список устройств на предмет «фантомов»: временных гостевых ноутбуков, случайно ответивших на community-строку, или оборудования, которое давно физически демонтировано, но осталось в базе как offline. Такие карточки чистим вручную, чтобы список устройств отражал реальную топологию, а не историю всего, что когда-либо появлялось в сети клиента. Отдельно фиксируем в регламенте: если у клиента есть сегменты, куда мониторинг не должен дотягиваться из соображений безопасности (например, изолированная касса или сегмент с 1С-сервером под 152-ФЗ), эти диапазоны сразу заносим в исключения на уровне сетевых ACL, а не только в конфиг LibreNMS — так исключение не зависит от настроек одного приложения.
Пороги и алерты: как мы ловим перегрузку канала до жалобы клиента
Голые графики никто не смотрит каждый день — нужны правила, которые сами скажут, когда пора вмешаться. В LibreNMS это Alert Rules: условие на основе метрик (заполненность интерфейса, потеря пакетов, температура, свободное место на диске) плюс уровень серьёзности (Ok/Warning/Critical) плюс канал доставки (Transport) — у нас это Telegram-бот в рабочий чат клиента и e-mail дежурному инженеру.
Базовое правило, которое мы ставим на аплинк в интернет у каждого клиента — предупреждение при устойчивой загрузке порта выше комфортного для офиса уровня и критический алерт при загрузке, близкой к номинальной пропускной способности канала. Конкретные проценты — не значение из документации, а наша практика: warning от 80% полосы канала, critical от 95%, оба — с усреднением, чтобы не реагировать на секундные всплески. Правило строится через конструктор в разделе Alerting → Rules на встроенном макро-языке (Alert rule builder), логика в духе:
%devices.status = '1'
&& %ports.ifOperStatus = 'up'
&& %ports.ifInOctets_rate * 8 / %ports.ifSpeed * 100 > 80
Отдельным правилом с более высоким приоритетом и более жёстким порогом (>95%) заводим Critical — так дежурный сразу видит по цвету в Telegram-уведомлении, нужно ли бросать текущие дела. Оформление сообщения задаётся в Alert Templates — это Blade-шаблоны (тот же движок, что в Laravel), в которые можно подставить конкретный порт, устройство и текущее значение, чтобы не открывать веб-интерфейс ради выяснения, что именно перегружено.
Помимо канала мы обязательно ставим правила на: недоступность устройства по ICMP (устройство пропало из сети), рост числа CRC/ошибок на порту свитча (признак деградации кабеля или дуплекс-конфликта), заполнение диска на NAS выше практического порога (85% warning, 95% critical — тоже наша практика, не догма из доки), и на температуру там, где датчик поддерживается модулем устройства.
Ещё один момент, который часто упускают при первом внедрении — подавление лавины уведомлений. Если у клиента упал сам роутер, дальше по цепочке «недоступны» становятся все устройства за ним, и без настройки зависимостей (Alert dependency на статус родительского устройства) дежурный получит десяток сообщений вместо одного понятного «упал шлюз, остальное — следствие». Мы сразу выстраиваем эту иерархию через привязку правил к статусу вышестоящего узла, а также включаем задержку перед отправкой алерта (obey down dependency, delay в 2-3 минуты на основных правилах) — это отсекает кратковременные микро-обрывы связи, на которые реагировать бессмысленно, и оставляет только устойчивые, реальные инциденты.
Что реально мониторим в офисе до 50 РМ: чек-лист по классам оборудования
Не всё, что умеет опрашивать LibreNMS, нужно небольшому офису. Мы ограничиваем набор метрик тем, что реально прогнозирует инцидент или объясняет жалобу пользователя — иначе дашборд превращается в шум, который никто не читает.
| Класс устройства | Что мониторим | Зачем |
|---|---|---|
| Управляемый свитч | Загрузка портов, ошибки/CRC, статус STP, PoE-бюджет, температура | Ловим забитый аплинк и деградирующие патч-корды до того, как отвалится связь |
| Роутер / межсетевой экран | Загрузка WAN-интерфейса, латентность и потери на аплинке (ICMP), число активных сессий/NAT, uptime | Основной источник жалоб «медленный интернет» — здесь всегда смотрим первым |
| Точка доступа Wi-Fi | Статус, число ассоциированных клиентов, загрузка радио-интерфейса (где модуль поддерживает конкретную модель) | Перегрузка эфира в открытую офисную зону — частая причина жалоб именно на Wi-Fi, а не на канал |
| Сетевой принтер/МФУ | Доступность по SNMP, уровень тонера/чернил (через Printer MIB), статус бумаги/лотков | Проактивная заявка на расходники вместо звонка «принтер встал» в разгар отчётного периода |
| NAS/файловый сервер | Свободное место на томах, статус RAID/дисков (через вендорский модуль — Synology, QNAP, TrueNAS), температура дисков, загрузка CPU/RAM | Раннее предупреждение о заполнении диска с бэкапами и о деградации массива |
Для каждого класса в LibreNMS уже есть готовый OS/vendor-модуль с нужными OID — писать свои шаблоны для типового офисного оборудования почти никогда не приходится, разве что для узкоспециализированных приборов (например, ИБП без стандартного UPS-MIB).
С ИБП отдельная история: если модель поддерживает стандартный UPS-MIB по SNMP (через сетевую карту управления или через шлюз), заводим его тоже — статус батареи, режим работы от сети/от батареи и оставшееся время автономии critical важны именно для серверной комнаты, где на ИБП висит и сам сервер мониторинга. Здесь есть очевидный парадокс, который мы всегда объясняем клиенту: если ИБП с сервером LibreNMS обесточен одновременно с самим сервером, алерт о переходе на батарею просто не успеет уйти. Поэтому для действительно критичного оборудования (например, единственный сервер 1С в небольшом офисе) финальным звеном остаётся физическое уведомление с самого ИБП или отдельный маломощный резервный канал алертинга — не полагаемся только на LibreNMS там, где отказывает сама инфраструктура, на которой он крутится.
Эксплуатация: опрос, хранение истории, масштабирование
По умолчанию опрос устройств идёт через cron-задачу librenms-scheduler (systemd timer), которая запускает poller-wrapper.py с интервалом опроса устройства (обычно 5 минут) и отдельно дискавери раз в 6 часов. Для парка до полусотни устройств одного poller-процесса на cron достаточно с запасом. Когда клиент подключает вторую площадку или парк вырастает за пару сотен устройств, мы переходим на Dispatcher Service — единый systemd-сервис librenms.service, который умеет распределять задачи опроса между несколькими poller-узлами через Redis, не дожидаясь cron-тика. Официальная рекомендация в документации именно такая: начать со стабильной однонодовой установки, включить RRDCached, и только потом при необходимости переходить на Dispatcher Service — мы следуем этой последовательности буквально, не перескакивая сразу к распределённой схеме там, где она не нужна.
Исторические данные хранятся в RRD-файлах — это данные фиксированного размера (round-robin, старые точки автоматически прорежаются), поэтому диск под них не растёт бесконечно, но глубина детализации графика за прошлый год всегда грубее, чем за прошлую неделю — это особенность формата, а не баг. RRDCached мы включаем даже на одиночном сервере: он снижает число операций записи на диск, буферизуя обновления в памяти и сбрасывая пачками, что заметно на бюджетных VPS с медленным диском.
Регламент обслуживания, который мы ставим клиенту в договор: раз в квартал — проверка `./validate.php` на предмет расхождения версии кода и схемы БД, ревизия списка алертов (не появились ли устройства без покрытия), и бэкап базы MariaDB вместе с директорией rrd/ — без второго бэкап бесполезен, потому что вся история графиков живёт именно в файлах, а не в БД.
Итог: стоимость владения и где заканчиваются возможности LibreNMS
Итоговая стоимость владения для клиента — это фактически цена виртуальной машины (у нас это обычно тот же гипервизор, где уже крутится остальная инфраструктура клиента) плюс наши часы на внедрение и квартальное обслуживание. Лицензионных отчислений нет в принципе — AGPLv3 снимает вопрос «сколько устройств можно мониторить», в отличие от бесплатных тарифов коммерческих NMS. Для офиса до 50 РМ с типовым набором из пары свитчей, роутера, точки доступа, принтера и NAS весь стек разворачивается за один рабочий день, включая настройку алертов и первую неделю калибровки порогов (первые дни почти всегда правим пороги — трафик у конкретного клиента отличается от «книжных» 80/95%).
Честно про границы: LibreNMS — это NMS, заточенный на сеть и SNMP-опрашиваемые устройства, а не универсальная система мониторинга приложений. Если клиенту нужен глубокий APM, мониторинг логов приложений или синтетические проверки веб-сервисов, туда добавляется отдельный инструмент — но саму сетевую инфраструктуру, ради которой всё это городится в 9 случаях из 10 («тормозит интернет», «упал свитч», «не видно принтер»), LibreNMS закрывает полностью и бесплатно.
Частые вопросы
- Сколько устройств выдержит один сервер LibreNMS без распределённого опроса?
- Для офиса до 50-100 опрашиваемых узлов (с учётом того, что каждый порт свитча — это тоже отдельные метрики) достаточно одиночного сервера на 2 vCPU/4 ГБ RAM с включённым RRDCached. Переход на Dispatcher Service с несколькими poller-узлами через Redis мы делаем только когда парк вырастает за пару сотен устройств или добавляется вторая географическая площадка.
- Нужно ли что-то ставить на компьютеры сотрудников?
- Нет. LibreNMS опрашивает по SNMP только сетевое оборудование и серверы — свитчи, роутеры, точки доступа, принтеры, NAS. Рабочие станции сотрудников не входят в контур этого мониторинга; для них при необходимости используется отдельный инвентаризационный инструмент.
- Что если оборудование не поддерживает SNMP?
- Часть бытовых роутеров и неуправляемых свитчей SNMP не отдаёт в принципе — для них остаётся только ICMP-проверка доступности без детальных графиков трафика. На этапе аудита инфраструктуры мы сразу оцениваем, какая доля парка поддерживает SNMP, и предлагаем при необходимости замену ключевых узлов на управляемые модели.
- Безопасно ли включать SNMP на оборудовании клиента?
- При правильной настройке — да: используем непубличную community-строку (никогда не 'public'), ограничиваем доступ ACL на IP сервера мониторинга, а для устройств на периметре сети переходим на SNMPv3 с шифрованием authPriv (SHA+AES) вместо открытой community-строки v2c.
- Как быстро придёт алерт о перегрузке канала интернета?
- При интервале опроса 5 минут и усреднении для избежания ложных срабатываний на секундных всплесках — уведомление о превышении порога уходит в Telegram или на почту в течение 5-10 минут от начала устойчивой перегрузки, то есть обычно раньше, чем сотрудники успевают позвонить с жалобой.