# OpenNMS, one platform for faults, performance and flows > OpenNMS is a long-lived Java network management platform that puts fault, performance and traffic monitoring in one place, and the parts worth understanding are the scale-out story, where Minions distribute the collection and Sentinels store the flows, and the protocol coverage, which is wide enough that most operators never write a plugin. The repository is a Maven monorepo of a few dozen modules with its own Antora documentation build. **OpenNMS/opennms** — Enterprise-Grade Open-Source Network Management Platform - Repository: https://github.com/OpenNMS/opennms - Website: http://www.opennms.org/ - Stars: 1,180 · Forks: 613 - Language: Java - License: NOASSERTION - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/opennms-opennms ## Fault, performance and traffic in the same place OpenNMS is an open source network monitoring platform that helps you visualise and monitor everything on your local and distributed networks. The summary line is more specific than that, though: OpenNMS offers comprehensive fault, performance and traffic monitoring with alarm generation in one place, and is highly customisable and scalable, integrating with your core business applications and workflows. The project is known as OpenNMS Horizon, which is the name the releases use, and the code base lives in the OpenNMS/opennms repository. The distinction matters for anyone searching for documentation, because the release artefacts are called OpenNMS Horizon 36.0.5 while the project and the website are OpenNMS. What the platform does is best understood by the shape of the feature list, which is not a list of small features but a set of capabilities that usually come from different products. Fault management with alarm generation, performance measurement with thresholding, and flow analysis with deep dives, in one platform with a unified UI, is the differentiator. An organisation that would otherwise run a performance monitor, a flow analyser and a fault manager side by side, each with its own alarms and its own dashboards, is the audience the phrase enterprise-grade open source is aimed at. The Java implementation and the maturity of the project are visible in the release numbering, which is at 36. The version history is not a sign of churn so much as of a project that has never had to restart. The readme points at two documents for the practical work: an installation guide and a build-from-source guide, both in the Antora documentation under the docs/modules tree. Storage is not necessarily a single database: the vendor describes PostgreSQL for the core and additional stores for flow and performance data depending on configuration. ## The protocol list, and the promise not to write plugins The data collection feature claims that OpenNMS works with many industry standard data collection protocols with no need to write or maintain third party plugins, and then lists them: SNMP, JSON, WinRM, XML, SQL, JMX, SFTP, FTP, JDBC, HTTP, HTTPS, VMware, WS-Management and Prometheus. That list is the substance of the claim, and it is worth reading as a coverage map of what a modern estate contains. SNMP covers the network devices. WinRM, WS-Management and JMX cover the Windows and Java estates. JSON, XML and HTTP cover the API-shaped world, where a device exposes a REST interface instead of a protocol. SQL and JDBC are the data sources, which is how you monitor a database server by querying it. SFTP and FTP reach into the device for files. VMware covers the virtualisation layer. And Prometheus is there, which is the interesting one, because it means the platform can ingest the metrics format that the cloud native world has standardised on, and can be a destination for exporters rather than only a source of its own. The claim has a boundary, and a reader should know where it is. The list is the set of protocols the platform knows how to speak, and a protocol the platform does not speak still needs something written, whether that is a plugin, a script or a collector. The value of the list is that for most estates the answer is already there. The other half of the inventory story is the provisioning system, described as flexible and providing many ways to interoperate with configuration management systems. That is the piece that stops the monitoring database from drifting away from the infrastructure, and it is why the feature is titled full inventory management rather than something about devices. ## Flows at scale, and the three processes that make it work Traffic management is the feature with the most specific numbers in the readme, and the scalability section explains how that number is reached. The flow protocols supported are NetFlow v5 and v9, IPFIX and sFlow, with the claim of 300,000 or more flows per second. BGP monitoring is supported, implementing the OpenBMP standards for BGP messages and metrics, alongside deep-dive analysis and enterprise reporting. The scale-out story is the interesting part, and it has three named pieces. Sentinels handle flow persistence, that is, they are the processes that store the flow data. Minions handle the ingest work, and the readme is specific about what they take: flow, BMP, SNMP trap and Syslog ingest. And the platform can embed ActiveMQ to Kafka message brokers, which is the bridge that lets the monitoring system feed the event stream that the rest of an organisation's tooling consumes. That division is a good one, because the three workloads have very different shapes. Flow ingest is a firehose of small records that wants to be spread across the network and written to fast storage. Trap and syslog ingest is a low-volume, high-value stream that wants to be spread across the network and correlated centrally. BGP monitoring is a conversation with the routers themselves, which wants to run where the routes are. Putting all three behind one collector would make the firehose pay for the other two, so the Minion and the Sentinel are separated. The Kafka bridge deserves a second look, because it is the piece that stops the platform from being a silo. A monitoring system that also publishes what it learns into the company's event backbone is a different proposition from one that only has a web UI. ## Minion measures from where the user is Digital experience monitoring is the feature that sounds smallest and is in some ways the most distinctive. The readme describes it as using the OpenNMS Minion to monitor a service's latency and availability from different perspectives. The distinction is between measuring a service from the infrastructure side and measuring it from the places where people experience it. A latency figure collected by a probe next to the data centre says something about the service; a latency figure collected from a branch office, a home connection or a mobile network says something about the user. Those numbers differ, and the difference is the thing a service level agreement is written against. The Minion is the same process that does the flow, trap and syslog ingest, which is a practical point about the design. A single agent that can both report on a service from a remote site and carry the flow and trap traffic from that site avoids the usual arrangement of several agents per remote location, each with its own configuration, its own upgrade cycle and its own failure mode. For a network team, the practical question this raises is where the Minions go. The readme's scalability section treats them as a fleet, and the digital experience feature treats them as vantage points, and those are the same deployment described from two ends. A platform with one agent that can be placed for either purpose is easier to operate than a platform with a monitoring probe, a trap receiver and a flow collector. The readme also notes the configuration side, which is where a platform of this kind tends to be weakest. Most features can be configured through the web UI or XML scripting, including thresholding, provisioning, event and flow management, service monitoring and performance measurement. The XML route is the one that matters at scale, because a thousand thresholds configured by hand in a web interface is not a configuration. ## Reporting, dashboards and topology Enterprise reporting and visualisation is the last of the feature blocks, and it is the one that describes what a user actually sees. Customisable dashboards can be exported as a PDF. There are resource graphs, database reports and charts. And there is the ability to define and customise complex layered topologies to integrate topology maps into the service problem management workflow. That last phrase carries the feature. A topology map is not decoration in an operations tool, it is the mechanism by which an alarm is translated into an impact statement. If a link fails and the topology knows that four services depend on it, the alert can say that four services are affected, which is the difference between an alert and an incident. Layered topologies exist to make that dependency information explicit and editable, and the fact that the readme puts the topology map inside the service problem management workflow rather than in a separate visualisation section says the tool treats it as core. The export to PDF is worth a mention too, because it is the difference between a monitoring system that lives in a browser and one that can produce a document for a review. In a platform of this scope, the document is often the artefact that the organisation is actually asked for. The dashboards and the reporting are also where the platform's breadth shows: resource graphs and database reports in one product means the same system answers both a live operational question and a quarterly question about capacity. ## A Maven monorepo, a Perl build and an Antora documentation pipeline The repository layout shows the scale of the thing, and it is worth a walk because the names are the design. There are around thirty modules under opennms- prefixes, and they are named by responsibility. The configuration layer is split into opennms-config, opennms-config-api, opennms-config-dao, opennms-config-jaxb, opennms-config-model and opennms-config-tester, which is a deliberate separation of the configuration model, its persistence, its API and the thing that validates it. The data access layer is opennms-dao with opennms-dao-api and opennms-dao-mock beside it, and the mock is the giveaway that the layer is designed to be tested. There is opennms-alarms, opennms-correlation for the alarm correlation, opennms-services, opennms-provision, opennms-model, opennms-rrd for the round robin database, opennms-icmp, opennms-javamail, opennms-jetty for the embedded web server, opennms-config-api and opennms-openapi-docs for the API documentation, opennms-enterprise-reporting, and a set of assemblies, opennms-base-assembly, opennms-full-assembly and opennms-assemblies, which is how the different distributions are put together. The build tooling is a mixture of eras, which is normal for a project of this age. There are Perl scripts, compile.pl, assemble.pl and clean.pl, a Makefile, packaging scripts makedeb.sh and makerpm.sh, a debian/ directory and a container/ directory, and Maven with a maven/ directory and a dependencies/ directory. CircleCI configuration sits in.circleci. The documentation has its own pipeline, and the root Makefile is entirely for it. It builds Antora documentation, either with a locally installed Antora or from a Docker image, opennms/antora:3.1.4-b10433 by default, and the make targets are help, docs, docs-docker, docs-deps, docs-deps-docker, docs-serve, docs-serve-stop, docs-clean, docs-clean-cache and clean-all, with the docker serve target running a local web server with Nginx to preview the site. The site file is antora-playbook-local.yml and both the image and the site file are overridable arguments. One file in the root is unusual and worth knowing about. There is a.gitconsensus.yaml, and there is a.version.txt and a.nightly marker, and a WHATSNEW.md that carries the user-facing change notes for each release. ## Where OpenNMS is the wrong tool The first limit is the shape of the deployment. A platform that does fault, performance and flow, with a web UI, a relational database, a service-oriented ingest architecture and a reporting subsystem, is an operation in itself. An organisation that runs a handful of sites and wants alerts by email does not need this, and the readme says as much in a roundabout way, pointing people who just want to try it at a set of basic install scripts for a simple non-production evaluation. Those scripts are not an installation guide and should not be read as one. The second is the collector topology. The scale story only works if the Minions are placed sensibly and the Sentinels are sized for the flow volume, and getting that wrong is not a configuration mistake, it is a design task. The same applies to the ingest split between flow, trap, syslog and BMP, because the readme's own list shows that these are different workloads with different placement needs. The third is the flow storage cost. Three hundred thousand flows per second is a headline throughput number, and the flows themselves are the cheap part, whereas the storage and the retention behind them are not, and the readme does not give guidance on how long to keep them or how to budget for it. The fourth is the protocol boundary. The no-plugins-needed claim covers the listed protocols, and an estate that speaks something else is back to writing something, whether that is a plugin, a script or a sidecar. The fifth is the licensing and the repository layout. The licence field on the project is one GitHub cannot classify, and the repository carries both a COPYING file and a LICENSE.md, so a large deployment that has to answer a licence questionnaire needs to read those files. And the default branch is develop, with the releases tagged separately, which is the right arrangement for a project this size but means the default view of the repository is the moving target rather than a release. ## Conclusion OpenNMS fits a network operations team that wants fault, performance and flow monitoring in one product, that has a mixed estate of devices speaking anything from SNMP to WS-Management, and that needs the collector to run close to the network it watches. It does not fit a team that wants a small agent and a light database, because this is an enterprise platform with a large service footprint, and it does not fit a team that needs a hosted or SaaS offering. Before evaluating it, read the deployment guide rather than the install scripts, since the opennms-forge scripts are explicitly for a simple non-production evaluation, and decide which collector runs where, because the Minion and Sentinel topology is the part of the design that determines whether the thing scales. Version 36.0.5 was published on 2026-10-14, the default branch is develop, and the last push was on 2026-10-15. ## FAQ ### What is OpenNMS? An open source network monitoring platform that helps you visualise and monitor everything on your local and distributed networks, offering comprehensive fault, performance and traffic monitoring with alarm generation in one place. The releases are named OpenNMS Horizon, and the project describes itself as enterprise grade open source. ### Which data collection protocols does OpenNMS support? SNMP, JSON, WinRM, XML, SQL, JMX, SFTP, FTP, JDBC, HTTP, HTTPS, VMware, WS-Management and Prometheus, and the README says these work with no need to write or maintain third party plugins. ### How does OpenNMS scale to large networks? Through Sentinels for flow persistence, Minions for flow, BMP, SNMP trap and Syslog ingest, and an embedded ActiveMQ to Kafka bridge for message brokers. Flow support covers NetFlow v5 and v9, IPFIX and sFlow, with a claim of more than 300,000 flows per second. ### What is the OpenNMS Minion for? It is used for digital experience monitoring, meaning monitoring a service's latency and availability from different perspectives, and the same agents handle the flow, BMP, SNMP trap and Syslog ingest work. ### How do I try OpenNMS without a production install? The README points to the opennms-forge/opennms-install repository, which has basic install scripts for a simple non-production evaluation of OpenNMS Horizon on Linux. The full installation and build-from-source guides are separate documents in the Antora documentation. ## Sources - [Issues](https://github.com/OpenNMS/opennms/issues) - [OpenNMS/opennms on GitHub](https://github.com/OpenNMS/opennms) - [Project website](http://www.opennms.org/) - [README](https://github.com/OpenNMS/opennms/blob/develop/README.md) - [Releases](https://github.com/OpenNMS/opennms/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/opennms-opennms