8 складов и ни одного алерта: LibreNMS для мониторинга сети логистической компании

Задача клиента: распределённая сеть без мониторинга

В январе 2026 года к нам в АйТи Фреш обратилась логистическая компания «ЛогиСервис» из Москвы — оператор складской логистики с 8 складскими комплексами по всей России: Москва (2), Санкт-Петербург, Казань, Екатеринбург, Новосибирск, Ростов-на-Дону, Краснодар.

На каждом складе работало 15–30 единиц сетевого оборудования: управляемые коммутаторы (доступ для ТСД и ПК), Wi-Fi точки доступа (для терминалов сбора данных на складе), маршрутизаторы (VPN между складами и офисом), ИБП с сетевым управлением. Итого — около 200 сетевых устройств, и ни одно не мониторилось.

«Мы узнаём о проблемах от кладовщиков: "Интернет не работает", "ТСД не подключается к Wi-Fi". Но к моменту звонка WMS-система уже потеряла связь с терминалами, и весь склад простаивает. Последний раз Казань стояла 4 часа, потому что в коммутаторе "тихо" умер порт, а никто не заметил» — IT-директор «ЛогиСервис».

Аудит сетевой инфраструктуры складов

Наши инженеры провели удалённый аудит всех 8 складов через VPN:

  • Коммутаторы: Cisco Catalyst 2960 (Москва, СПб), MikroTik CRS326 (регионы), D-Link DGS-1210 (старые склады)
  • Wi-Fi: Ubiquiti UniFi AP-AC-Pro (везде), управлялись локальными контроллерами
  • Маршрутизаторы: MikroTik RB4011 (VPN между складами), Cisco ISR 1111 (Москва)
  • ИБП: APC Smart-UPS 3000 с AP9631 NMC (сетевой модуль)
  • Серверы: Linux-серверы с WMS-системой на каждом складе

Проблемы:

  1. Нулевой мониторинг — ни SNMP, ни пинги, ни алерты
  2. Реактивная поддержка — узнавали о проблемах от пользователей
  3. Нет бэкапов конфигов — если оборудование сгорит, конфигурацию придётся восстанавливать по памяти
  4. Нет истории — невозможно проанализировать, когда началась деградация канала

Мы выбрали LibreNMS — open-source NMS-систему, форк Observium. Ключевые преимущества для нашего случая: поддержка SNMP v2c/v3, auto-discovery, встроенная карта (weathermap), интеграция с Oxidized для бэкапа конфигов, Telegram-алерты и API для интеграции с WMS.

Установка LibreNMS через Docker

Мы развернули LibreNMS на выделенном сервере в московском офисе (Ubuntu 22.04, 4 CPU, 8 GB RAM). Docker-установка обеспечивает изоляцию и простоту обновления.

Docker Compose конфигурация

# Создаём директорию проекта
mkdir -p /opt/librenms && cd /opt/librenms

# docker-compose.yml
cat > docker-compose.yml << 'EOF'
version: "3.8"

services:
  db:
    image: mariadb:10.11
    container_name: librenms_db
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: "R00tDB!2026Secure"
      MYSQL_DATABASE: librenms
      MYSQL_USER: librenms
      MYSQL_PASSWORD: "L1breNMS!DB@2026"
    volumes:
      - ./data/db:/var/lib/mysql
    command:
      - "--innodb-file-per-table=1"
      - "--lower-case-table-names=0"
      - "--character-set-server=utf8mb4"
      - "--collation-server=utf8mb4_unicode_ci"

  redis:
    image: redis:7-alpine
    container_name: librenms_redis
    restart: always

  librenms:
    image: librenms/librenms:latest
    container_name: librenms
    restart: always
    depends_on:
      - db
      - redis
    ports:
      - "8080:8000"
    environment:
      DB_HOST: db
      DB_NAME: librenms
      DB_USER: librenms
      DB_PASSWORD: "L1breNMS!DB@2026"
      DB_TIMEOUT: 60
      REDIS_HOST: redis
      CACHE_DRIVER: redis
      SESSION_DRIVER: redis
      APP_URL: "https://nms.logiservice.ru"
      LIBRENMS_SNMP_COMMUNITY: "LogiSNMP2026"
      LIBRENMS_WEATHERMAP: "true"
    volumes:
      - ./data/librenms:/data
      - ./data/rrd:/opt/librenms/rrd
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8000"]
      interval: 30s
      timeout: 10s
      retries: 3

  dispatcher:
    image: librenms/librenms:latest
    container_name: librenms_dispatcher
    restart: always
    depends_on:
      - librenms
    environment:
      DB_HOST: db
      DB_NAME: librenms
      DB_USER: librenms
      DB_PASSWORD: "L1breNMS!DB@2026"
      REDIS_HOST: redis
      DISPATCHER_NODE_ID: dispatcher1
      SIDECAR_DISPATCHER: 1
    volumes:
      - ./data/librenms:/data
      - ./data/rrd:/opt/librenms/rrd
EOF

# Запускаем
docker compose up -d

# Проверяем статус
docker compose ps
# librenms          running (healthy)
# librenms_db       running
# librenms_redis    running
# librenms_dispatcher running

# Создаём admin-пользователя
docker exec -it librenms lnms user:add admin -p 'Adm1n!NMS2026' -r admin -e admin@logiservice.ru

Настройка nginx reverse proxy с SSL

# /etc/nginx/sites-available/librenms.conf
server {
    listen 443 ssl http2;
    server_name nms.logiservice.ru;

    ssl_certificate /etc/letsencrypt/live/nms.logiservice.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/nms.logiservice.ru/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

server {
    listen 80;
    server_name nms.logiservice.ru;
    return 301 https://$server_name$request_uri;
}

# Включаем и проверяем
sudo ln -s /etc/nginx/sites-available/librenms.conf /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

Настройка SNMP на сетевом оборудовании

SNMP (Simple Network Management Protocol) — протокол, через который LibreNMS собирает метрики с оборудования. Мы настроили SNMP v3 для безопасности и SNMP v2c как fallback для старых устройств.

SNMP v3 на Cisco Catalyst 2960

! Cisco Catalyst 2960 — настройка SNMP v3
enable
configure terminal

! Создаём SNMP view (что разрешено читать)
snmp-server view FULL iso included

! Создаём группу с аутентификацией и шифрованием
snmp-server group MONITOR v3 priv read FULL

! Создаём пользователя (auth SHA + priv AES128)
snmp-server user librenms MONITOR v3 auth sha Auth!SNMP2026 priv aes 128 Priv!SNMP2026

! Информация о местоположении
snmp-server location "Moscow Warehouse 1, Rack A2"
snmp-server contact "noc@logiservice.ru"

! Включаем SNMP traps
snmp-server enable traps snmp linkdown linkup coldstart
snmp-server enable traps config
snmp-server enable traps cpu threshold
snmp-server enable traps envmon fan shutdown supply temperature status
snmp-server host 10.0.0.50 version 3 priv librenms

end
write memory

SNMP на MikroTik RouterOS

# MikroTik RouterOS — настройка SNMP v3
/snmp
set enabled=yes contact="noc@logiservice.ru" \
  location="Kazan Warehouse, Rack B1" trap-version=3

/snmp community
set [ find default=yes ] disabled=yes
add name=librenms addresses=10.0.0.50/32 \
  security=private \
  authentication-protocol=SHA1 \
  authentication-password="Auth!SNMP2026" \
  encryption-protocol=AES \
  encryption-password="Priv!SNMP2026" \
  read-access=yes write-access=no

SNMP на Linux-серверах

# Устанавливаем snmpd на каждом Linux-сервере
sudo apt install -y snmpd snmp libsnmp-dev

# Конфигурация /etc/snmp/snmpd.conf
sudo bash -c 'cat > /etc/snmp/snmpd.conf << EOF
# Слушаем на всех интерфейсах
agentaddress udp:161

# SNMPv3 пользователь
createUser librenms SHA "Auth!SNMP2026" AES "Priv!SNMP2026"
rouser librenms priv

# Системная информация
sysLocation    Moscow Warehouse WMS Server
sysContact     noc@logiservice.ru
sysServices    72

# Расширенные метрики
extend distro /usr/bin/distro
extend hardware /bin/cat /sys/devices/virtual/dmi/id/product_name
extend manufacturer /bin/cat /sys/devices/virtual/dmi/id/sys_vendor

# Мониторинг дисков
disk / 10%
disk /var 10%

# Мониторинг процессов
proc sshd
proc nginx
proc postgres
EOF'

# Скачиваем скрипт distro
sudo wget -O /usr/bin/distro https://raw.githubusercontent.com/librenms/librenms-agent/master/snmp/distro
sudo chmod +x /usr/bin/distro

# Перезапускаем
sudo systemctl restart snmpd
sudo systemctl enable snmpd

# Проверяем локально
snmpwalk -v3 -u librenms -l authPriv -a SHA -A 'Auth!SNMP2026' -x AES -X 'Priv!SNMP2026' localhost system
# SNMPv2-MIB::sysDescr.0 = STRING: Linux wms-msk-01 5.15.0-91-generic

Auto-discovery и группы устройств

LibreNMS умеет автоматически обнаруживать устройства в сети через CDP/LLDP, SNMP scan и ARP-таблицы. Мы настроили автообнаружение для каждого склада.

Настройка auto-discovery

# В LibreNMS UI: Settings → Discovery → SNMP
# Или через конфигурацию:
docker exec -it librenms lnms config:set snmp.community.0 "LogiSNMP2026"
docker exec -it librenms lnms config:set snmp.v3.0.authlevel "authPriv"
docker exec -it librenms lnms config:set snmp.v3.0.authname "librenms"
docker exec -it librenms lnms config:set snmp.v3.0.authpass "Auth!SNMP2026"
docker exec -it librenms lnms config:set snmp.v3.0.authalgo "SHA"
docker exec -it librenms lnms config:set snmp.v3.0.cryptopass "Priv!SNMP2026"
docker exec -it librenms lnms config:set snmp.v3.0.cryptoalgo "AES"

# Добавляем сети для discovery
docker exec -it librenms lnms config:set nets.0 "10.1.0.0/16"   # Москва
docker exec -it librenms lnms config:set nets.1 "10.2.0.0/16"   # СПб
docker exec -it librenms lnms config:set nets.2 "10.3.0.0/16"   # Казань
docker exec -it librenms lnms config:set nets.3 "10.4.0.0/16"   # Екатеринбург
docker exec -it librenms lnms config:set nets.4 "10.5.0.0/16"   # Новосибирск
docker exec -it librenms lnms config:set nets.5 "10.6.0.0/16"   # Ростов
docker exec -it librenms lnms config:set nets.6 "10.7.0.0/16"   # Краснодар

# Включаем discovery через LLDP/CDP
docker exec -it librenms lnms config:set autodiscovery.xdp true
docker exec -it librenms lnms config:set autodiscovery.ospf true
docker exec -it librenms lnms config:set autodiscovery.arp true

# Ручное добавление ключевых устройств (seed devices)
# LibreNMS обнаружит остальные через LLDP/CDP
docker exec -it librenms lnms device:add 10.1.0.1 --v3-auth-level authPriv \
  --v3-auth-name librenms --v3-auth-pass 'Auth!SNMP2026' --v3-auth-proto SHA \
  --v3-priv-pass 'Priv!SNMP2026' --v3-priv-proto AES

# Повторяем для маршрутизатора каждого склада
for ip in 10.2.0.1 10.3.0.1 10.4.0.1 10.5.0.1 10.6.0.1 10.7.0.1; do
  docker exec -it librenms lnms device:add $ip --v3-auth-level authPriv \
    --v3-auth-name librenms --v3-auth-pass 'Auth!SNMP2026' --v3-auth-proto SHA \
    --v3-priv-pass 'Priv!SNMP2026' --v3-priv-proto AES
done

# Запускаем discovery
docker exec -it librenms lnms discovery:run

# Результат через 15 минут:
# Discovered 187 devices across 8 locations
# 42 switches, 16 routers, 48 APs, 16 UPS, 24 servers, 41 other

Группы устройств и дашборды

Организуем устройства по складам и типам:

# Создаём группы через CLI (или через Web UI)
docker exec -it librenms lnms device-group:add "Moscow-WH1" \
  --rules '{"condition":"AND","rules":[{"id":"location","field":"location","type":"string","operator":"contains","value":"Moscow Warehouse 1"}]}'

docker exec -it librenms lnms device-group:add "Moscow-WH2" \
  --rules '{"condition":"AND","rules":[{"id":"location","field":"location","type":"string","operator":"contains","value":"Moscow Warehouse 2"}]}'

# Группы по типу оборудования
docker exec -it librenms lnms device-group:add "All-Switches" \
  --rules '{"condition":"AND","rules":[{"id":"type","field":"type","type":"string","operator":"equal","value":"network"}]}'

docker exec -it librenms lnms device-group:add "All-UPS" \
  --rules '{"condition":"AND","rules":[{"id":"type","field":"type","type":"string","operator":"equal","value":"power"}]}'

# Дашборды в Web UI:
# - Общий дашборд: карта России с метками складов (виджет Worldmap)
# - Per-warehouse: утилизация портов, трафик, статус Wi-Fi
# - Alerts: активные алерты, история инцидентов
# - Availability: SLA per warehouse за 30 дней

Алертинг: Telegram, email и эскалация

Мониторинг без алертов — просто красивые графики. Мы настроили многоуровневую систему оповещений.

Настройка Telegram-бота для алертов

# 1. Создаём бота через @BotFather в Telegram
# Получаем token: 7098765432:AAHxxxxxxxxxxxxxxxxxxxxxxxxxxx

# 2. Создаём группу «NOC Alerts» и добавляем бота
# Chat ID: -1001234567890

# 3. Настраиваем транспорт в LibreNMS
# Settings → Alerting → Alert Transports → Add Transport

# Через конфигурацию:
docker exec -it librenms lnms config:set alert.transports.telegram.0.telegram-token "7098765432:AAHxxxxxxxxxxxxxxxxxxxxxxxxxxx"
docker exec -it librenms lnms config:set alert.transports.telegram.0.telegram-chat-id "-1001234567890"

# Шаблон алерта (Settings → Alert Templates):
# Название: "Warehouse Alert"
# Шаблон:
# 🔴 *{{ $alert->title }}*
# 
# 📍 Device: {{ $alert->hostname }} ({{ $alert->location }})
# ⏰ Time: {{ $alert->timestamp }}
# 📋 Severity: {{ $alert->severity }}
# 
# {{ $alert->msg }}
#
# 🔗 [Open in LibreNMS](https://nms.logiservice.ru/device/device={{ $alert->device_id }})

Правила алертов

# Настраиваем правила алертов через Web UI или конфигурацию

# Правило 1: Устройство недоступно (critical)
# Условие: Device is down
# Задержка: 2 минуты (чтобы не спамить при кратковременных потерях)
# Транспорт: Telegram + Email

# Правило 2: Порт down на коммутаторе (warning)
# Условие: Port went down AND port description contains "uplink" OR "server" OR "wms"
# Задержка: 1 минута
# Транспорт: Telegram

# Правило 3: Высокая утилизация порта (>85%)
# Условие: Port utilization > 85% for 10 minutes
# Транспорт: Email

# Правило 4: ИБП на батарее
# Условие: UPS input voltage = 0 (перешёл на батарею)
# Задержка: 0 (немедленно!)
# Транспорт: Telegram + Email + SMS (через HTTP API)

# Правило 5: Температура оборудования
# Условие: Sensor temperature > threshold
# Транспорт: Telegram

# Правило 6: Wi-Fi AP недоступна
# Условие: Device down AND device group = "All-APs"
# Задержка: 3 минуты
# Транспорт: Telegram

# Тестируем алерт
docker exec -it librenms lnms alert:test 1
# Alert sent successfully via telegram

Oxidized: автоматический бэкап конфигов

Oxidized — инструмент для автоматического сбора и версионирования конфигураций сетевого оборудования. Интегрируется с LibreNMS и хранит историю изменений в Git.

Установка и настройка Oxidized

# Добавляем Oxidized в docker-compose.yml
cat >> docker-compose.yml << 'EOF'

  oxidized:
    image: oxidized/oxidized:latest
    container_name: oxidized
    restart: always
    ports:
      - "8888:8888"
    volumes:
      - ./data/oxidized:/root/.config/oxidized
    environment:
      CONFIG_RELOAD_INTERVAL: 600
EOF

# Создаём конфигурацию Oxidized
mkdir -p ./data/oxidized

cat > ./data/oxidized/config << 'EOF'
---
username: admin
password: OxAdmin2026!
model: junos
resolve_dns: true
interval: 3600        # Собираем конфиги каждый час
use_syslog: false
log: /root/.config/oxidized/oxidized.log
debug: false

threads: 30
timeout: 20
retries: 3
prompt: !ruby/regexp /^([\w.@()-]+[#>]\s?)$/

rest: 0.0.0.0:8888

input:
  default: ssh, telnet
  debug: false
  ssh:
    secure: false

output:
  default: git
  git:
    user: oxidized
    email: oxidized@logiservice.ru
    repo: /root/.config/oxidized/configs.git

source:
  default: http
  debug: false
  http:
    url: https://nms.logiservice.ru/api/v0/oxidized
    scheme: https
    map:
      name: hostname
      model: os
      group: location
    headers:
      X-Auth-Token: "your-librenms-api-token-here"

model_map:
  cisco: ios
  routeros: routeros
  linux: linux
  apc_aos: apc_aos
EOF

# Перезапускаем с Oxidized
docker compose up -d oxidized

# Настраиваем интеграцию в LibreNMS
docker exec -it librenms lnms config:set oxidized.enabled true
docker exec -it librenms lnms config:set oxidized.url "http://oxidized:8888"
docker exec -it librenms lnms config:set oxidized.features.versioning true

# Через час проверяем — конфиги собраны
docker exec -it oxidized oxidized list
# sw-msk-01 (ios) - success - 2026-01-15 14:23:01
# rt-msk-01 (routeros) - success - 2026-01-15 14:23:05
# ...
# 187 devices, 183 success, 4 failed

Просмотр и сравнение конфигов в LibreNMS

После интеграции Oxidized в LibreNMS на странице каждого устройства появляется вкладка Config с текущей конфигурацией и историей изменений:

# В Web UI: Device → Config
# Показывает diff между версиями конфигурации
# Можно увидеть, кто и когда изменил конфигурацию коммутатора

# Через Git напрямую:
cd /opt/librenms/data/oxidized/configs.git
git log --oneline -20
# a3f4b7c (HEAD) sw-msk-01 - 2026-01-15 15:23
# b5c6d7e sw-kzn-02 - 2026-01-15 15:22
# c7d8e9f rt-spb-01 - 2026-01-15 15:21

# Смотрим изменения в конфиге конкретного устройства
git log --oneline -- sw-msk-01
git diff HEAD~5 HEAD -- sw-msk-01
# - spanning-tree vlan 20 priority 24576
# + spanning-tree vlan 20 priority 8192
# Видим: кто-то изменил STP priority на VLAN 20

Weathermap: визуальная карта сети

Weathermap — визуализация сети в виде карты с линками между устройствами, цветом показывающая утилизацию каналов в реальном времени.

Настройка Network Weathermap

# LibreNMS включает плагин Weathermap
# Включаем в Settings → Plugins → Weathermap → Enable

# Создаём карту через Web Editor:
# https://nms.logiservice.ru/weathermap/editor

# Пример конфигурации карты (автоматически генерируется редактором):
# /opt/librenms/data/librenms/plugins/Weathermap/configs/russia-warehouses.conf

WIDTH 1200
HEIGHT 800
HTMLOUTPUTFILE russia-overview.html
IMAGEOUTPUTFILE russia-overview.png
TITLE LogiService - Network Overview

KEYPOS DEFAULT 10 700
KEYSTYLE DEFAULT horizontal 400 50

SCALE DEFAULT 0    0    192 192 192   # Серый - нет данных
SCALE DEFAULT 0    1    200 255 200   # Зелёный - свободно
SCALE DEFAULT 1    30   128 255 128
SCALE DEFAULT 30   60   255 255 0     # Жёлтый - средняя нагрузка
SCALE DEFAULT 60   85   255 165 0     # Оранжевый
SCALE DEFAULT 85   100  255 0   0     # Красный - перегруз

# Узлы (склады)
NODE moscow-wh1
    LABEL Moscow WH1
    POSITION 400 200
    ICON /opt/librenms/html/images/icons/warehouse.png

NODE moscow-wh2
    LABEL Moscow WH2
    POSITION 500 250

NODE spb-wh
    LABEL SPb WH
    POSITION 350 100

NODE kazan-wh
    LABEL Kazan WH
    POSITION 700 200

# Линки между узлами (VPN-туннели)
LINK moscow-wh1-to-spb
    NODES moscow-wh1 spb-wh
    TARGET /opt/librenms/rrd/rt-msk-01/port-GigabitEthernet0_0_1.rrd
    WIDTH 4
    BANDWIDTH 100M

В результате IT-директор «ЛогиСервис» видит на одном экране состояние всех 8 складов — зелёные линки означают нормальную нагрузку, красные — перегруз, серые — обрыв.

Интеграция LibreNMS API с WMS-системой

«ЛогиСервис» использует WMS-систему для управления складскими операциями. Мы интегрировали LibreNMS с WMS через REST API — теперь WMS-дашборд показывает статус сетевой инфраструктуры склада прямо в интерфейсе оператора:

# Пример запроса к LibreNMS API
# Получаем статус всех устройств на складе в Казани
curl -s -H 'X-Auth-Token: your-api-token' \
  'https://nms.logiservice.ru/api/v0/devices?type=network&location=Kazan' \
  | python3 -m json.tool

# Ответ:
# {
#   "status": "ok",
#   "devices": [
#     {"hostname": "sw-kzn-01", "status": 1, "uptime": 2847291},
#     {"hostname": "sw-kzn-02", "status": 1, "uptime": 2847105},
#     {"hostname": "ap-kzn-01", "status": 1, "uptime": 1284729},
#     ...
#   ]
# }

# Получаем трафик на порту (для отображения загрузки канала)
curl -s -H 'X-Auth-Token: your-api-token' \
  'https://nms.logiservice.ru/api/v0/devices/sw-kzn-01/ports/GigabitEthernet0_1/port_bits' \
  | python3 -m json.tool

# Скрипт для WMS-интеграции (Python)
import requests

class LibreNMSClient:
    def __init__(self, url, token):
        self.url = url
        self.headers = {'X-Auth-Token': token}

    def get_warehouse_status(self, location):
        resp = requests.get(
            f'{self.url}/api/v0/devices',
            headers=self.headers,
            params={'location': location}
        )
        devices = resp.json()['devices']
        total = len(devices)
        up = sum(1 for d in devices if d['status'] == 1)
        return {'total': total, 'up': up, 'down': total - up}

# WMS отображает: "Казань: 18/18 устройств online" (зелёный)
# или: "Казань: 16/18 устройств online (2 DOWN!)" (красный)

Эта интеграция позволяет операторам WMS видеть проблемы с сетью до того, как они повлияют на складские операции — например, если Wi-Fi точка доступа в зоне приёмки товара упала, оператор может перенаправить кладовщиков с ТСД в зону с работающим Wi-Fi, не дожидаясь звонка с жалобой.

Результаты внедрения: от реактивного к проактивному

Внедрение LibreNMS заняло 14 рабочих дней: 2 дня установка и настройка LibreNMS, 5 дней настройка SNMP на 200 устройствах (удалённо через VPN), 3 дня настройка алертов и Oxidized, 2 дня создание дашбордов и weathermap, 2 дня обучение NOC-команды.

Измеримые результаты за первые 3 месяца

МетрикаДо LibreNMSПосле LibreNMS
Среднее время обнаружения проблемы (MTTD)45–120 минут (от звонка пользователя)2–3 минуты (автоалерт)
Среднее время восстановления (MTTR)2–4 часа15–30 минут
Простой складов в месяц~8 часов~40 минут
Предотвращённые инциденты0 (не было мониторинга)12 за квартал
Бэкапы конфигурацийНет187 устройств, ежечасно
Устройств под мониторингом0187
Активных алерт-правил018

Реальные кейсы предотвращённых простоев

За первые 3 месяца LibreNMS помогла предотвратить несколько серьёзных инцидентов:

  • Казань, неделя 2: LibreNMS зафиксировала рост ошибок CRC на uplink-порту коммутатора. Алерт пришёл в Telegram за 40 минут до полного отказа порта. Инженер переключил uplink на резервный порт удалённо — ноль простоя.
  • Новосибирск, неделя 5: ИБП перешёл на батарею в 03:00 ночи. Алерт разбудил дежурного, который связался с электриками. Батарея разрядилась бы за 45 минут — успели за 20.
  • Москва-WH2, неделя 8: Oxidized зафиксировал несанкционированное изменение конфигурации маршрутизатора — стажёр случайно удалил VPN-туннель к Краснодару. Откатили конфиг из Git за 2 минуты.

Инженеры АйТи Фреш обеспечивают техподдержку LibreNMS на аутсорсе: добавление новых устройств, создание дашбордов, обновление системы и консультации NOC-команды «ЛогиСервис».

Часто задаваемые вопросы

LibreNMS специализируется на сетевом мониторинге: из коробки поддерживает 1600+ типов сетевого оборудования через SNMP MIB, включает auto-discovery через CDP/LLDP, weathermap и интеграцию с Oxidized. Zabbix — более универсальная платформа (серверы, приложения, базы данных), но для сетевого оборудования требует ручного создания шаблонов. Если основная задача — мониторинг коммутаторов, маршрутизаторов и Wi-Fi, LibreNMS запускается быстрее и требует меньше настройки. Для комплексного мониторинга (серверы + сеть + приложения) лучше подходит Zabbix.

SNMP v2c передаёт community string (по сути пароль) в открытом виде — любой, кто перехватит трафик, получит доступ к управлению оборудованием. SNMP v3 обеспечивает аутентификацию (SHA/MD5) и шифрование (AES/DES). Для распределённой сети с трафиком через интернет (VPN между складами) это критично. Мы рекомендуем v3 всегда, а v2c — только для устаревшего оборудования, которое не поддерживает v3, и только в изолированных VLAN.

Для 200 устройств с 5-минутным интервалом поллинга достаточно: 4 CPU, 8 GB RAM, 100 GB SSD. RRD-файлы (графики) занимают примерно 200 МБ на устройство, но со временем не растут (round-robin). Для 500 устройств рекомендуем 8 CPU, 16 GB RAM, 500 GB SSD. LibreNMS хорошо масштабируется через distributed polling — можно добавить poller-серверы в каждом регионе для снижения задержки.

Для устройств в удалённых филиалах за NAT есть несколько подходов: 1) VPN-туннель (как в нашем случае) — LibreNMS опрашивает устройства через VPN по внутренним IP; 2) Distributed polling — установить poller LibreNMS в каждом филиале; 3) SNMP proxy — проксирование SNMP-запросов через маршрутизатор филиала. Самый надёжный вариант — VPN: LibreNMS в центральном офисе имеет прямой доступ ко всем устройствам.

TFTP-бэкапы сохраняют только текущую версию конфигурации. Oxidized хранит полную историю изменений в Git — вы видите, что изменилось, когда и можете откатить к любой предыдущей версии. Интеграция с LibreNMS показывает diff конфигурации прямо в веб-интерфейсе. Это незаменимо для расследования инцидентов: если после изменения конфигурации что-то сломалось — вы точно знаете, какая строка была изменена.

Нужна помощь с настройкой?

Специалисты АйТи Фреш помогут с внедрением и настройкой — 15+ лет опыта, обслуживание от 15 000 ₽/мес

📞 Связаться с нами
#LibreNMS установка настройка#мониторинг сети SNMP#SNMP v3 настройка#LibreNMS auto-discovery#мониторинг сетевого оборудования#LibreNMS алерты Telegram#weathermap сети#Oxidized бэкап конфигов