NetBox или LibreNMS: что выгоднее и когда

MAATRIX

Когда в сети становится больше десятка устройств, а Excel с IP-адресами превращается в файл, который правит уже три человека вслепую, встаёт вопрос: что ставить — NetBox или LibreNMS? Они звучат как конкуренты в одном ряду сравнений «X или Y», но на деле решают разные задачи, и выбор не глядя в свой сценарий почти всегда оборачивается разочарованием через пару месяцев. Разберём, что каждый из них умеет, сколько ресурсов просит и в каком случае имеет смысл ставить оба сразу.

NetBox и LibreNMS — не конкуренты, а разные инструменты

NetBox — это DCIM и IPAM: система учёта инфраструктуры. Она отвечает на вопросы «какой IP свободен в этой подсети», «в каком юните стойки стоит этот сервер», «через какой порт коммутатора идёт кабель к патч-панели», «какие VLAN выделены под этот сайт». NetBox не опрашивает оборудование сам — это база данных с удобным веб-интерфейсом и REST/GraphQL API, источник истины (source of truth), на который опираются скрипты автоматизации, Ansible-плейбуки и Terraform-провайдеры.

LibreNMS — это система мониторинга сети. Она сама ходит по устройствам через SNMP (и частично по SSH/API для некоторых вендоров), собирает метрики — загрузку интерфейсов, температуру, ошибки CRC, доступность, — рисует графики и шлёт алерты, когда порт падает или диск на свитче забивается логами.

Итого: NetBox — это «что у нас есть и как оно должно быть устроено», LibreNMS — «что происходит с этим прямо сейчас». Прямого пересечения функций мало: у NetBox есть примитивный учёт устройств без реального опроса, у LibreNMS — черновой инвентарь без адресного планирования. Сравнивать их как взаимозаменяемые продукты некорректно, но на практике команды часто выбирают только один инструмент из-за бюджета или времени на внедрение — и вот здесь сравнение уже осмысленно.

Установка, стек и требования к серверу

Оба проекта self-hosted, оба ставятся на обычный VPS, но стек разный.

NetBox: Python/Django, PostgreSQL как основная БД, Redis для кэша и очередей (RQ/Celery-подобные задачи), опционально nginx + gunicorn/uWSGI перед приложением. Для команды до 500-1000 устройств хватает 2 vCPU и 4 ГБ RAM — PostgreSQL нетребователен, пока база не разрастается до десятков тысяч префиксов и объектов с историей изменений (NetBox хранит changelog по каждому объекту, и это со временем ест место на диске).

LibreNMS: PHP (Laravel) + MySQL/MariaDB, плюс RRDtool или Graphite для хранения временных рядов графиков, cron-задачи для опроса (по умолчанию раз в 5 минут), redis опционально для кэша. Здесь узкое место — диск и I/O: RRD-файлы пишутся на каждое устройство и каждую метрику постоянно, и при мониторинге 50+ устройств с десятками интерфейсов лучше сразу закладывать SSD, а не сетевой диск с высокой задержкой — иначе поллер начинает не укладываться в 5-минутный интервал и алерты запаздывают.

Для старта на своём сервере пошагово можно свериться с отдельными инструкциями — установка NetBox на VPS и установка LibreNMS на VPS — там разобраны конкретные команды для чистой Ubuntu.

# Ориентировочный минимум для старта (не для прод-нагрузки в сотни устройств)
NetBox:    2 vCPU, 4 GB RAM, 20-40 GB SSD (PostgreSQL растёт медленно)
LibreNMS:  2 vCPU, 4 GB RAM, от 40 GB SSD (RRD-графики растут быстро)

Точные цифры для LibreNMS сильно зависят от числа опрашиваемых портов и retention графиков — это ориентир, а не гарантия, реальное потребление стоит смотреть по своей нагрузке в первые недели.

IPAM и Source of Truth — сильная сторона NetBox

Если у вас есть задача держать актуальную карту адресного пространства — какие подсети выделены под какой сайт, какие IP заняты, какие VLAN закреплены за каким департаментом, — NetBox закрывает это гораздо честнее, чем таблица в облаке. Ключевые вещи, которые он даёт:

• Иерархия префиксов с автоматическим расчётом свободных диапазонов и утилизации.
• Учёт стоек, юнитов, кабелей, портов коммутаторов — вплоть до физической топологии дата-центра.
• Кастомные поля и теги — можно завести атрибут «ответственный отдел» или «дата ввода в эксплуатацию» без правки кода.
• REST и GraphQL API — на нём строятся автоматизации: скрипт создания VM тянет из NetBox свободный IP, а не берёт «первый попавшийся» вручную.
• Плагины экосистемы: from netbox-plugin-dns до netbox-topology-views — сообщество живое, апдейты регулярные.

Слабое место NetBox — он ничего не проверяет сам. Если инженер настроил интерфейс с другим IP в обход NetBox, система об этом не узнает, пока кто-то не откроет её и не свяжет учёт с реальностью — либо руками, либо синхронизацией через скрипт опроса. NetBox — это дисциплина команды, а не автономный сторож.

Мониторинг, графики и алерты — сильная сторона LibreNMS

LibreNMS решает противоположную задачу: он смотрит на сеть, а не описывает её на бумаге. Из коробки после автообнаружения (discovery) по SNMP он умеет:

• Собирать метрики с сотен вендоров через готовые SNMP MIB-профили — Cisco, MikroTik, Juniper, HP/Aruba, да и обычные Linux-серверы с net-snmp.
• Рисовать графики трафика по интерфейсам, загрузки CPU/RAM, температуры, состояния БП и вентиляторов на поддерживаемом железе.
• Алертить в Telegram, Slack, по email или через webhook — правила алертов гибко настраиваются по группам устройств.
• Строить карты сети (weathermap) — наглядно, где именно упала пропускная способность.
• Вести биллинг трафика (billing) по портам — удобно, если считаете исходящий трафик клиентам.

Минусы, о которых честно стоит сказать: веб-интерфейс LibreNMS выглядит откровенно устаревшим по сравнению с современными дашбордами вроде Grafana, а тонкая настройка алертов через встроенный rule builder требует привыкания — синтаксис не самый интуитивный. Если нужны действительно кастомные дашборды и сложная визуализация, многие связывают LibreNMS с Grafana через плагин источника данных, а не ограничиваются встроенными графиками.

Частые ошибки после установки — SNMP-community не совпадает на устройстве и в LibreNMS, поллер не укладывается в cron-интервал из-за медленного диска, забытые лимиты open_files в PHP-FPM. Разбор типовых сбоев есть в статье про частые ошибки LibreNMS на сервере.

Сравнение по сценариям

Если нужно выбрать буквально один инструмент под ограниченный бюджет — отталкивайтесь от боли, которая мешает сейчас. Путаница в IP-адресах и отсутствие карты сети — берите NetBox. Сеть падает без предупреждения, а вы узнаёте об инцидентах от клиентов — берите LibreNMS. Кстати, похожая логика разбирается и в сравнении Zabbix или Prometheus: вопрос не «что лучше вообще», а «какую конкретно боль вы закрываете».

Когда ставить оба вместе

На практике зрелая инфраструктура рано или поздно приходит к обоим инструментам одновременно — они не конкурируют за ресурсы сервера так сильно, чтобы это было проблемой (можно развести по двум небольшим VPS или даже держать на одном при аккуратном разделении ресурсов).

Типовая связка выглядит так: NetBox остаётся источником истины — в нём заведены все устройства, их IP и роль в сети. LibreNMS настраивается на автообнаружение по списку из NetBox (через его API можно выгрузить список хостов и community-строки и скормить их в LibreNMS вместо ручного добавления). Готового «официального» модуля синхронизации на все случаи жизни в экосистеме нет — обычно это самописный скрипт на Python, который раз в сутки дергает NetBox API и обновляет список устройств в LibreNMS через его собственный API. Это лишние 30-60 минут разработки, но именно так исчезает ситуация «завели устройство в мониторинге и забыли занести в учёт», а IPAM перестаёт расходиться с реальностью.

Если ресурсов на два отдельных сервера пока нет, разумный порядок внедрения — сначала LibreNMS (даёт видимость проблем здесь и сейчас), а NetBox подключать, когда количество устройств и подсетей уже не помещается в голове одного инженера. Сколько именно RAM закладывать под LibreNMS при росте числа опрашиваемых портов — отдельный вопрос, разобранный в статье сколько RAM нужно для LibreNMS.

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