OpenNMS: мониторинг больших сетей

OpenNMS — платформа мониторинга сетей, которая развивается как открытый проект и используется там, где Zabbix или LibreNMS уже не хватает: в крупных филиальных сетях и дата-центрах с тысячами интерфейсов. Её сильные стороны — модель предметной области, ориентированная на сеть, а не на отдельные серверы, мощный провижининг, обработка потоков NetFlow и IPFIX, горизонтальное масштабирование через Minion и Sentinel. Разберём установку, настройку SNMP, опрос, пороги и диагностику.

Две редакции и позиционирование

Проект выходит в двух вариантах. Horizon — открытая версия с быстрым циклом выпусков, в ней первыми появляются новые возможности. Meridian — коммерческая подписка на стабильную ветку с длительной поддержкой и исправлениями безопасности; код при этом остаётся открытым. Для промышленной эксплуатации чаще выбирают Meridian.

OpenNMS по умолчанию работает без агентов: опрашивает устройства по SNMP, ICMP и HTTP.

• SNMP v1, v2c и v3, включая контексты и шифрование.
• Опрос доступности, интерфейсов, дисков, температуры, питания.
• Провижининг из XML, CSV и внешних источников.
• События, аварии, пороги и уведомления.
• Потоки NetFlow v5 и v9, IPFIX, sFlow через Sentinel.
• Карты топологии по LLDP, CDP, OSPF и BGP.

Архитектура

Ядро — Java-приложение, которое запускается как служба opennms. Демоны делят работу: provisiond ведёт инвентаризацию, pollerd опрашивает, collectd собирает метрики, eventd и alarmd обрабатывают события, notifd шлёт уведомления. Конфигурация лежит в /opt/opennms/etc, логи — в /opt/opennms/logs.

Данные хранятся в PostgreSQL. Метрики в актуальных ветках Horizon пишутся туда же с расширением TimescaleDB: это даёт сжатие и политики хранения без отдельной Cassandra.

Для распределённых сетей есть два дополнения. Minion ставится на удалённой площадке, выполняет опрос и отправляет результаты в ядро, что снимает нагрузку с канала и позволяет мониторить сети за NAT. Sentinel обрабатывает потоки и разгружает ядро при больших объёмах телеметрии.

Установка

Нужны JDK 17 и PostgreSQL. На RHEL-совместимых системах подключают репозиторий проекта, на Debian и Ubuntu — пакет из репозитория OpenNMS. Быстрый вариант для теста — Docker Compose с образами horizon и postgres.

sudo dnf install opennms
sudo /opt/opennms/bin/install -dis
sudo systemctl enable --now opennms

Скрипт install -dis создаёт схему базы, применяет миграции и разворачивает конфигурацию; его же запускают после обновления. Веб-интерфейс поднимается на порту 8980, вход по умолчанию admin/admin — смените пароль сразу после первого входа. Консоль Karaf доступна по SSH на порту 8101, туда тоже стоит поставить свой пароль.

systemctl status opennms
ss -tlnp | grep -E '8980|8101'
tail -f /opt/opennms/logs/manager.log

SNMP и первичная настройка

Учётные данные SNMP задаются в snmp-config.xml. Для коммутаторов и маршрутизаторов используйте v3 с authPriv: v2c передаёт community открытым текстом и давно считается компромиссом. В файле задаются диапазоны адресов и профили, чтобы не дублировать настройки.

<snmp-config version="v3">
  <definition version="v3" security-name="monitor"
    auth-passphrase="..." auth-protocol="SHA"
    privacy-passphrase="..." privacy-protocol="AES">
    <range begin="192.0.2.0" end="192.0.2.255"/>
  </definition>
</snmp-config>

До настройки ядра проверьте доступность утилитой snmpwalk из пакета net-snmp: если она молчит, OpenNMS тоже не увидит устройство.

Обнаружение и провижининг

Автообнаружение включается в discovery-configuration.xml: указываются диапазоны include-range и исключения exclude-range. Найденные узлы попадают в базу, но для управляемого парка надёжнее провижининг: XML-файл с описанием узлов и интерфейсов кладётся в etc/imports, после чего импортируется командой в Karaf.

ssh -p 8101 admin@localhost
provision:import datacenter
snmp:walk 192.0.2.10 1.3.6.1.2.1.1

Провижининг идемпотентен: повторный импорт обновляет существующие узлы и не создаёт дубликаты, если указан стабильный foreign-id. Не берите в качестве идентификатора IP-адрес: он меняется.

Опрос, пороги и события

Набор опрашиваемых сервисов задаётся в poller-configuration.xml, сбор метрик — в datacollection-config.xml. По умолчанию включено много лишнего; для больших сетей набор сокращают, иначе устройства получают нагрузку без пользы.

Пороги описываются в thresholds.xml: дата-источник, условие, значение срабатывания и порог возврата. Событие порога можно превратить в аварию и отправить уведомление через notifd. Настройка уведомлений состоит из трёх частей: destinations (куда), destinationPaths (кому) и notifd-configuration (когда).

<threshold type="low" ds-name="memTotalFree"
  value="102400" rearm="204800" trigger="2"/>

Порог срабатывает при свободной памяти ниже 100 МБ и снимается выше 200 МБ. Без дедупликации и подавления ящик дежурного превращается в свалку за сутки.

Масштабирование

Нагрузка растёт вместе с числом интерфейсов. Сначала вынесите PostgreSQL на отдельный сервер и настройте TimescaleDB: сжатие старых чанков и политика удаления заметно сокращают объём. Затем добавьте Minion на удалённых площадках и Sentinel для потоков.

Размер кучи JVM задаётся в etc/opennms.conf. Не давайте ядру больше половины памяти сервера: PostgreSQL на той же машине тоже нуждается в буферах. При тысячах узлов проверяйте время цикла опроса — если collectd не успевает, интервалы растягиваются и графики становятся рваными.

Диагностика

• Узел есть, но метрик нет — проверьте SNMP с самой машины OpenNMS и категорию узла: сбор идёт только для известных категорий.
• Интерфейс «down» при живом линке — сверьте ifAdminStatus и ifOperStatus, а также фильтры опроса.
• Аварии не приходят — смотрите notifd.log и проверьте, что событие дошло до alarmd.
• Веб-интерфейс не открывается — проверьте порт 8980 и место на диске: при переполнении PostgreSQL ядро стартует, но UI отдаёт ошибку.
• После обновления пустая страница — запустите install -dis и перезапустите службу.

Команда opennms -v status показывает версию и состояние, journalctl -u opennms -n 100 — последние сообщения службы.

Чек-лист внедрения

• Сменить пароли admin в веб-интерфейсе и Karaf.
• Настроить SNMP v3 и проверить его через snmpwalk.
• Завести провижининг с постоянными foreign-id.
• Сократить набор опрашиваемых сервисов и метрик.
• Настроить пороги с разумным rearm.
• Проверить уведомления на тестовом событии.
• Настроить бэкап PostgreSQL и каталога etc.

Итог

OpenNMS — тяжёлая, но честная платформа для сетей, где важны инвентаризация, топология и потоки, а не только графики загрузки процессора. Начните с одного сервера и десятка устройств, настройте SNMP v3 и провижининг, затем добавляйте Minion и Sentinel по мере роста. Главное — не тащить в продакшен настройки по умолчанию: они рассчитаны на демонстрацию, а не на тысячу коммутаторов.