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

MAATRIX

Observium — один из самых старых и живучих инструментов мониторинга сети: автообнаружение устройств по SNMP, готовые графики для сотен вендоров из коробки, минимум ручной настройки шаблонов. Но именно из-за автоматизма он же чаще всего и ломается непредсказуемо — один неверный community string или забытый cron, и вместо карты сети вы получаете пустые графики и молчащий поллер. Ниже — конкретные ошибки, с которыми реально сталкиваются при установке и эксплуатации Observium, и как их закрывать без пересборки всего с нуля.

Установка: на чём спотыкаются в первые полчаса

Observium Community Edition ставится не из пакета, а клонированием git-репозитория, и большинство первых ошибок — это несовпадение версий стека под требования проекта.

Минимальный набор для сервера на Debian 12 / Ubuntu 24.04:

apt update && apt install -y php-cli php-mysql php-gd php-json php-snmp \
  php-curl php-zip php-mbstring php-xml mariadb-server rrdtool \
  snmp fping mtr-tiny nmap ipmitool graphviz imagemagick whois curl git

Частая ошибка на этом шаге — PHP Fatal error: Uncaught Error: Call to undefined function mysqli_connect() при попытке открыть веб-интерфейс. Причина в том, что модуль php-mysql (он же php-mysqli) не подтянулся вместе с нужной версией PHP, особенно если на сервере уже стоял другой PHP из стороннего репозитория. Проверяется одной командой:

php -m | grep -iE 'mysqli|snmp|gd'

Если модулей нет — не переустанавливайте PHP целиком, а доустановите пакет под конкретную версию (php8.2-mysqli и т.д.) и перезапустите php-fpm.

Вторая типичная грабля — конфликт версии MariaDB и strict mode. Свежий сервер после apt install mariadb-server по умолчанию включает STRICT_TRANS_TABLES, а Observium ожидает более мягкий режим при первичном импорте схемы sql-schema/. Симптом — установка обрывается на середине с ошибками Data truncated for column. Решение — на время первичного php includes/update/update.php временно убрать STRICT_TRANS_TABLES из sql_mode в /etc/mysql/mariadb.conf.d/50-server.cnf, накатить схему, затем вернуть строгий режим обратно.

Третья вещь, о которую спотыкаются на новых образах — несовпадение версии PHP с тем, что реально поддерживает актуальная ветка Observium. Проект довольно консервативен к слишком свежим релизам PHP (баги в некоторых расширениях всплывают именно на новых мажорных версиях раньше, чем их успевают протестировать мейнтейнеры). Если после установки в логе php-fpm видны предупреждения об устаревших конструкциях или Deprecated вперемешку с реальными ошибками — не пытайтесь чинить код Observium под новый PHP, а поставьте вместе с системным PHP более старую совместимую версию через sury.org или аналогичный репозиторий и переключите на неё php-fpm pool именно для Observium, не трогая остальные сайты на сервере.

SNMP-автообнаружение не находит устройства

Это самая частая жалоба: устройство добавлено через ./addhost.php, но ./discovery.php -h all не подтягивает ни интерфейсы, ни сенсоры.

Порядок диагностики, который экономит время:

1. Проверить сырой SNMP-доступ в обход Observium:

snmpwalk -v2c -c public 192.168.1.1 system

Если ответа нет — проблема не в Observium, а в сети или в конфиге агента на устройстве (не тот community string, ACL на SNMP, фильтрация UDP/161 на файрволе между сервером и устройством).

1. Проверить, каким протоколом реально опрашивается хост:

./discovery.php -h 192.168.1.1 -m os,ports -d

Флаг -d включает debug-вывод и почти всегда показывает точную причину: неверная версия SNMP (v1 vs v2c vs v3), таймаут, либо MIB, который устройство не отдаёт.

1. Если устройство отвечает, но не определяется тип ОС — Observium не нашёл совпадения по sysObjectID в своей базе includes/definitions/. Для белых пятен (нестандартные вендоры, кастомные прошивки) устройство добавится как generic-хост с базовыми метриками, это ожидаемое поведение, а не баг.

Отдельно стоит SNMPv3: если используете его, ошибки чаще всего в паре authProtocol/privProtocol — Observium должен быть собран с поддержкой нужных алгоритмов на стороне Net-SNMP. Проверка:

snmpwalk -v3 -u observuser -l authPriv -a SHA -A 'authpass' -x AES -X 'privpass' 192.168.1.1 system

Если эта команда работает напрямую, а через Observium — нет, сверьте точное совпадение регистра и длины паролей в веб-интерфейсе (Devices → Edit → SNMP) с тем, что задано на устройстве.

Отдельно стоит сказать про MTU и фрагментацию SNMP-ответов: устройства с большим числом интерфейсов (например, стек коммутаторов на 48+ портов) иногда отдают ответ по ifTable, который не помещается в один UDP-пакет при дефолтных настройках. Симптом — часть интерфейсов видна, часть пропадает без видимой причины, а snmpwalk с -t 5 -r 3 (увеличенный таймаут и число повторов) внезапно всё показывает. Если сталкиваетесь с этим регулярно, увеличьте таймаут SNMP-опроса конкретно для проблемного хоста через $config['snmp']['exec_timeout'] или локально в настройках устройства, а не для всего парка сразу — иначе один медленный коммутатор растянет цикл поллинга всем остальным.

Поллер молчит: "did not update database" и зависшие процессы

Симптом знаком многим: графики есть, но данные не обновляются последние несколько часов. В логе /opt/observium/logs/poller.log часто встречается:

Poller finished for 192.168.1.1 in 340.13 secs (unfinished)

Это значит поллер упёрся в таймаут по конкретному хосту, и весь цикл опроса растянулся. Причины обычно две: недоступное устройство, которое не убрали из мониторинга (Observium ждёт таймаут SNMP по каждому модулю), либо слишком большое число интерфейсов на одном хосте при опросе через один тред.

Проверка, что cron вообще запускает поллер:

crontab -u observium -l | grep poller

Должна быть строка вида:

*/5 * * * * /opt/observium/poller-wrapper.py >> /dev/null 2>&1

Если cron есть, а данные всё равно не идут — смотрите на лок-файлы в /opt/observium/rrd/ и в самой БД (таблица pollers), которые могли зависнуть после аварийного обрыва предыдущего опроса. Ручной прогон с диагностикой одного хоста:

./poller.php -h 192.168.1.1 -d 2>&1 | tail -100

Часто там сразу видна причина — от Could not connect to database (обрыв сокета MySQL после рестарта сервиса) до конкретной ошибки конкретного модуля (storage, hr-mib и т.п.), который можно временно отключить в config.php:

$config['poller_modules']['storage'] = 0;

Пустые графики и "No data available"

Устройство опрашивается, поллер отрабатывает без ошибок, а графики показывают пустоту. Здесь три частые причины.

RRD-файлы не создаются из-за прав. Observium должен иметь право на запись в /opt/observium/rrd/<hostname>/. Если каталог создавался вручную или копировался с другого сервера, владелец может остаться root:

chown -R observium:observium /opt/observium/rrd

rrdtool не найден или несовместимая версия. Observium вызывает бинарник rrdtool напрямую через exec(), и если путь в config.php ($config['rrdtool']) не совпадает с реальным расположением — графики просто не строятся молча, без явной ошибки в интерфейсе. Проверка: which rrdtool и сверка с конфигом.

PHP-GD не поддерживает нужный формат. Для отрисовки PNG-графиков модуль php-gd обязателен; без него бэкенд рендеринга падает тихо, и вместо графика в браузере виден битый значок изображения. php -m | grep gd решает вопрос за секунду.

Если это виртуальный сервер, где диск и так под нагрузкой от других сервисов, стоит проверить и общую скорость дисковой подсистемы — RRD активно пишет мелкими блоками, и на медленном сетевом хранилище поллер может тормозить именно на этом этапе, а не на самом SNMP-опросе.

Производительность: поллер не успевает за интервалом

Когда устройств становится больше полусотни, стандартный 5-минутный интервал поллинга начинает не укладываться в себя же — новый цикл стартует раньше, чем закончился предыдущий. Симптом в логах — растущее число (unfinished) записей и накопление "хвостов" процессов poller.php в выводе ps aux | grep poller.

Что реально помогает:

Distributed polling — штатная возможность Observium: несколько поллеров могут опрашивать разные группы устройств параллельно, каждый со своим циклом cron, что снимает проблему единого узкого места на крупных инсталляциях (сотни устройств).

Если мониторинг растёт, а текущий VPS уже упирается в CPU или диск при каждом цикле поллинга — это тот случай, когда проще отдельно вынести Observium на выделенный сервер с NVMe и не делить ресурсы с продакшн-сервисами.

Доступ, права и веб-интерфейс

Часть ошибок связана не с самим мониторингом, а с тем, как Observium отдаётся через веб-сервер.

"403 Forbidden" или белый экран на /. Чаще всего — неверный DocumentRoot, который должен указывать не на корень репозитория, а на подпапку html/:

root /opt/observium/html;

Если указать корень /opt/observium, веб-сервер откроет исходники и конфиги вместо интерфейса, а часть путей вообще не будет резолвиться.

PHP-FPM не подключён к nginx. Классическая ошибка для тех, кто переносит конфиг с Apache: не прописан fastcgi_pass на правильный сокет php-fpm. Проверка сокета:

ls -la /run/php/

Логин не проходит после установки. По умолчанию первый пользователь создаётся вручную через CLI:

./adduser.php admin 'strongpassword' 10

Последняя цифра — уровень доступа (10 = администратор). Если пароль "не подходит" сразу после установки — велика вероятность, что пользователь вообще не был создан этой командой, а веб-форма логина ожидает уже существующую запись в таблице users.

Учтите и внешний периметр: если веб-панель Observium смотрит наружу без ограничения по IP или VPN, это отдельный риск — community-версия не получает такого частого потока security-патчей, как коммерческие SIEM-решения, так что закрывать интерфейс хотя бы базовым allow/deny в nginx или туннелем стоит по умолчанию, а не «когда-нибудь потом».

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