Привет Хабр!

13 августа 2025 года вышел новый релиз OpenNMS Horizon (открытой системы мониторинга сетей и сервисов, NMS). Версия 34.0.0 стала первым крупным обновлением в ветке 34.x.

Не буду пересказывать все технические детали, с ними всегда можно ознакомиться на сайте проекта. Важно другое, OpenNMS распространяется под лицензией AGPLv3 и является полностью open source. Помимо этого, существует продукт OpenNMS Meridian, подписочная услуга с коммерческими планами, поддержкой и SLA. Однако, с учётом текущей ситуации, в России коммерческая версия вряд ли доступна.

Почему же тогда стоит говорить об OpenNMS?
Несмотря на ограниченную доступность, проект остаётся перспективным и отражает новые тренды в области мониторинга сетей. Да, он менее известен, чем Zabbix или Prometheus, но это вполне жизнеспособный open-source инструмент.

В этой статье я покажу его работу на практике и проведу несколько простых экспериментов.

И вот так выглядит консоль сразу после установки.

Чтобы лучше познакомиться с этим продуктом, я сделал небольшую симуляцию корпоративной сети: два компьютера (нашлись только старенькие на Windows XP), виртуальная машина, роутер и мой ноутбук.

После добавления всех компонентов и их настройки, они появились на главном экране консоли. OpenNMS Horizon сразу начал собирать метрики: ICMP, SNMP и другие.

Первым тестом стало отключение одного из XP-компьютеров, система моментально подсветила событие красным и выдала уведомление о недоступности узла.

Вторым этапом я решил проверить, как система реагирует уже не на отказ устройства, а на перегрузку сети.

Всем нам знакома ситуация, когда сеть “ложится” из-за резервного копирования ночью. Для симуляции этого я запустил генерацию трафика через iperf3 с одного XP-компьютера на другой. На сервере (приёмнике) был запущен iperf3 -s, на клиенте (отправителе) - «бэкап» командой iperf3 -c <IP-сервера> -t 300, на 5 минут.

Уже через пару минут OpenNMS Horizon уловил перегрузку и подсветил этот момент на главной консоли. При этом в режиме реального времени я наблюдал рост трафика на интерфейсе, т.е. отдельный график показывал пики нагрузки онлайн, что очень удобно.

Также я увидел рост исходящего трафика на клиенте (отправителе). На графике Bits In/Out, собранном через SNMP с интерфейса сетевой карты, отчётливо видно увеличение исходящего потока данных. Этот показатель формируется на основе стандартных SNMP-счётчиков (ifInOctets и ifOutOctets), которые фиксируют количество принятых и отправленных октетов на интерфейсе.

В качестве заключительного сценария я смоделировал проблему “медленного интернета” на виртуальной машине.
Для этого я использовал утилиту Clumsy, которая позволяет в реальном времени симулировать сетевые проблемы: задержки, потери пакетов и т.д. В результате OpenNMS Horizon, где заранее было настроено правило на подобные ситуации, через 5-10 минут зафиксировал проблему, вывел уведомление на главной консоли и отразил всплески на графиках ICMP и SSH.

Заключение

Эти небольшие эксперименты, конечно, не отражают всей полноты возможностей OpenNMS Horizon, но позволяют взглянуть на него не как на «очередное обновление», а как на реальный инструмент для мониторинга.

В тестах система показала себя гибкой и надёжной, она одинаково уверенно реагирует и на простые инциденты вроде отключения узла, и на более сложные сценарии, перегрузку сети или деградацию канала.

Да, у OpenNMS есть свои особенности: высокий «порог вхождения» (Java, PostgreSQL, ручная конфигурация XML), относительно небольшое и разрозненное сообщество, а также позиционирование в первую очередь как enterprise-решения. Но всё это компенсируется мощным функционалом и направлением развития проекта.

Даже если вы не планируете использовать OpenNMS в продакшене, стоит хотя бы познакомиться с его возможностями, это помогает понять, куда движется рынок мониторинга сетей.