LibreNMS в Docker Compose: готовый файл

MAATRIX

Если у вас в сети больше пяти управляемых свитчей, пары роутеров и десятка серверов, ручной учёт «что где стоит и как дышит» перестаёт работать уже через месяц. Zabbix для этой задачи избыточен — он умеет всё, но настройка карты сети и SNMP-шаблонов под каждое устройство съедает вечера. LibreNMS решает именно эту узкую задачу: находит устройства в сети сам, автоматически подбирает под них шаблоны опроса и рисует топологию без танцев с бубном. Ниже — рабочий docker-compose.yml, с которым система поднимается на чистом сервере за один заход.

Чем LibreNMS отличается от Zabbix и Observium

LibreNMS — форк Observium 2013 года, сделанный после того, как Observium ограничил бесплатную версию урезанным списком поддерживаемых устройств. С тех пор проекты разошлись: Observium остался закрытым коммерческим продуктом с открытым community-изданием, а LibreNMS живёт полностью в открытую — разработка на GitHub, вклад от сообщества, регулярные релизы.

Ключевая идея LibreNMS — автообнаружение. Вы указываете диапазон подсетей и SNMP-community, система сама обходит сеть, определяет тип устройства (Cisco, MikroTik, Linux-хост, принтер, ИБП — база сигнатур большая) и подключает подходящие модули опроса: интерфейсы, температуру, загрузку CPU, состояние дисков, BGP-сессии. Ручных шаблонов, как в Zabbix, почти нет — есть OS-детекторы, которые уже написаны под сотни вендоров.

Практическая разница с соседними инструментами:

• Zabbix — универсальный агент-based и SNMP-мониторинг с гибким триггерным движком, но требует явного описания хостов и шаблонов. Если вам важна гибкость алертинга и вы готовы настраивать — сравнение в статье Zabbix или Prometheus: что выбрать для сервера.
• Observium CE — бесплатная версия с ограниченным списком устройств и без части фич из платной. LibreNMS убирает это ограничение ценой чуть менее полированного интерфейса.
• PRTG/SolarWinds — коммерческие, лицензия по числу сенсоров. LibreNMS бесплатен полностью, платите только за сервер.

Если основная задача — «сеть из железа с SNMP», LibreNMS почти всегда быстрее по времени внедрения. Если у вас разнородный зоопарк с кастомными метриками приложений — присмотритесь к Zabbix, инструкция по установке есть в статье как установить и настроить Zabbix на VPS.

Требования к серверу и подготовка окружения

LibreNMS в связке с MariaDB и Redis не самый лёгкий стек, но для сети до пары сотен устройств хватает скромной машины:

Диск растёт за счёт RRD-файлов с историей графиков — на каждое устройство со временем накапливается по нескольку мегабайт, для сотни хостов с интервалом опроса 5 минут закладывайте запас на год-два вперёд.

Перед стартом нужен Docker с плагином Compose. Если ставите с нуля, весь процесс — от системных пакетов до первого docker compose up — разобран в статье как установить и настроить Docker Compose для продакшена на VPS. Здесь коротко:

curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER
newgrp docker
docker compose version

Создайте рабочую директорию и файл окружения:

mkdir -p ~/librenms && cd ~/librenms
touch .env

В .env — пароли и таймзону:

TZ=Europe/Moscow
DB_ROOT_PASSWORD=замените_на_свой_пароль
DB_PASSWORD=замените_на_свой_пароль

Сгенерировать надёжные значения:

openssl rand -base64 24

Docker Compose файл целиком

Официальный образ librenms/librenms — это универсальный контейнер: один и тот же образ запускается и как веб-интерфейс, и как диспетчер опроса (поллер), и как приёмник syslog/SNMP-трапов — роль переключается переменными окружения SIDECAR_*. Такая схема удобна тем, что не нужно тащить отдельные Dockerfile для каждого компонента.

services:
  db:
    image: mariadb:11
    container_name: librenms_db
    restart: unless-stopped
    command: --innodb-file-per-table=1 --lower-case-table-names=0
    environment:
      TZ: ${TZ}
      MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASSWORD}
      MYSQL_DATABASE: librenms
      MYSQL_USER: librenms
      MYSQL_PASSWORD: ${DB_PASSWORD}
    volumes:
      - db_data:/var/lib/mysql
    healthcheck:
      test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
      interval: 10s
      timeout: 5s
      retries: 6

  redis:
    image: redis:7-alpine
    container_name: librenms_redis
    restart: unless-stopped
    volumes:
      - redis_data:/data

  librenms:
    image: librenms/librenms:latest
    container_name: librenms
    hostname: librenms
    restart: unless-stopped
    cap_add:
      - NET_ADMIN
      - NET_RAW
    ports:
      - "8000:8000"
    environment:
      TZ: ${TZ}
      PUID: 1000
      PGID: 1000
      DB_HOST: db
      DB_NAME: librenms
      DB_USER: librenms
      DB_PASSWORD: ${DB_PASSWORD}
      DB_TIMEOUT: 60
      REDIS_HOST: redis
      LIBRENMS_WEB_PORT: 8000
    volumes:
      - librenms_data:/data
    depends_on:
      db:
        condition: service_healthy
      redis:
        condition: service_started

  dispatcher:
    image: librenms/librenms:latest
    container_name: librenms_dispatcher
    restart: unless-stopped
    cap_add:
      - NET_ADMIN
      - NET_RAW
    environment:
      TZ: ${TZ}
      PUID: 1000
      PGID: 1000
      DB_HOST: db
      DB_NAME: librenms
      DB_USER: librenms
      DB_PASSWORD: ${DB_PASSWORD}
      REDIS_HOST: redis
      SIDECAR_DISPATCHER: 1
    volumes:
      - librenms_data:/data
    depends_on:
      - librenms

  snmptrapd:
    image: librenms/librenms:latest
    container_name: librenms_snmptrapd
    restart: unless-stopped
    ports:
      - "162:1620/udp"
    environment:
      TZ: ${TZ}
      PUID: 1000
      PGID: 1000
      DB_HOST: db
      DB_NAME: librenms
      DB_USER: librenms
      DB_PASSWORD: ${DB_PASSWORD}
      SIDECAR_SNMPTRAPD: 1
    volumes:
      - librenms_data:/data
    depends_on:
      - librenms

  syslogng:
    image: librenms/librenms:latest
    container_name: librenms_syslogng
    restart: unless-stopped
    ports:
      - "514:514/udp"
    environment:
      TZ: ${TZ}
      PUID: 1000
      PGID: 1000
      DB_HOST: db
      DB_NAME: librenms
      DB_USER: librenms
      DB_PASSWORD: ${DB_PASSWORD}
      SIDECAR_SYSLOGNG: 1
    volumes:
      - librenms_data:/data
    depends_on:
      - librenms

volumes:
  db_data:
  redis_data:
  librenms_data:

Разделение веб-контейнера и dispatcher на отдельные сервисы — не обязательное требование, для небольшой сети можно оставить только librenms без SIDECAR_DISPATCHER, и он будет опрашивать устройства сам. Но если поллер начинает захлёбываться (сеть растёт, интервал опроса не укладывается в 5 минут), вынесенный dispatcher масштабируется отдельно — можно поднять два-три таких контейнера с разными DISPATCHER_NODE_ID.

Порт 162/UDP (SNMP traps) и 514/UDP (syslog) — опциональны, нужны только если хотите принимать активные уведомления от устройств, а не только опрашивать их по расписанию. Список переменных окружения у образа время от времени меняется — перед боевым разворачиванием сверьтесь с актуальным README в официальном репозитории librenms/docker на GitHub.

Первый запуск: веб-установщик и валидация

docker compose up -d
docker compose logs -f librenms

Дождитесь строки о готовности веб-сервера, затем откройте http://IP-сервера:8000/install. Мастер установки:

1. Проверит соединение с базой (реквизиты уже переданы через переменные окружения — просто подтвердите).
2. Прогонит миграции схемы.
3. Предложит создать первого администратора — логин, пароль, e-mail.

После завершения мастера зайдите внутрь контейнера и прогоните встроенную диагностику — она отлавливает добрую половину проблем на старте:

docker exec -it librenms lnms validate

Типичные предупреждения на этом шаге — неверные права на директорию /data/rrd (чинится пересозданием тома с правильным PUID/PGID) и не найденный fping — в официальном образе он уже встроен, если ошибка всё же вылезла, проверьте, что используете актуальный тег librenms/librenms:latest, а не устаревший локальный кэш.

Сразу закройте порт 8000 от внешнего мира файрволом и поставьте перед LibreNMS reverse-proxy с TLS (Caddy или nginx с Let's Encrypt) — веб-интерфейс отдаёт пароли устройств в конфигурации, ходить к нему по HTTP из открытого интернета не стоит.

Автообнаружение сети по SNMP

Автообнаружение — основная причина выбрать LibreNMS вместо ручной настройки Zabbix. Логика такая: вы задаёте один или несколько SNMP-community и диапазон подсетей, LibreNMS сам обходит адреса, проверяет отклик по SNMP и добавляет то, что откликнулось, с уже подобранным OS-детектором.

Community для чтения добавляется в Settings → SNMP → Communities & V3 Credentials, либо через .env-подобный конфиг контейнера:

docker exec -it librenms lnms config:set snmp.community '["public", "my-ro-community"]'

Диапазон сети для сканирования — в Settings → Poller → Auto Discovery, либо консольной командой:

docker exec -it librenms lnms discovery:new -n "office-lan"

Реально запустить обход сети:

docker exec -it librenms /opt/librenms/discovery-wrapper.py -h all

Каждое найденное устройство должно отвечать на SNMP-запрос community-строкой с правом на чтение — на Cisco это snmp-server community my-ro-community RO, на MikroTik — включённый SNMP в IP → SNMP с указанием той же community и разрешённой подсети источника. Без ответа на SNMP LibreNMS устройство просто не увидит — ни ping-сканирования, ни агентов у него нет, весь мониторинг строится вокруг SNMP (плюс опционально IPMI и агенты для более глубоких метрик Linux/Windows-хостов).

После первого обхода зайдите в Devices — там уже будет топология с распознанными вендорами, интерфейсами и их скоростью. Ошибочно определённый тип устройства можно поправить вручную в карточке хоста — это не сломает опрос, просто скорректирует набор графиков.

Алерты, дашборды и обновление системы

Алертинг в LibreNMS настраивается через Alerts → Alert Rules — правила пишутся на понятном DSL (%devices.status = 0 и подобное), готовые шаблоны есть под самые частые случаи: устройство недоступно, интерфейс упал, диск заполнен, температура выше порога. Транспорты для уведомлений — Telegram, e-mail, Slack, вебхуки — настраиваются в Alerts → Alert Transports, у Telegram-бота это токен и chat_id, ничего специфичного под LibreNMS придумывать не нужно.

Дашборды собираются из готовых виджетов (топ загруженных интерфейсов, карта сети, список алертов) методом drag-and-drop — с нуля рисовать графики, как в Grafana, не требуется, но при желании LibreNMS можно подключить как источник данных к внешней Grafana через плагин или экспорт метрик — если у вас уже есть стек с Prometheus и Grafana под другие сервисы, вариант интеграции разобран в статье мониторинг VPN через Prometheus и Grafana, общие принципы применимы и здесь.

Обновление в Docker-варианте сводится к смене тега образа и пересозданию контейнеров — данные в томах db_data и librenms_data не теряются:

docker compose pull
docker compose up -d
docker exec -it librenms lnms validate

Перед обновлением обязательно снимите дамп базы — LibreNMS активно развивается, миграции схемы иногда меняют структуру таблиц, и откат после неудачной миграции проще делать из бэкапа, чем вручную:

docker exec librenms_db mariadb-dump -u root -p"$DB_ROOT_PASSWORD" librenms > librenms_$(date +%F).sql

Частая проблема после обновления — «зависшие» задачи в очереди Redis из-за смены формата задач между версиями. Лечится перезапуском dispatcher и redis:

docker compose restart redis dispatcher

Если поллер регулярно не укладывается в интервал (в логах dispatcher видно накопление задач), это почти всегда означает, что пора либо увеличить POLLER_THREADS, либо вынести опрос на второй dispatcher-контейнер с распределением нагрузки — оба варианта не требуют переустановки, только правки переменных окружения.

Частые вопросы