Сколько RAM нужно для Observium

MAATRIX

Observium привлекает именно автообнаружением: указали SNMP-community и диапазон подсетей — и система сама находит соседей по CDP/LLDP/FDP, строит топологию и начинает копить графики по портам, температуре, загрузке CPU. На демостенде из десятка устройств всё летает даже на 1 ГБ. Проблема вылезает через пару месяцев, когда список устройств вырос до полусотни, discovery стал занимать не пять минут, а двадцать, а сервер начал подтормаживать в моменты пересечения опроса и веб-сессий. Разберём, куда реально уходит память в Observium, чем это отличается от похожих систем вроде LibreNMS и Zabbix, и как посчитать запас заранее.

Из чего складывается потребление памяти

Observium — классический LAMP-стек, заточенный под SNMP-мониторинг, и память нужно закладывать под каждый компонент отдельно:

• Веб-сервер + PHP-FPM (или mod_php) — обслуживает дашборды, графики, API. Каждый воркер держит 25-70 МБ в зависимости от того, сколько людей одновременно смотрят страницы устройств с живыми графиками.
• MySQL/MariaDB — хранит устройства, порты, сенсоры, историю алертов и справочники OID. Не хранит сами временные ряды (это делает RRDtool), но при росте числа портов таблицы ports, ports_statistics и syslog (если включён) растут заметно, а вместе с ними — аппетит innodb_buffer_pool_size.
• discovery.php — периодический (обычно раз в сутки-двое через cron) обход сети: SNMP-walk по новым OID, определение типа устройства, поиск соседей. Кратковременно, но заметно прожорливее обычного поллинга — именно discovery чаще всего выявляет нехватку памяти первым.
• poller.php — регулярный опрос уже известных устройств (по умолчанию раз в 5 минут через cron). В базовой конфигурации Observium запускает опрос устройств последовательно одним процессом; при росте парка устройств администраторы обычно оборачивают вызов в xargs -P для параллельного запуска, и тогда одновременно в памяти живёт не один PHP-процесс, а столько, сколько указано в параллелизме.
• RRDtool — записывает результаты опроса в файлы .rrd, по одному на каждый график каждого порта/сенсора. У Observium нет альтернативного бэкенда для хранения метрик — в отличие от той же LibreNMS с опциональной InfluxDB, здесь всегда RRD-файлы на диске, и они же активно съедают страничный кэш ОС.
• SNMP-библиотека — php-snmp или net-snmp бинарники, вызываемые из PHP. При большом числе OID на устройство (например, все интерфейсы core-свитча на 96 портов) один такой вызов может подвиснуть на плохом канале и держать процесс в памяти дольше ожидаемого.

Итого RAM для Observium — это не «вес самого приложения» (он невелик), а сумма пиков PHP, MySQL и дисковой активности RRDtool, которые конкурируют за одну и ту же память сервера в момент одновременного опроса и открытых дашбордов.

Сколько RAM нужно в зависимости от числа устройств

Официальных таблиц с гарантированными цифрами разработчики Observium не публикуют — слишком много зависит от количества портов на устройство, включённых модулей (sensors, wireless, BGP-соседи) и интервала опроса. Ниже — ориентир по практике эксплуатации небольших и средних инсталляций, не гарантия; на вашем железе цифры могут отличаться на 20-30% в любую сторону:

Таблица считает «типовое» сетевое устройство на 10-40 портов с интервалом опроса 300 секунд по умолчанию. Если у вас плотные core-свитчи на 48-96 портов, включены сенсоры температуры/питания на каждом или вы опрашиваете чаще (120 секунд), закладывайте следующую строку уже при вдвое меньшем количестве устройств — узкое место в Observium растёт не по числу узлов, а по числу опрашиваемых OID за цикл.

Community vs Professional/Enterprise — где расход памяти отличается

Это важная развилка именно для Observium, и она напрямую влияет на архитектуру, а не только на функциональность. Бесплатная Community-версия (SVN-снапшот) — однопроцессная в плане поллинга «из коробки»: все устройства опрашивает один сервер, и вся память под опрос концентрируется на одной машине. Платные Professional и Enterprise добавляют официально поддерживаемый distributed poller — несколько узлов-поллеров, каждый берёт свой кусок устройств и шлёт результат на центральный сервер с MySQL и веб-интерфейсом.

Практическое следствие для расчёта RAM:

• На Community при росте парка устройств вы масштабируете вертикально — один сервер становится всё толще по RAM/CPU, потому что распределить нагрузку штатно некуда.
• На Professional/Enterprise от нескольких сотен устройств выгоднее масштабироваться горизонтально: центральный сервер под БД/веб (8-16 ГБ) плюс 2-3 poller-ноды по 2-4 ГБ каждая, размещённые ближе к опрашиваемым сегментам сети — это заодно снижает задержки SNMP через VPN-туннели до удалённых площадок.
• Community-версия также не даёт части оптимизаций хранения (RRDCacheD из коробки настроен слабее), поэтому дисковая нагрузка на memory-competing page cache выше при том же числе устройств по сравнению с коммерческими редакциями.

Если вы на старте не уверены, какая редакция подойдёт — начинайте с Community на VPS среднего тарифа: миграция на Professional меняет только лицензионный ключ и метод обновления (git вместо SVN), архитектура сервера остаётся той же.

MySQL/MariaDB — тюнинг под Observium

СУБД в Observium легче, чем в LibreNMS (нет временных рядов в таблицах), но всё равно остаётся вторым по прожорливости компонентом после пиков поллера. Дефолтные настройки MariaDB рассчитаны на универсальный случай и не годятся для схемы с частыми UPDATE по таблицам портов.

Минимальный набор правок в /etc/mysql/mariadb.conf.d/50-server.cnf:

[mysqld]
innodb_buffer_pool_size = 1G          # 40-50% от RAM, выделенной под MySQL
innodb_buffer_pool_instances = 1
innodb_flush_log_at_trx_commit = 2    # компромисс скорость/надёжность для метрик
innodb_file_per_table = 1
innodb_io_capacity = 800              # выше на NVMe, ниже на HDD/сетевых дисках
max_connections = 40

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

mysql -e "SELECT table_schema AS db, ROUND(SUM(data_length+index_length)/1024/1024,1) AS size_mb FROM information_schema.tables WHERE table_schema='observium' GROUP BY table_schema;"

Если размер данных меньше выделенного буфера — это нормально до определённого предела (запас на рост), но закладывать буфер вдвое больше текущей БД без плана роста парка не стоит. От 150-200 устройств, где веб, поллер и MySQL живут на одном сервере, конкуренция за память между СУБД и RRDtool становится заметной уже в htop — тогда имеет смысл вынести MySQL на отдельный сервер, тем более что схема Observium позволяет это через простой config.php без переустановки. Похожий разбор конкуренции компонентов за память — в статье про расчёт RAM для LibreNMS, хотя веса компонентов там иные.

RRDtool и поллер: последовательный или параллельный опрос

Это специфика именно Observium, которую стоит понимать до выбора тарифа. В отличие от LibreNMS, у Observium нет опции переключиться на InfluxDB или Prometheus — временные ряды всегда пишутся в файлы .rrd, по одному на каждый график каждого порта и сенсора. На сети из пары сотен устройств с активными портами это легко тысячи мелких файлов, в которые нужно писать каждые 5 минут.

Последствия для памяти двоякие:

• Сами по себе вызовы rrdtool update лёгкие по RAM, но при большом числе файлов ОС агрессивно кэширует их в page cache, отбирая память у MySQL — на графике free -h это видно как рост buff/cache при падающем available.
• Базовый poller.php из cron опрашивает устройства последовательно одним процессом — предсказуемо по памяти, но на сотнях устройств цикл может не укладываться в 5-минутный интервал. Стандартное решение — обёртка с параллелизмом:

#!/bin/bash
cd /opt/observium
./discovery.php -h all >> logs/discovery.log 2>&1
./poller-wrapper.py -d 0 -r 16 >> logs/poller.log 2>&1

(в старой схеме без poller-wrapper.py параллелизм собирают через xargs -P по списку хостов). Каждый параллельный процесс — это отдельный PHP + SNMP-вызов, и при 16 параллельных поллерах пиковое потребление памяти в момент опроса может быть в разы выше «тихого» состояния между циклами. Именно этот пик, а не среднее потребление, определяет минимальный объём RAM — расчёт по средней загрузке почти всегда занижает требования.

Держите каталог rrd/ на отдельном быстром томе (SSD/NVMe), не на системном разделе — при нехватке IOPS деградация проявляется сначала как рост iowait, а через него — как рост давления на память из-за разбухшего page cache.

Признаки нехватки памяти и как их поймать

Не гадайте по ощущениям — снимайте показания. Базовый набор команд на первую-вторую неделю после запуска:

free -h                              # следите за available, не free
vmstat 5 5                           # si/so — если не нули, сервер уже свопится
mysqladmin status                    # Threads_running растёт — очередь к БД
htop                                 # какой процесс реально ест RAM в моменте опроса

Тревожные сигналы, что текущего объёма недостаточно:

• si/so в vmstat устойчиво больше нуля во время цикла поллера — это уже деградация, не запас прочности.
• Время выполнения poller-wrapper.py (видно в logs/poller.log по timestamp) регулярно приближается к длине интервала опроса или превышает её — цикл не успевает завершиться до следующего запуска.
• discovery.php растягивается на часы вместо минут при добавлении новых устройств — часто симптом не CPU, а нехватки памяти под параллельные SNMP-запросы.
• Веб-интерфейс подвисает именно в момент запуска poller/discovery по cron, а не постоянно — классический признак конкуренции за память между веб-воркерами и поллером.

Если один из этих признаков проявляется при формально «достаточном» по таблице объёме RAM — сначала проверьте innodb_buffer_pool_size и степень параллелизма поллера, и только потом увеличивайте сервер. Часто узкое место не в общем объёме памяти, а в том, что поллер и MySQL пытаются использовать её одновременно в одну и ту же минуту. Общие подходы к такой диагностике пересекаются с материалом про мониторинг диска на VPS — стоит сразу настроить алерт по свободному месту и I/O под каталог rrd/, чтобы не ловить проблему постфактум. Если ещё выбираете между Observium и альтернативами, полезно сравнение подходов в статье Zabbix против Prometheus — там разбирается похожая дилемма архитектуры мониторинга.

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