Разворачиваем LibreNMS в Docker за вечер: пошаговое внедрение мониторинга офисной сети, как мы делаем это клиентам

Что понадобится: требования и выбор площадки

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

Ресурсов система просит скромно. Для офиса до 100 устройств нам стабильно хватает виртуалки 2 vCPU / 4 GB RAM / 40 GB SSD. Важен именно SSD: RRD-файлы графиков генерируют много мелких записей, на HDD поллер начинает не укладываться в цикл опроса. Если планируете больше пары сотен устройств — добавьте до 4 vCPU / 8 GB.

Куда ставить — два варианта из нашей практики:

• Гипервизор на площадке клиента — если он есть. Мониторинг живёт внутри сети, видит всё напрямую;
• Наша площадка в дата-центре МТС + VPN до офиса — если своего гипервизора нет. Бонус: когда в офисе гаснет свет, мониторинг снаружи успевает прокричать об этом в Telegram.

Ставим только в Docker. Классическая ручная установка LibreNMS — это полтора десятка шагов: nginx, PHP-FPM с набором расширений, MariaDB, snmpd, cron-задания, права на каталоги — и каждый шаг умеет ломаться по-своему. Docker-стек официальный, обновляется одной командой и переносится на другой хост копированием каталога. Для типового внедрения выбор очевиден.

Установка через Docker Compose на Ubuntu 24.04

Готовим хост

Свежая Ubuntu Server 24.04 LTS, дальше — стандартный набор:

# Docker Engine + compose-plugin из официального репозитория
curl -fsSL https://get.docker.com | sh

# Часовой пояс — критично для графиков и алертов
timedatectl set-timezone Europe/Moscow

# Проверяем
docker --version && docker compose version

Разбираем официальный compose-стек

Берём за основу примеры из официального репозитория librenms/docker. Стек состоит из нескольких контейнеров, и полезно понимать, что делает каждый:

Файл .env: минимум, который надо заполнить

TZ=Europe/Moscow
PUID=1000
PGID=1000

MYSQL_DATABASE=librenms
MYSQL_USER=librenms
MYSQL_PASSWORD=«длинный_случайный_пароль»

REDIS_HOST=redis

Пароль БД генерируем через openssl rand -base64 24 и сразу кладём в парольный сейф — привычка, которая спасает через год, когда никто уже не помнит, что где стояло. Запускаем:

docker compose up -d
docker compose ps   # все контейнеры должны стать healthy

Первый вход

Открываем http://ip-сервера:8000, создаём администратора, наводим первичную красоту: в My Settings → Language включается русский интерфейс (перевод частичный, но меню и дашборды — по-русски). Сразу же включаем двухфакторку админам — мониторинг знает о вашей сети всё, доступ к нему надо беречь. Наружу веб-интерфейс мы не публикуем никогда: доступ — только из локальной сети или через VPN; если веб всё же нужен снаружи, впереди ставится обратный прокси с TLS и ограничением по адресам.

Обновления и бэкап стека

Ещё два вопроса, которые надо закрыть в день установки, а не «потом». Обновление Docker-стека — две команды: docker compose pull && docker compose up -d; проект выпускает релизы ежемесячно, мы обновляем клиентские инсталляции раз в один-два месяца, предварительно глянув changelog. Бэкап — это два тома: база MariaDB (дамп через mariadb-dump по крону) и каталог RRD-файлов с графиками (обычный архив). Складываем на соседнюю площадку по правилу 3-2-1 и — обязательный пункт — хотя бы раз проверяем восстановление на чистой ВМ. Мониторинг, который нечем восстановить, — это ложное чувство безопасности.

Готовим железо: включаем SNMP на типовом офисном парке

LibreNMS без SNMP — как стетоскоп без пациента. Проходим по типовому парку наших клиентов. Везде используем SNMP v2c с community, ограниченным по адресу источника: версия v3 с шифрованием правильнее, но на разношёрстном офисном железе её поддержка лотерейна, а v2c с ACL — разумный компромисс для внутренней сети.

MikroTik RouterOS

/snmp community add name=itf-mon-XXXX addresses=192.168.10.5/32 read-access=yes
/snmp set enabled=yes trap-community=itf-mon-XXXX

Здесь 192.168.10.5 — адрес сервера LibreNMS: никто другой опросить роутер не сможет. Важный нюанс: используйте именно v2c — по v1 MikroTik отдаёт не все OID, часть счётчиков 64-битного трафика просто не видна.

Cisco IOS и коммутаторы доступа

access-list 90 permit host 192.168.10.5
snmp-server community itf-mon-XXXX RO 90
snmp-server location Office-Floor2-Rack1

Поле location заполняем всегда — LibreNMS подхватит его и разложит устройства по локациям на карте автоматически.

Keenetic, HP/Aruba, ИБП APC, принтеры

• Keenetic — SNMP здесь не включён по умолчанию: это отдельный компонент, который сначала ставится в разделе «Изменить набор компонентов», после чего агент настраивается и появляется в веб-интерфейсе;
• HP/Aruba ProCurve — snmp-server community "itf-mon-XXXX" operator из конфиг-режима;
• ИБП APC с сетевой картой — SNMP включается в веб-интерфейсе карты управления; на старых прошивках доступен только v1 — для ИБП этого хватает;
• принтеры (Kyocera, HP) — SNMP обычно включён с завода с community public: меняем его в веб-панели принтера и получаем мониторинг тонера бесплатно.

Автообнаружение: сеть находит себя сама

Руками добавляем только ядро сети — центральный коммутатор и роутер (Devices → Add Device, адрес + community). Дальше начинается магия: discovery по CDP, LLDP и ARP находит соседей найденного, соседей соседей — и так, пока сеть не кончится. Чтобы магия не ушла за пределы офиса, задаём рамки в конфигурации:

lnms config:set nets '["192.168.20.0/24","192.168.21.0/24"]'
lnms config:set autodiscovery.xdp true
lnms config:set autodiscovery.arp true

Параметр nets — белый список подсетей: устройства вне его не добавятся, даже если обнаружены. Это же спасает от захвата в мониторинг гостевого Wi-Fi и соседей по VPN. Исключения точечно задаются через autodiscovery-настройки бана по IP или sysName.

Реальный пример с внедрения этого лета: офис торговой компании, добавили руками два устройства — ядро и роутер. Через 40 минут в системе было 34 устройства: восемь коммутаторов, десяток точек Wi-Fi, два ИБП, принтеры и пара NAS. Вручную такой парк описывается день. Проверьте после discovery список найденного: пара сюрпризов вида «а это что за коробка в серверной?» гарантирована — считайте это бесплатной инвентаризацией.

Подключаем серверы Windows и Linux

Linux

Ставим стандартный snmpd, ограничиваем доступ адресом мониторинга — и сервер отдаёт CPU, память, диски, интерфейсы, аптайм. Для расширенных метрик (RAID, SMART, температуры) LibreNMS поддерживает механизм SNMP extend и агент check_mk — подключаем их выборочно, только там, где это оправдано.

Windows

Со встроенной службой SNMP в Windows история грустная: Microsoft объявила её устаревшей, и ставится она теперь как «компонент по требованию» (Features on Demand). Работать — работает, и для терминальных серверов клиентов мы чаще всего используем именно её: минимально инвазивно, ничего стороннего на боевой сервер не ставится. Два обязательных шага: задать community с ограничением по хосту в свойствах службы и открыть UDP/161 в файрволе Windows — по умолчанию он закрыт, и это грабли №1 каждого внедрения.

Где граница LibreNMS

По серверам система честно показывает «железное» здоровье: нагрузку, память, заполнение дисков, сетевую активность, аптайм. Внутренности приложений — счётчики 1С, очереди SQL, состояние служб с логикой перезапуска — это уже территория Zabbix, о котором у нас есть отдельный обзор. Мы нередко держим у клиента обе системы: LibreNMS смотрит за сетью, Zabbix — за серверами и 1С.

Первичная гигиена после установки

Свежепоставленный мониторинг похож на неразобранный склад: всё есть, найти ничего нельзя. Час гигиены превращает его в инструмент:

• Группы устройств — раскладываем парк по типам: сеть / серверы / ИБП / печать. По группам дальше строятся дашборды и правила алертов;
• Человеческие имена — «SW-Floor2-Rack1» вместо серийника в display name. Алерт «упал SW-Floor2» читается в три ночи сильно лучше, чем «упал HPE-2530-24G-a8f3»;
• Локации — офисам и филиалам задаём адреса: получаем карту, на которой видно, какая площадка болеет;
• Отключаем мусорные интерфейсы — loopback, незадействованные порты, служебные VLAN-сабинтерфейсы. Меньше шума в графиках и алертах, меньше нагрузка на поллер;
• Проверяем цикл поллера — в Poller → Performance время опроса всех устройств должно укладываться в 5-минутный цикл с запасом. Если не укладывается — первым делом смотрим на диск (SSD ли он) и на количество опрашиваемых портов.

Типичные грабли внедрения из нашей практики

Коллекция, собранная лбами наших инженеров. Формат: симптом → диагноз → фикс.

• Windows-сервер добавлен, но недоступен. Симптом: «No reply with community». Диагноз: файрвол Windows молча режет UDP/161. Фикс: разрешающее правило для адреса мониторинга.
• MikroTik показывает не все счётчики. Симптом: часть портов без графиков трафика. Диагноз: устройство добавлено по SNMP v1, 64-битные счётчики не отдаются. Фикс: переключить устройство на v2c.
• Алерты приходят пачками с опозданием. Симптом: уведомления задерживаются на десятки минут. Диагноз: dispatcher остался без Redis и потерял очередь. Фикс: проверить REDIS_HOST в .env и здоровье контейнера redis.
• Поллер не укладывается в 5 минут. Симптом: дырки в графиках, предупреждение в Poller Performance. Диагноз: RRD-файлы на медленном диске. Фикс: переезд томов на SSD; на больших инсталляциях — rrdcached.
• Принтер Kyocera «моргает» в мониторинге. Симптом: то доступен, то нет, алерты каждые полчаса. Диагноз: энергосбережение — в глубоком сне сетевая карта отвечает на SNMP через раз. Фикс: либо ослабить агрессивность сна в настройках принтера, либо поднять для него порог алерта до 15–20 минут недоступности.

Что получает клиент через сутки работы системы

Через сутки после вечера внедрения у клиента есть: графики по каждому порту каждого коммутатора, инвентаризация всего парка с моделями, серийниками и версиями прошивок, автоматическая топология сети, история syslog с железа и база для настройки алертов. Дальше — неделя наблюдения и тюнинг правил уведомлений, об алертах будет отдельная статья серии.

По ресурсам типовая инсталляция ведёт себя скромно: на офисе в 30–40 устройств стек занимает около 2 ГБ памяти, CPU дышит всплесками раз в пять минут во время опроса, диск прирастает на десятки мегабайт в неделю — RRD-файлы фиксированного размера не разбухают со временем, в отличие от классических баз метрик. Это одна из причин, почему LibreNMS годами живёт на самой дешёвой виртуалке без всякого внимания к себе.

Чек-лист приёмки, которым пользуются наши инженеры, — 12 пунктов:

1. Все контейнеры стека в статусе healthy;
2. Часовой пояс Europe/Moscow на хосте и в .env совпадают;
3. Пароль БД и админа — в парольном сейфе;
4. 2FA включена для всех администраторов;
5. SNMP включён на 100% управляемого парка, community не «public», доступ ограничен адресом мониторинга;
6. Автообнаружение ограничено подсетями клиента через nets;
7. Все устройства опознаны (нет Generic Device там, где его быть не должно);
8. Группы и display name назначены;
9. Мусорные интерфейсы исключены из опроса;
10. Поллер укладывается в цикл с запасом минимум 40%;
11. Тестовый алерт дошёл до Telegram и email;
12. Бэкап томов db и rrd настроен и проверен восстановлением.

Если по такому списку у вас всё зелёное — мониторинг внедрён, а не «поставлен». Нужна помощь — контакты ниже, развернём и возьмём наблюдение на себя.