LibreNMS для распределённой сети: SNMP, карта, алерты и Oxidized

Привет! Меня зовут Евгений Семенов. За 15 лет в IT мне пришлось поработать с добрым четырьмя десятками систем сетевого мониторинга (NMS), и это были проекты совершенно разного калибра. Представьте, от маленьких офисов с парой коммутаторов до гигантских логистических сетей, где в сотнях филиалов стояли Cisco, Aruba, MikroTik. Мониторинг серверов и приложений? Здесь я всегда выбираю Zabbix. Но если речь о сети, то для меня практически безальтернативен LibreNMS. И знаете, почему? Он совершенно бесплатен, без проблем «видит» любое оборудование благодаря SNMP MIB и, что самое приятное, его реально развернуть буквально за один рабочий день. Дальше я покажу вам, как мы подходим к внедрению на практике, поделюсь нашим внутренним регламентом и, конечно, расскажу о реальном проекте — с цифрами.

Что такое LibreNMS и почему он так прижился

Что такое LibreNMS? По сути, это такой прокачанный форк нашего старого-доброго Observium, но с колоссальным преимуществом: у него полностью открытая разработка и по-настоящему живое сообщество. Под капотом у него работает проверенный временем стек: PHP, MySQL, RRDtool и Python-поллеры. Главный козырь, на наш взгляд? Конечно, это гигантская база описаний оборудования прямо внутри системы. Только представьте: 1500+ моделей поддерживаются "из коробки" – от брутальных Cisco Catalyst и HP ProCurve до специализированных промышленных устройств Moxa! Но есть и ложка дёгтя, куда без неё: его веб-интерфейс становится довольно медлительным, если устройств в вашей сети собирается, прямо скажем, *очень* много.

Как же это всё устроено у нас на продакшене? LibreNMS мы запускаем на выделенной виртуалке Debian 12. Эта машина получила 6 виртуальных ядер и 12 ГБ оперативной памяти. Живёт она в дата-центре МТС и оттуда держит под контролем более 230 сетевых устройств наших клиентов. Сам физический сервер — это Dell Xeon Platinum 8280, а дисковая подсистема, разумеется, на быстрых NVMe-накопителях. И чтобы связь с остальными виртуалками была молниеносной, мы подключили к нему 40-гигабитный Mellanox.

Установка: официальный скрипт vs ручная сборка

Установить LibreNMS можно тремя способами: использовать готовый Docker-образ, поставить из Debian-пакета или заморочиться с ручной инсталляцией прямо из git-репозитория. Мы в ITFresh всегда выбираем последний вариант. И знаете, почему? Полный контроль над версиями PHP, nginx и MariaDB окупается сторицей. Особенно это заметно, когда приходит время очередного крупного апгрейда: никаких неприятных сюрпризов!

sudo apt update && sudo apt install -y acl curl fping git graphviz imagemagick \
  mariadb-client mariadb-server mtr-tiny nginx-full nmap php8.2-cli php8.2-curl \
  php8.2-fpm php8.2-gd php8.2-gmp php8.2-mbstring php8.2-mysql php8.2-snmp \
  php8.2-xml php8.2-zip python3-dotenv python3-pymysql python3-redis \
  python3-setuptools python3-systemd python3-pip rrdtool snmp snmpd whois \
  unzip python3-pip

sudo useradd librenms -d /opt/librenms -M -r -s "$(which bash)"
cd /opt
sudo git clone https://github.com/librenms/librenms.git
sudo chown -R librenms:librenms /opt/librenms
sudo chmod 771 /opt/librenms
sudo setfacl -d -m g::rwx /opt/librenms/rrd /opt/librenms/logs /opt/librenms/bootstrap/cache
sudo setfacl -R -m g::rwx /opt/librenms/rrd /opt/librenms/logs /opt/librenms/bootstrap/cache

MariaDB, nginx, PHP-FPM, cron, dispatcher-сервис — всё по официальной документации. Я не переписываю туториал, в нём 200 строк, они действительно рабочие. Если при ./validate.php всё горит зелёным — двигаемся дальше.

SNMP v3: нормальная аутентификация вместо пароля на заборе

Первое, что я делаю после установки — раскатываю SNMP v3 на всех коммутаторах. У нас в стандартной заготовке два контекста: ro (только чтение, полл LibreNMS) и rw (управление, Oxidized тоже ходит по v3). На Cisco IOS это выглядит так:

snmp-server group LIBRENMS-RO v3 priv
snmp-server user nms LIBRENMS-RO v3 auth sha1 AuthPass2025! priv aes 128 PrivPass2025!
snmp-server contact "it@company.ru"
snmp-server location "MSK-Office-5floor"

Для MikroTik:

/snmp community add name=nms authentication-protocol=SHA1 authentication-password=AuthPass2025! \
    encryption-protocol=AES encryption-password=PrivPass2025! security=private
/snmp set enabled=yes trap-version=3 contact="it@company.ru" location="Warehouse-Khimki"

Добавить новое устройство в LibreNMS — проще простого. Достаточно одной команды в CLI:

sudo -u librenms /opt/librenms/addhost.php 10.10.5.1 v3 nms AuthPass2025! SHA1 PrivPass2025! AES priv

Auto-discovery и карта топологии

Включите CDP на коммутаторах Cisco или LLDP на всём остальном оборудовании. После этого LibreNMS буквально за вас сам построит полноценную карту сетевых связей! А со стороны LibreNMS нужно лишь добавить пару строк в config.php:

$config['autodiscovery']['xdp']      = true;   // LLDP/CDP/FDP/OSPF
$config['autodiscovery']['ospf']     = true;
$config['autodiscovery']['bgp']      = false;
$config['autodiscovery']['snmpscan'] = false;  // на проде вредно, грузит сеть
$config['nets']                      = ['10.10.0.0/16', '10.20.0.0/16'];

Крон /opt/librenms/discovery-wrapper.py запускается каждые 6 часов и сам добавляет новые устройства. Через сутки после настройки в разделе Maps появится наглядная schema с линиями между коммутаторами — это не декорация, по ней удобно находить петли и несимметричные каналы.

Алерты в Telegram: минимум шума, максимум пользы

Вы же знаете этот кошмар? Стандартный «саундтрек» любого админа со стажем — это три сотни писем-уведомлений, навалившихся за выходные. Чтобы реально не утонуть в этом потоке и сохранить рассудок, мы сразу подключаем Telegram-транспорт. И, что не менее важно, настраиваем предельно жёсткий список правил. Вот что потребуется добавить в config.php:

$config['alert']['transports']['telegram'][0]['token']   = '1234567890:AA...';
$config['alert']['transports']['telegram'][0]['chat_id'] = '-1001234567890';
$config['alert']['transports']['telegram'][0]['parse_mode'] = 'markdown';

Затем, прямо в веб-интерфейсе LibreNMS (UI → Alerts → Rules), мы создаем наш минимальный, но очень эффективный набор правил:

Такая задержка в 5 минут, проверено, просто отсекает около 80% ложных срабатываний. Это те самые «алерты» от кратковременных, секундных пропаданий пинга. А вот оставшиеся 20% — это уже что-то серьезное, то, что действительно требует нашего внимания и действий.

Oxidized: git-история всех сетевых конфигов

Ох уж это сетевое оборудование! Его ведь часто обновляют, заменяют по частям, и самое обидное — очень редко это сопровождается хоть какой-то документацией. Oxidized решает эту головную боль, причём делает это кардинально: он просто каждую ночь автоматически забирает running-config со всех подключенных устройств и чистенько коммитит их в git-репозиторий. А LibreNMS, в свою очередь, через свой специальный плагин мгновенно подхватывает эти изменения и тут же, прямо в веб-интерфейсе, показывает нам наглядный «дифф» — что конкретно поменялось.

sudo apt install -y ruby ruby-dev libssl-dev pkg-config g++ cmake
sudo gem install oxidized oxidized-script oxidized-web

sudo useradd -s /bin/bash -m oxidized
sudo -u oxidized oxidized  # создаст /home/oxidized/.config/oxidized/

В config указываем источник — сам LibreNMS через его API (удобно: добавили устройство в NMS — оно автоматически попало в бэкап):

source:
  default: http
  http:
    url: https://nms.company.ru/api/v0/oxidized
    headers:
      X-Auth-Token: 'ВАШ_API_ТОКЕН_ИЗ_LIBRENMS'
output:
  default: git
  git:
    user: oxidized
    email: oxidized@company.ru
    repo: /var/lib/oxidized/devices.git
interval: 3600

Буквально после первого же прогона в нашем репозитории уже лежат все running-configs. Могу сказать точно: диффы за целый месяц расскажут о вашей сети куда больше, чем любая, даже самая подробная, страница в Confluence.

Реальный кейс: логистика, 8 складов, 140 устройств

Вспомним один интересный кейс. В апреле 2025 года к нам пришел крупный логистический оператор. Что у них было? Один головной офис в столице и целых восемь складов, раскиданных по всей Московской и Калужской областям. Всего, представьте, 140 сетевых устройств: 72 Cisco Catalyst, 38 MikroTik, 14 точек доступа Aruba, 8 АТС и, разумеется, Wi-Fi-контроллеры. Их прошлый мониторинг? Скажем прямо, его просто не было. Как они работали? В основном, просто пинговали все подряд из обычной гугл-таблицы.

Мы, конечно, не стали тянуть. Развернули LibreNMS на совершенно новенькой виртуалке прямо в их кластере Proxmox. А потом взяли Ansible, и буквально за каких-то два вечера накатили SNMP v3 на весь парк оборудования. Благо, IPsec-туннели до всех складов у них уже были настроены, так что тут мы времени не теряли. И что в итоге? Уже через неделю клиент увидел то, о чём раньше мог только мечтать: подробнейшую карту связности со всеми перекрёстными путями, шикарные графики загрузки апликов по всем складам, да ещё и уведомления о перегретых коммутаторах, которые, оказывается, стояли прямо в котельных!

И знаете, что самое интересное? Всего за первые полтора месяца работы LibreNMS обнаружил сразу ТРИ серьезнейшие проблемы, о которых на той стороне даже и не догадывались! Во-первых, выявился «капризный» SFP-модуль на складе в Подольске: он вызывал ежечасные обрывы, и сигнал там, казалось, буквально танцевал вместе с проезжающими грузовиками. Во-вторых, мы нашли классическую петлю на складе в Ногинске — как только мы ее устранили, время доставки заказа по системе WMS упало... представьте, с 48 секунд до фантастических 9! И, наконец, в Дмитрове стойка с оборудованием просто-напросто перегревалась: кондиционер там чинили целых четыре месяца, но, что самое печальное, этого никто толком и не замечал. А что по бюджету? За внедрение «под ключ» мы взяли 215 000 рублей. И дополнительно — 18 000 рублей в месяц за нашу постоянную техподдержку.

Distributed polling и масштабирование

Когда устройств становится больше 400–500, одной виртуалке становится тесно: цикл опроса не укладывается в 5 минут. Решение — distributed poller: отдельная машина пополняет ту же БД. Конфигурация в config.php:

$config['distributed_poller']                = true;
$config['distributed_poller_name']           = 'poller-spb';
$config['distributed_poller_group']          = 1;
$config['distributed_poller_memcached_host'] = 'nms.company.ru';
$config['distributed_poller_memcached_port'] = 11211;

По нашему опыту, один поллер стабильно тянет примерно 700 устройств с интервалом опроса в 5 минут. Если же у вас больше — не экономьте, смело добавляйте второй, а то и третий.

Что я обязательно делаю после запуска

• Ставлю validate.php в cron раз в сутки — при деградации система сама напишет в алерт-канал.
• Бэкаплю БД и конфиг — mysqldump librenms + tar на /opt/librenms/config.php в Borg-репозиторий на отдельном сервере.
• Включаю LDAP-авторизацию против AD клиента — админы заходят своими учётками, а не общим librenms/Password1.
• Как показать начальнику IT-отдела, что наша работа приносит конкретную ценность? Чтобы клиент видел реальную картину, мы кое-что делаем. Раз в месяц мы специально готовим для него подробный PDF-отчёт. В нём — актуальный «топ-10 устройств по загрузке». Этот инструмент помогает быстро оценить производительность инфраструктуры и принять обоснованные решения.

FAQ — LibreNMS в корпоративной сети

Когда LibreNMS выигрывает у Zabbix?

Когда главная задача — именно сеть. LibreNMS из коробки понимает более 1500 моделей коммутаторов, роутеров и UPS, рисует карту топологии по CDP/LLDP, умеет weathermap. Zabbix универсальнее для серверов и приложений.

Почему мы используем только SNMP v3?

SNMP v2c передаёт community-string по сети в открытом виде. v3 добавляет SHA-аутентификацию и AES-шифрование. Для распределённых сетей с туннелями через публичный интернет это минимальная гигиена.

Сколько железа нужно под LibreNMS для офиса 50–150 устройств?

4 vCPU, 8 ГБ RAM, 120 ГБ SSD хватает с запасом. RRD-базы занимают около 200 МБ на устройство, но за счёт round-robin не растут со временем.

Зачем нужен Oxidized, если на коммутаторах есть ручной бэкап?

Oxidized тянет конфиг раз в сутки и коммитит в git. Вы видите diff — что именно и когда изменилось. При ЧП открываете вчерашний коммит и возвращаете рабочую конфигурацию за минуту.

Как мониторить филиалы за NAT?

Самый надёжный путь — поднять IPsec/WireGuard туннели и опрашивать SNMP по внутренним адресам. Для крупной сети — distributed polling: ставим дополнительный poller в филиале.