LibreNMS на сервере: частые ошибки и решения

MAATRIX

LibreNMS — форк Observium с открытой разработкой, автообнаружением сети и мониторингом по SNMP, но после установки почти всегда возникает одна из типовых проблем: устройство не добавляется, поллер молчит, графики пустые или веб-интерфейс падает с 500-й ошибкой. Разберём частые ошибки LibreNMS на сервере по шагам — с командами для диагностики и конкретными причинами, а не общими советами «перезагрузите». Если вы ещё выбираете между инструментами мониторинга, полезно заодно свериться со статьёй Netdata или Zabbix: что выбрать для сервера — логика выбора для LibreNMS во многом похожа.

validate.php ругается на права и зависимости

Первым делом после установки и после каждого крупного обновления стоит прогнать встроенную проверку окружения:

cd /opt/librenms
su - librenms -c './validate.php'

В новых версиях команда доступна короче через обёртку lnms:

lnms validate

Скрипт проверяет PHP-модули (mbstring, gd, mysqli, snmp, gmp, curl), права на директории, наличие cron-задания, состояние миграций базы и версию Python для poller-wrapper. Частые находки:

• Права на rrd/, logs/, storage/, bootstrap/cache/ не те. Все эти каталоги должны принадлежать пользователю, от которого крутится LibreNMS (обычно librenms), а storage/ и bootstrap/cache/ — ещё и быть доступны на запись веб-серверу. Чинится так:

chown -R librenms:librenms /opt/librenms
setfacl -R -m u:librenms:rwx -m u:www-data:rwx /opt/librenms/rrd /opt/librenms/logs /opt/librenms/storage /opt/librenms/bootstrap/cache
setfacl -d -m u:librenms:rwx -m u:www-data:rwx /opt/librenms/rrd /opt/librenms/logs /opt/librenms/storage /opt/librenms/bootstrap/cache

• «Not all Cron Entries Installed». Значит файл /etc/cron.d/librenms не скопирован из репозитория или потерялся при апдейте. Скопируйте его заново из /opt/librenms/dist/librenms.cron (или аналогичного файла в вашей версии) и перезапустите cron.
• Незалитые миграции базы после git pull — выполните php artisan migrate --force из директории /opt/librenms от имени пользователя librenms.

Не пропускайте предупреждения validate.php ради «потом разберусь» — большинство проблем из следующих разделов сводятся именно к тому, что здесь было пропущено. Похожая логика диагностики «сначала проверь права и cron, потом всё остальное» работает и в других системах мониторинга — например, в Zabbix на сервере: частые ошибки и решения разобраны те же классы проблем на другом стеке.

SNMP: устройство не обнаруживается автоматически

Самая частая жалоба — «добавляю хост, а LibreNMS пишет, что SNMP недоступен». Прежде чем трогать настройки самого LibreNMS, проверьте SNMP напрямую с сервера мониторинга:

snmpwalk -v2c -c ваша_community -O e IP_УСТРОЙСТВА system

Если команда зависает или отвечает таймаутом — проблема не в LibreNMS, а в сети или в самом устройстве:

• Firewall блокирует UDP/161. На стороне устройства откройте порт именно с IP сервера мониторинга: ufw allow from IP_LIBRENMS to any port 161 proto udp.
• snmpd слушает только localhost. В /etc/snmp/snmpd.conf строка agentAddress должна включать внешний интерфейс, например agentAddress udp:161,udp6:[::1]:161, а не только 127.0.0.1.
• Не совпадает версия или community. LibreNMS по умолчанию пробует community из глобальных настроек (Settings → SNMP), но если на устройстве стоит своя строка — укажите её явно при добавлении хоста.

Добавление хоста с явными параметрами SNMP через CLI удобнее веб-формы, когда нужно быстро перебрать варианты:

lnms device:add HOSTNAME_ИЛИ_IP --v2c -c ваша_community
# или SNMPv3
lnms device:add HOSTNAME_ИЛИ_IP --v3 -U user -A authpass -X privpass -a SHA -x AES

Ещё одна ловушка — LibreNMS по умолчанию сначала пингует устройство перед добавлением. Если ICMP на устройстве заблокирован, а SNMP работает нормально, добавление падает с ошибкой доступности до того, как вообще дойдёт до SNMP-проверки. В настройках устройства или флагах добавления можно отключить обязательный ping-check — тогда LibreNMS сразу пробует SNMP, не оглядываясь на ICMP.

Поллер не обновляет данные

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

cd /opt/librenms
./poller.php -h HOSTNAME -d

Вывод покажет, на каком именно модуле (SNMP-запрос, парсинг данных, запись в RRD) всё останавливается. Если ручной запуск отрабатывает нормально, а по расписанию данные не идут — смотрите в сторону cron:

• Убедитесь, что cron вообще работает: systemctl status cron (или crond на RHEL-подобных).
• Проверьте, что задания реально выполняются, а не тихо падают: grep librenms /var/log/syslog или journalctl -u cron.
• Поллер не успевает за интервалом. Если опрос одного цикла устройств занимает больше 5 минут, а следующий запуск уже стартует поверх, начинаются блокировки и пропуски. Смотрите время выполнения в логах /opt/librenms/logs/poller.log — если оно растёт вместе с числом устройств, пора переходить на распределённый поллинг (несколько воркеров poller-wrapper.py с разным числом процессов) или добавлять ресурсы серверу.
• Устаревшие блокировки в базе. Если поллер аварийно завершился (например, сервер перезагрузили посреди опроса), в таблице блокировок могут остаться «зависшие» записи, из-за которых новый цикл считает устройство уже занятым и пропускает его. Раздел Poller → Poller Log в веб-интерфейсе покажет, какие хосты реально опрашивались в последних циклах, а какие — нет.

Отдельно проверьте лимиты PHP: max_execution_time и memory_limit в php.ini для CLI (не для php-fpm — поллер запускается из консоли отдельным SAPI). На крупных сетях штатных значений часто не хватает, и процесс поллера обрывается по таймауту без внятной ошибки в веб-интерфейсе.

Пустые или битые RRD-графики

Устройство опрашивается, поллер отрабатывает без ошибок, но график показывает «No Data» или обрывается посередине. Первым делом проверьте сам RRD-файл напрямую:

rrdtool info /opt/librenms/rrd/HOSTNAME/номер_порта.rrd

Если файла нет вообще — поллер не доходит до записи, смотрите раздел выше. Если файл есть, но rrdtool info выдаёт ошибку доступа — это права:

chown -R librenms:librenms /opt/librenms/rrd
find /opt/librenms/rrd -type d -exec chmod 775 {} \;

Частая причина именно «прерванных» графиков — использован rrdcached, но демон не запущен или недоступен по сокету. Если в конфиге включена запись через rrdcached, а сам процесс rrdcached не поднят (systemctl status rrdcached), запросы на запись копятся в очереди и теряются молча, без явной ошибки в интерфейсе. Отключите rrdcached в настройках, если не готовы его администрировать отдельно, — прямая запись в RRD-файлы медленнее при большом числе устройств, но надёжнее для старта.

Ещё одна практическая деталь: место на диске под rrd/ растёт линейно с числом устройств и портов и может неожиданно кончиться на маленьком тарифе. Проверяйте регулярно:

df -h /opt/librenms/rrd
du -sh /opt/librenms/rrd/* | sort -rh | head -20

Если графики резко «обрываются» после переноса на новый сервер — проверьте, что версия rrdtool не старше той, на которой создавались файлы: старые бинарники иногда не читают файлы, созданные новыми версиями формата.

Веб-интерфейс: 500-я ошибка и белый экран

Когда интерфейс падает целиком, первый источник правды — логи, а не догадки:

tail -n 50 /opt/librenms/logs/librenms.log
tail -n 50 /var/log/nginx/error.log
tail -n 50 /var/log/php8.2-fpm.log

Частые причины:

• Не сгенерирован APP_KEY после свежей установки или копирования .env со старого сервера без ключа — Laravel (на котором построен веб-слой LibreNMS) откажется работать. Сгенерируйте новый: php artisan key:generate.
• storage/ или bootstrap/cache/ недоступны на запись веб-серверу — та же проблема прав, что и в первом разделе, но теперь она валит не консольный validate.php, а именно веб-запросы.
• Кэш конфигурации устарел после правки .env — Laravel кэширует конфиг, и правки не подхватываются, пока не сбросить кэш:

php artisan config:clear
php artisan cache:clear

• База данных недоступна — проверьте параметры подключения в .env (DB_HOST, DB_DATABASE, DB_USERNAME, DB_PASSWORD) и что MariaDB/MySQL вообще запущена.

После обновления LibreNMS через ./daily.sh или git pull обязательно прогоняйте php artisan migrate --force — забытые миграции чаще всего и дают белый экран сразу после апдейта, а не сразу после установки.

Алерты не приходят

Правило создано, транспорт настроен, но уведомления не приходят ни в Telegram, ни на почту. Проверяйте по цепочке:

1. Транспорт вообще работает? В разделе Alerting → Alert Transports у каждого транспорта есть кнопка теста — используйте её в первую очередь, это отсекает половину случаев за секунду.
2. Правило действительно применяется к устройству? В Alert Rules посмотрите, к каким группам устройств привязано правило (Device Groups или конкретные хосты) — частая ошибка новичков в том, что группа задана слишком узко и реальное устройство в неё не попадает.
3. Поллер вообще работает? Проверка алертов завязана на цикл опроса — если поллер стоит (раздел выше), алерты по определению не сработают, потому что новых данных для оценки условия просто нет.
4. Устройство не в режиме обслуживания. В LibreNMS есть maintenance mode — если он случайно включён на устройстве или группе, алерты по нему подавляются намеренно, и это легко забыть выключить после плановых работ.

Для email-транспорта отдельно проверьте настройки SMTP в Settings → Alerting → Transports → Mail и убедитесь, что исходящий 587/465 порт не блокируется провайдером или firewall — на некоторых VPS исходящий SMTP на сторонние сервисы закрыт по умолчанию из-за антиспам-политики, и это выглядит как «алерты не приходят», хотя LibreNMS отправляет их корректно.

Если помимо сети нужно ещё и отслеживать состояние самого «железа» серверов, посмотрите отдельно мониторинг здоровья железа — LibreNMS хорошо дополняет такой контроль, но не заменяет его: SNMP на сетевом оборудовании и датчики температуры/дисков на сервере — разные задачи.

Для стабильного мониторинга сети важна не только правильная настройка LibreNMS, но и сервер под ним — с достаточным диском под RRD-архив и стабильной сетью до опрашиваемых устройств. У MAATRIX сервер поднимается за пару минут, с оплатой картой РФ, СБП или криптой, без иностранной карты — держать LibreNMS рядом с сетью, которую он мониторит, часто важнее, чем экономить на конфигурации.

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