Planet OpenNMS 2026-06-09T05:00:02Z Venus The OpenNMS Group webmaster@opennms.com https://planet.opennms.org/atom.xml https://www.opennms.com/?p=21411 RRDtool, Newts, Prometheus: Where OpenNMS Time Series Storage Goes Next

When you're monitoring thousands of devices, the choice of where you put your performance metrics matters. Every value collected by collectd, every response time recorded by pollerd, every streaming telemetry sample ends up stored as time series data, and that data has to keep up, scale out, and play nicely with the tools your IT [...]

The post RRDtool, Newts, Prometheus: Where OpenNMS Time Series Storage Goes Next appeared first on The OpenNMS Group, Inc..

When you're monitoring thousands of devices, the choice of where you put your performance metrics matters. Every value collected by collectd, every response time recorded by pollerd, every streaming telemetry sample ends up stored as time series data, and that data has to keep up, scale out, and play nicely with the tools your IT Operators use day to day.

We've been making changes to the time series storage options in OpenNMS and now is a good moment to explain where we're headed and what it means for you.

Why Prometheus-Style Time Series Storage?

OpenNMS has long supported several time series backends. For example: RRDtool for traditional file-based storage, Newts on top of Apache Cassandra for horizontally scaled deployments, and a plugin-based path to many other Time Series Storage backends like Prometheus.

Going forward, we're focusing on that last option as the recommended scale-out path. Here's why:

  • Horizontal scalability done right. Prometheus-style stores are purpose-built for ingesting and querying time series at massive volumes. They've been hardened in production at organizations running well into the millions of active series.

  • First-class query integration. No matter the dashboarding platform your operators are using, their job is about quickly creating queries to make use of the data. The Prometheus Query Language (PromQL) lets you search your data quickly. It’s easy to adjust data with computation in-line, it’s templatable and portable, and it’s simple to write and understand.
  • A healthier ecosystem. Prometheus has become the de facto open-source standard for metrics. Choosing a Prometheus-compatible backend means more downstream tooling, more community know-how, and more flexibility over time. Customers today are using OpenNMS with Prometheus, Cortex, Mimir, Thanos, and Victoria Metrics – all of which support this Prometheus-style Time Series format.

If you're spinning up a new OpenNMS deployment today, or rethinking how to scale an existing one, a Prometheus-style backend is the path we're going to be investing the most in going forward.

Renaming the Cortex Plugin to Prometheus RemoteWrite Plugin

It’s been a bit of an undocumented feature that our Cortex plugin works with any Prometheus remote-write compatible time series backend. Users have been leveraging it for production workloads for quite some time. However, the name we initially chose isn’t a true reflection of the broad compatibility we offer and it’s caused some confusion. "Cortex" refers to one specific implementation, but the plugin works with the wider family of Prometheus-compatible databases that enable remote-write capability.

To better reflect what the plugin actually does, we have renamed the Cortex plugin to Prometheus RemoteWrite Plugin. The functionality is the same; the name is a more accurate description of the broader use case.

We’ve also got more updates planned for the Prometheus RemoteWrite Plugin thanks to the valuable feedback from Horizon users in our community, our Meridian customers, and our own developers and contributors.

What's Happening with Newts and Cassandra?

When Newts was introduced, Apache Cassandra was the most practical answer to "how do I scale this horizontally?" That landscape has changed. Purpose-built time series databases now do this job with less operational overhead, and they integrate more cleanly with modern dashboarding tools.

With that in mind, support for the Newts plugin (Cassandra-backed time series storage) will be discontinued with the upcoming Meridian 26 release.

Here's what that means in practice:

  • Meridian 26 will still ship with Newts support for existing Newts users. If you're already running on Newts, you can continue to do so through that release.
  • OpenNMS Meridian releases are supported for three years after their initial release. Anyone deploying Meridian 26 has a full three-year window of official Newts support — plenty of runway to plan and execute a migration on their own schedule.
  • After Meridian 26 reaches end of support, OpenNMS will no longer provide official support for the Cassandra backend. Newts will not be carried forward into subsequent Meridian releases.
  • OpenNMS is open source. Even after official support ends, the Newts code won't just disappear. The community has historically been a great resource for keeping useful pieces alive, and that option remains for users who want to continue running Newts beyond the official support window.

If you're a current Newts user, there's nothing you need to do tomorrow, but it's worth starting to think about your migration path now, while you have plenty of time on the clock. If you’re an existing Meridian Newts user then we have professional services and support options to help you with a migration plan. Just get in touch.

What's Happening with RRDs?

Nothing! At least, not yet. RRDs, or Round Robin Databases, have been used by OpenNMS since the early days and we aren’t moving on from them yet but the work we have done with Time Series Storage (TSS) and the work we are putting in to update and refine our Prometheus TSS plugin is getting us headed in a direction to eventually makes some moves with RRDs as well. Stay tuned.

Get Started

If you're planning a new OpenNMS deployment, or evaluating how to scale your existing one, here are some good next steps:

  • Read the docs. See the Time Series Integration Layer and Prometheus RemoteWrite Plugin documentation for current configuration details. We'll be updating the docs to reflect the new plugin name as part of the rename.

  • Pick a backend. VictoriaMetrics, Mimir, and Cortex are all good options. Choose based on the operational profile that best fits your team and the support you need.

  • Install OpenNMS with the new integration plugin. Get your OpenNMS install setup and running with the new Prometheus TSS Plugin.

Planning for What’s Next

Time series storage is one of those choices that quietly defines what your monitoring platform can do five years from now. By investing in Prometheus-style backends, renaming the Cortex plugin to reflect its broader compatibility, and giving Newts users a clear three-year runway, we're making the next decade of OpenNMS deployments more scalable, more interoperable, and easier to live with.

If you'd like to talk through what makes sense for your environment, contact us. We are happy to help you think it through.

The post RRDtool, Newts, Prometheus: Where OpenNMS Time Series Storage Goes Next appeared first on The OpenNMS Group, Inc..

 2026-06-05T17:32:53Z José Anés https://www.opennms.com/ https://www.opennms.com/wp-content/uploads/2021/04/OpenNMS_Favicon_36px.png The OpenNMS Group, Inc. 2026-06-05T17:40:02Z https://www.opennms.com/?p=21397 Need an Exit from Junos Space? Meridian Is It.

As of July 2024, Juniper effectively deprecated the OpenNMS component of Junos Space with the release of Space 24.1R1. OpenNMS is no longer bundled on Space VMs and has to be installed separately by users. Juniper is currently pointing users at an outdated version of OpenNMS Horizon (which is our community edition) to fill this [...]

The post Need an Exit from Junos Space? Meridian Is It. appeared first on The OpenNMS Group, Inc..

As of July 2024, Juniper effectively deprecated the OpenNMS component of Junos Space with the release of Space 24.1R1. OpenNMS is no longer bundled on Space VMs and has to be installed separately by users. Juniper is currently pointing users at an outdated version of OpenNMS Horizon (which is our community edition) to fill this gap. If you're still relying on Space for network monitoring, you need a supported, maintained path forward and that's exactly what our long-term support offerings with OpenNMS Meridian provide. We've already successfully migrated customers from Junos Space to Meridian, and as the team that actually builds and maintains Meridian, we're uniquely positioned to get you there too.

You're Running Unsupported Software Right Now

Junos Space support is at the end of life. It's shuffled off its mortal coil and ceased to be. However, you might still be relying on it to monitor your network, which means you're running unsupported software, and Juniper isn't coming back to fix it for you. Space had a well-earned reputation for a slow, frustrating UI even among its own users. Now that it's EOL, those problems aren't going anywhere. But we here at OpenNMS can help.

Space Was Always a Stale Fork

It's been an open secret for a long time that Junos Space leveraged OpenNMS. In fact, it's based on an older version of OpenNMS Meridian. Space was a frustrating product even when it was supported, and that's because it never got the latest updates. It was always out of date on a stale fork. Engineers who lived with it complained constantly about clunky workflows, an interface that felt a decade behind, and a polling engine that would buckle under real enterprise device counts. Juniper certainly wasn't delivering UI updates, performance improvements, or new features either.

The Engine Underneath Is Alive and Thriving

The good news is that the core that powered Space has been thriving without it. OpenNMS Meridian has been actively developed for the entire span that Space sat frozen. It's been gaining new features, performance enhancements, and quality improvements that Space users never saw and never will.

Where Space Failed, Meridian Delivers

If you're still relying on Space, or if you liked the basic monitoring and alerting it provided and your workflows are built around it, Meridian is your path forward and it directly addresses the things Space was worst at. The data collection engine is flexible enough to monitor pretty much anything you can point it at. The Grafana integration produces dashboards that look like they come from this decade rather than the last one. Our Device Configuration Backup feature gives you automated backups for your switch and router configurations which is something Space users had to previously cobble together themselves.

Scale Was Always Space's Achilles' Heel

Space also struggled notoriously with larger environments. Admins managing anything north of a few hundred devices reported sluggish discovery, failed polls, and an interface that became nearly unusable at scale because it was never tuned for the workloads it was being handed. Meridian runs comfortably into the tens of thousands of devices out of the box, and with our Support offerings, you'll always be covered as your network grows and your monitoring needs evolve.

Stop Waiting and Come Back to the Original

The migration clock is already running. Every day you stay on Space is another day on unsupported, unpatched software with no vendor standing behind it. The move to Meridian isn't a compromise. It's an upgrade to the product Space was always trying to be. Talk to our team today and we'll get you on a migration path that works for your environment. You were going to have to do this anyway. Do it now and come back to the original.

The post Need an Exit from Junos Space? Meridian Is It. appeared first on The OpenNMS Group, Inc..

 2026-05-29T15:24:50Z Marshall Massengill https://www.opennms.com/ https://www.opennms.com/wp-content/uploads/2021/04/OpenNMS_Favicon_36px.png The OpenNMS Group, Inc. 2026-06-05T17:40:02Z https://www.opennms.com/?p=21367 How a Leading UK Fiber Network Operator Uses OpenNMS to Deliver Reliable Network Monitoring to its Customers

The UK’s fiber revolution is well underway with more than 16 million premises now passed by full-fiber infrastructure and over half the country able to access a gigabit-capable connection (Ofcom Connected Nations Report, 2025). Raw coverage is only part of the story though. Behind every fast, reliable broadband connection is a wholesale network operator responsible [...]

The post How a Leading UK Fiber Network Operator Uses OpenNMS to Deliver Reliable Network Monitoring to its Customers appeared first on The OpenNMS Group, Inc..

The UK’s fiber revolution is well underway with more than 16 million premises now passed by full-fiber infrastructure and over half the country able to access a gigabit-capable connection (Ofcom Connected Nations Report, 2025). Raw coverage is only part of the story though. Behind every fast, reliable broadband connection is a wholesale network operator responsible for keeping thousands of links running at peak performance, around the clock. This is the story of how one such operator turned to OpenNMS to meet that challenge head-on.

The Challenge: Meeting a Major ISP’s High Standards

An operator provides the fiber lines and they’re responsible for making sure everything works perfectly for the ISPs that rely on their network. With Internet outages costing the UK economy an estimated £1.4 billion in lost work hours in the past year (Uswitch, 2025) there is a lot at stake.

When a major national ISP recognized they had outgrown their homegrown tools and they needed enterprise-grade monitoring to meet their service level agreements, they turned to OpenNMS. They needed to ensure precise tracking for thousands of interfaces and delivering the precise 95th percentile link utilization metrics that are the industry-standard measure for wholesale fiber SLAs.

How OpenNMS Stepped In

A full-fiber access network generates significantly more performance data than an equivalent copper network—per-port diagnostics, optical power levels, and dense interface metrics all add up fast. We rolled out a solution built to handle that scale: 10,000 to 20,000 interfaces across core and edge routers, with metrics collected every five minutes. The goal? Give the operator the data they need, fast and reliably, so the ISP’s customers never miss a beat and auditing reports for SLAs don’t show erroneous results.

The Results: Reliable Monitoring, Happy Customers

Today, the operator’s ISP monitoring is live and working, with OpenNMS keeping constant watch on the performance of their network. The success of this project has opened the door to more collaboration and bigger monitoring ambitions, including next-generation metric streaming over IPFIX.

By the Numbers

  • Provider edge routers monitored: 13
  • Interfaces per router: ~7,700
  • Metrics per interface: 24
  • Metrics collected every five minutes: 2,516,016

Looking Ahead

OpenNMS helped the operator deliver on the ISP’s high expectations, and we’re just getting started. Stay tuned for more stories from the network edge!

Interested in learning more about how OpenNMS can help your company? Contact us to speak with one of our network monitoring experts.

The post How a Leading UK Fiber Network Operator Uses OpenNMS to Deliver Reliable Network Monitoring to its Customers appeared first on The OpenNMS Group, Inc..

 2026-05-21T12:28:31Z Jen Fekin https://www.opennms.com/ https://www.opennms.com/wp-content/uploads/2021/04/OpenNMS_Favicon_36px.png The OpenNMS Group, Inc. 2026-06-05T17:40:01Z tag:github.com,2008:Repository/9377198/opennms-36.0.0-1 OpenNMS Horizon 36.0.0

Release 36.0.0

Release 36.0.0 is the first major release in the 36.x series.

Introduces new features including DB-backed configuration for SNMP, data collection, and Trapd, plus environment variable support in service configuration.

Bug
Enhancement
  • Add copy icon to node page IP addresses (Issue NMS-19628)
  • Add filtering on metrics in Kafka producer (Issue NMS-19395)
  • Add metadata support in service configuration (Issue NMS-19113)
  • Add node in exported ResponseTimeResource messages (Issue NMS-19223)
  • DCB: Add config fetch from sshScriptingService output (Issue NMS-19754)
  • DCB: Emit an event when config changes between backup intervals (Issue NMS-19773)
  • Move eventconf.xml to DB (Issue NMS-19575)
  • Move existing events into etc_archive (Issue NMS-19600)
  • Run Core, Minion and Sentinel on Java 21 even compiled with 17 (Issue NMS-19451)
  • UX Design for Trapd Config (Issue NMS-19487)
Epic
  • Support OpenNMS running with Java 21 (Issue NMS-19482)
New Feature
  • Allow Karaf cache cleanup configuration via environment variables (Issue NMS-19368)
  • Expose Rest End points to add/update mib groups, resource types and system definations for a specific snmp data collection ID (Issue NMS-19453)
  • Expose rest end points to delete list of snmpCollectionSources | Expose services to delete list of mibgroups,resourcetypes and systemdefs (Issue NMS-19486)
  • Expose rest endpoint for upload/update trapd configuration (Issue NMS-19611)
  • FE: Add function to create/update mib groups in data collection config creation UI (Issue NMS-19550)
  • FE: Add function to create/update resource types in data collection config creation UI (Issue NMS-19551)
  • FE: Add overwrite and rename functionality for a source (Issue NMS-19452)
  • FE: Add/Update mib groups and integrate endpoint (Issue NMS-19503)
  • FE: Add/Update resource types and integrate rest endpoint (Issue NMS-19491)
  • FE: Add/Update system defs and integrate rest endpoint (Issue NMS-19490)
  • FE: Change create/edit resource type and mib groups component to drawer (Issue NMS-19570)
  • FE: Convert Storage Strategy and Persistence Selector Strategy field from select dropdown to autocomplete (Issue NMS-19527)
  • FE: Create Table for SNMP v3 user management (Issue NMS-19596)
  • FE: Create form for SNMP v3 User creation and edit (Issue NMS-19597)
  • FE: Create general configuration form in trap config UI (Issue NMS-19594)
  • FE: Create initial scaffolding for data collection UI (Issue NMS-19360)
  • FE: Create initial scaffolding for data collection details UI (Issue NMS-19361)
  • FE: Data Collection Source page redesign (Issue NMS-19553)
  • FE: Data collection Details UI page redesign (Issue NMS-19561)
  • FE: Delete sources, systemdefs, resource types and mib groups (Issue NMS-19514)
  • FE: Download vendor/source specific files (Issue NMS-19515)
  • FE: Enable/Disable data collection sources (Issue NMS-19540)
  • FE: Initial UI for creating datacollection config (Issue NMS-19539)
  • FE: Integrate get/upload/update rest endpoint for trapd config (Issue NMS-19621)
  • FE: Integrate source rest endpoint with pagination, sorting and searching (Issue NMS-19439)
  • FE: Test coverage for sources, system defs, resource types and mib groups (Issue NMS-19488)
  • Java 21 Support (compiling and running) (Issue NMS-19396)
  • Provide functionality to enable/disable status of sources/mibgroups/resourceTypes/systemDefs (Issue NMS-19563)
  • Update SNMP Config Rest API to add an entire Definition, not just a range (Issue NMS-19516)
  • Update documentation for trapd config (Issue NMS-19652)
Story
  • Add Rest API for new/edit snmp collection name (profile) (Issue NMS-19713)
  • Add Integration tests to validate migration to DB (Issue NMS-19769)
  • Add ability to download vendor/source specific data collection config files. (Issue NMS-19502)
  • Add support for downloading Trapd Config (Issue NMS-19724)
  • Create DB Entities with Dao interface and impls (Issue NMS-19258)
  • Create Liquibase changelog for SNMP collection configuration tables (Issue NMS-19257)
  • Deprecate C3P0 connection pool (Issue NMS-19576)
  • Deprecate JoeSnmp implementation (Issue NMS-19577)
  • Deprecate WMI support (Issue NMS-19262)
  • FIPS Compliance : Fix usermanager exception : SHA1PRNG not available (Issue NMS-19519)
  • Implement REST endpoint to upload and import vendor XML files into database (Issue NMS-19261)
  • Implement offline XML-to-database migration during upgrade (Issue NMS-19259)
  • Make OSGiBasedTicketerPlugin the default and auto-enable ticketing when a plugin register (Issue NMS-19521)
  • Propose design and implementation details (Issue NMS-19225)
  • Remove SNMP config encryption support in favor of SCV (Secure Credentials Vault) (Issue NMS-19643)
  • Support Downloading of individual source files from data collection config (Issue NMS-19770)
  • Trap Config UI doesn't handle if security level is not present in config (Issue NMS-19726)
  • UX Design for SNMP Configuration Management UI (Issue NMS-19363)
  • Update DefaultDataCollectionConfigDao to load from database instead of XML files (Issue NMS-19260)
  • Update outage list page column labels and usability improvements (Issue NMS-19548)
Task
  • Clean up plugins include in our containers by default (Issue NMS-19775)
  • Cleanup some of the issues in snmp data collection feature (Issue NMS-19534)
  • Create Java 21 Build environment (Issue NMS-19441)
  • Deprecate "legacy" SNMP Config Rest APIs (Issue NMS-19639)
  • Docs: Update Elasticsearch (Issue NMS-19555)
  • Documentation for SNMP Config Rest API updates (Issue NMS-19509)
  • Enable light/dark mode switching for Vue pages (Issue NMS-19617)
  • Ensure Trap Config is in search (Issue NMS-19729)
  • FE: Add UI components for SCV attribute selection in SNMP Config input controls (Issue NMS-19443)
  • FE: Add concurrently to slightly speed up UI build times (Issue NMS-19584)
  • FE: Create a component combining FeatherInput with SCV Icon button and apply to SNMP Config (Issue NMS-19510)
  • FE: Create initial scaffolding for UI (Issue NMS-19592)
  • FE: Event conf xml validator test case failing (Issue NMS-19365)
  • FE: Improve Source Selection Flow Before Event Creation (Issue NMS-19364)
  • FE: Initial SNMP Config UI scaffolding, route and data types (Issue NMS-19226)
  • FE: Integrate rest endpoint for mib groups with pagination, searching and sorting (Issue NMS-19481)
  • FE: Integrate rest endpoint for resource types with pagination, searching and sorting (Issue NMS-19480)
  • FE: Integrate rest endpoint for system defs with pagination, searching and sorting (Issue NMS-19479)
  • FE: Replace xml with JSON when creating and updating an event. (Issue NMS-19094)
  • FE: SNMP Config Lookup UI (Issue NMS-19265)
  • FE: SNMP Config Revised Lookup UI (Issue NMS-19440)
  • FE: SNMP Config Search UI (Issue NMS-19542)
  • FE: SNMP Config UI for upload/download config (Issue NMS-19506)
  • FE: SNMP Config UI layout changes (Issue NMS-19615)
  • FE: SNMP Config UI should display the default values for items the user did not specifically change (Issue NMS-19564)
  • FE: SNMP Config UI to save and remove profiles (Issue NMS-19398)
  • FE: SNMP Config UI to save configuration by IP address and range (Issue NMS-19367)
  • FE: SNMP Config UI to view and edit global default overrides (Issue NMS-19559)
  • FE: SNMP Config UI updates: use dropdowns for protocols, etc. (Issue NMS-19507)
  • FE: SNMP Config updates to allow user to add or change an entire Definition (Issue NMS-19517)
  • FE: Sort SNMP Config Definitions by Location and IP Address (Issue NMS-19518)
  • FE: Update fortawesome icons from 4.x to 6.7.2 (Issue NMS-16554)
  • FE: Upload data collection files from vendor (Issue NMS-19405)
  • FE: Use common MessageDialog and ConfirmationDialog instead of individual ones (Issue NMS-19523)
  • Fix Alarm Advanced Search to retain values (Issue NMS-19730)
  • Hide existing SNMP Config UI (Issue NMS-19630)
  • Implement rerun for failed tests (Issue NMS-19614)
  • Initial PrimeVue scaffolding and test page (Issue NMS-19189)
  • MIB compiler UI design / task breakout (Issue NMS-19131)
  • Merge SNMP Config feature branch to develop (Issue NMS-19623)
  • Move Plugins UI component between Integrations and Tools in sidebar (Issue NMS-19528)
  • POC for combining Password Gateway, User static and user info modals (Issue NMS-19711)
  • Reduce integration test log verbosity to prevent 50MB log limit failures (Issue NMS-19624)
  • Remove Landing Pages for Alarms (Issue NMS-19681)
  • Remove Landing Pages for Events, replace with Event List (Issue NMS-19709)
  • Remove existing/legacy SNMP Config UI (Issue NMS-19622)
  • Remove process.env in /ui (Issue NMS-19727)
  • Replace npm and yarn with pnpm (Issue NMS-19192)
  • Restructure mib compiler to include rest module (Issue NMS-19625)
  • Review "legacy" SNMP Config Rest APIs (Issue NMS-19629)
  • SCV Rest API to get credentials for all aliases (Issue NMS-19483)
  • SNMP Config Back End, Rest API and UI to Delete a Definition (Issue NMS-19536)
  • SNMP Config Rest API: Integration Tests (Issue NMS-19397)
  • SNMP Config UI details should not display error if user has not filled in range (Issue NMS-19708)
  • SNMP Config UI: Add more help in UI itself (Issue NMS-19728)
  • SNMP Config to DB: Migrate snmp-config.xml to CM (Issue NMS-19150)
  • SNMP Config to DB: Rest API for SNMP Lookup by IP Address (Issue NMS-19264)
  • SNMP Config to DB: Rest API to Add a Definition (Issue NMS-19274)
  • SNMP Config to DB: Rest API to Add/Update a Profile (Issue NMS-19272)
  • SNMP Config to DB: Rest API to Delete a Profile (Issue NMS-19273)
  • SNMP Config to DB: Rest API to Get SNMP Config (Issue NMS-19270)
  • SNMP Config to DB: Rest API to Remove a Definition (Issue NMS-19281)
  • SNMP Config to DB: Rest API to Save Definition having multiple ranges (Issue NMS-19271)
  • SNMP Config to DB: Rest API to Save Global Default Overrides (Issue NMS-19275)
  • SNMP Config to DB: Rest API to download entire config in XML and Json formats (Issue NMS-19456)
  • SNMP Config to DB: Rest API to upload entire config in XML and Json formats (Issue NMS-19457)
  • SNMP Config to DB: Update documentation and screenshots for UI (Issue NMS-19154)
  • SNMP Config: Ensure we properly handle IPv6 (back end) (Issue NMS-19557)
  • SNMP Config: Handle adding, merging, deleting definitions with ipMatch (Issue NMS-19543)
  • SNMP Config: Validate all SCV expressions (Issue NMS-19508)
  • Silence sass deprecation warnings for things we cannot yet fix due to Bootstrap (Issue NMS-19184)
  • Trapd Config to DB: Migrate trapd-configuration.xml to CM (Issue NMS-19448)
  • UBI10: Create the base deploy (Issue NMS-19504)
  • UI library and security updates - foundation-2024 - April 2026 (Issue NMS-19707)
  • UI library and security updates April 2026 (core/web-assets) (Issue NMS-19686)
  • UI security updates April 2026 (Issue NMS-19650)
  • Update /ui to vitest v4 (Issue NMS-19180)
  • Update OpenNMS Integration api to 2.0.0 in develop (Issue NMS-19485)
  • Update axios to 1.6.8 in Foundation-2024 and any other current versions (Issue NMS-16403)
  • Update date-fns to v4 in /ui (Issue NMS-19181)
  • Updates to wording and column names for Events and Alarms (Issue NMS-19627)
 2026-05-13T14:42:07Z mershad-manesh tag:github.com,2008:https://github.com/OpenNMS/opennms/releases Release notes from opennms 2026-05-13T13:57:07Z https://www.opennms.com/?p=21359 May 2026 Releases – Meridian 2025.0.6 and 2024.3.9

In May, we released updates to all OpenNMS Meridian versions under active support. Meridian Stable Updates Meridians 2025.0.6 and 2024.3.9 contains a couple of bug fixes and enhancements. For a list of changes, see the release notes: 2024.3.9 2025.0.6

The post May 2026 Releases – Meridian 2025.0.6 and 2024.3.9 appeared first on The OpenNMS Group, Inc..

In May, we released updates to all OpenNMS Meridian versions under active support.

Meridian Stable Updates

Meridians 2025.0.6 and 2024.3.9 contains a couple of bug fixes and enhancements.

For a list of changes, see the release notes:

The post May 2026 Releases – Meridian 2025.0.6 and 2024.3.9 appeared first on The OpenNMS Group, Inc..

 2026-05-13T14:31:56Z Morteza Ershad-Manesh https://www.opennms.com/ https://www.opennms.com/wp-content/uploads/2021/04/OpenNMS_Favicon_36px.png The OpenNMS Group, Inc. 2026-06-05T17:40:02Z tag:github.com,2008:Repository/9377198/meridian-foundation-2025.0.6-1 meridian-foundation-2025.0.6-1

OpenNMS Meridian Foundation 2025.0.6

 2026-05-13T13:37:57Z opennms-bamboo tag:github.com,2008:https://github.com/OpenNMS/opennms/releases Release notes from opennms 2026-05-13T13:57:07Z tag:github.com,2008:Repository/9377198/meridian-foundation-2024.3.9-1 meridian-foundation-2024.3.9-1

OpenNMS Meridian Foundation 2024.3.9

 2026-05-13T13:19:49Z opennms-bamboo tag:github.com,2008:https://github.com/OpenNMS/opennms/releases Release notes from opennms 2026-05-13T13:57:07Z https://www.opennms.com/?p=21352 From Installed to Optimized: Introducing OpenNMS Professional Services

If your team is among the 63% of organizations fielding more than a thousand infrastructure alerts a day, the problem usually isn't your monitoring platform. It's the gap between a default configuration and one that actually reflects how your environment runs. That gap is what our new Professional Services are built to close. We're excited [...]

The post From Installed to Optimized: Introducing OpenNMS Professional Services appeared first on The OpenNMS Group, Inc..

If your team is among the 63% of organizations fielding more than a thousand infrastructure alerts a day, the problem usually isn't your monitoring platform. It's the gap between a default configuration and one that actually reflects how your environment runs.

That gap is what our new Professional Services are built to close.

We're excited to announce Installation and Integration engagements starting at $500 per project. These services are designed to get OpenNMS deployed the first time correctly and tuned to surface signal instead of noise.

What's Included

Installation

The Installation track covers what most teams want help with up front:

  • Deploy Core — Stand up OpenNMS Core, Minions, and Sentinels with secure communication and validated health checks, so you're production-ready from day one.
  • Upgrade (Config Merge) — Merge your custom configurations cleanly into a newer release, reducing risk while preserving the tuning your team has already done.
  • Node Provisioning — Provision up to 1,000 nodes through PRIS, discovery, or whichever method fits your inventory.
Integration

The Integration track is where OpenNMS starts to look less like a generic monitoring tool and more like part of your stack:

  • Kafka & Prometheus — Connect OpenNMS to your existing data infrastructure for broader observability and external metric consumption.
  • Custom Authentication — RADIUS, LDAP, Active Directory, Kerberos, and SSO/OAuth via third-party modules.
  • Alarm & Event Forwarding — Route alarms and events through any of our northbounders: BSF, Drools, email, trap, syslog, the Kafka Producer, or Elasticsearch archiving.
  • Custom Events & Traps — Scripted event translation and custom trap configurations for the SNMP devices that don't fit a standard MIB.

Why It Matters

The value is straightforward. You get a faster path to a production-ready setup, fewer false positives once you're live, and a configuration our team can stand behind: because we built it with you.

Each package is scoped and priced per project, so you know exactly what you're getting before we start. No surprises.

Ready To Close The Gap?

If you've been putting off a deployment, an upgrade, or that integration backlog because the team doesn't have the cycles, reach out, and we'll put together a plan tailored to your environment.

The post From Installed to Optimized: Introducing OpenNMS Professional Services appeared first on The OpenNMS Group, Inc..

 2026-05-07T18:52:36Z Marshall Massengill https://www.opennms.com/ https://www.opennms.com/wp-content/uploads/2021/04/OpenNMS_Favicon_36px.png The OpenNMS Group, Inc. 2026-06-05T17:40:02Z tag:github.com,2008:Repository/9377198/opennms-35.0.5-1 OpenNMS Horizon 35.0.5

Release 35.0.5

Bug
  • Event Translator doesn't pickup changes on reload event (Issue NMS-19613)
  • MetaTagDataLoader fails to resolve interface scope for streaming telemetry resources (Issue NMS-19599)
  • OpenNMS Twin Shell seems to require flows feature ( ipfix ) (Issue NMS-19598)
  • Update com.hubspot.jinjava:jinjava library (Issue NMS-19526)
  • Update expat library (Issues NMS-18885, NMS-18906, NMS-18940)
  • Update java-21-openjdk-headless library (Issue NMS-19589)
  • Update libbrotli library (Issue NMS-19524)
  • When Minions are upgraded to 35.0.4 the location and Minion ID is overwritten (Issue NMS-19610)
Enhancement
  • Event Conf : Support order in which eventconf.xml assigns the order (Issue NMS-19603)
  • Eventd parameter expansion only resolves ifAlias of associated ipInterface (Issue NMS-19631)
Story
  • FIPS Compliance : Fix usermanager exception : SHA1PRNG not available (Issue NMS-19519)
  • Replace CSV-based user login tracking with a dedicated audit log file (Issue NMS-19638)
  • Update outage list page column labels and usability improvements (Issue NMS-19548)
Task
  • CircleCI Investigate resource usage across our jobs (Issue NMS-19454)
  • Fix the Sentinel Objective (Issue NMS-19554)
 2026-04-08T15:27:49Z mershad-manesh tag:github.com,2008:https://github.com/OpenNMS/opennms/releases Release notes from opennms 2026-05-13T13:57:07Z https://www.opennms.com/?p=21268 April 2026 Releases – Meridian 2025.0.5 and 2024.3.8

In April, we released updates to all OpenNMS Meridian versions under active support. Meridian Stable Updates Meridians 2025.0.5 and 2024.3.8 contains a couple of bug fixes and enhancements. For a list of changes, see the release notes: 2024.3.8 2025.0.5

The post April 2026 Releases – Meridian 2025.0.5 and 2024.3.8 appeared first on The OpenNMS Group, Inc..

In April, we released updates to all OpenNMS Meridian versions under active support.

Meridian Stable Updates

Meridians 2025.0.5 and 2024.3.8 contains a couple of bug fixes and enhancements.

For a list of changes, see the release notes:

The post April 2026 Releases – Meridian 2025.0.5 and 2024.3.8 appeared first on The OpenNMS Group, Inc..

 2026-04-08T15:23:11Z Morteza Ershad-Manesh https://www.opennms.com/ https://www.opennms.com/wp-content/uploads/2021/04/OpenNMS_Favicon_36px.png The OpenNMS Group, Inc. 2026-06-05T17:40:02Z tag:github.com,2008:Repository/9377198/meridian-foundation-2025.0.5-1 meridian-foundation-2025.0.5-1

OpenNMS Meridian Foundation 2025.0.5

 2026-04-08T14:20:05Z opennms-bamboo tag:github.com,2008:https://github.com/OpenNMS/opennms/releases Release notes from opennms 2026-05-13T13:57:07Z tag:github.com,2008:Repository/9377198/meridian-foundation-2024.3.8-1 meridian-foundation-2024.3.8-1

OpenNMS Meridian Foundation 2024.3.8

 2026-04-08T14:00:40Z opennms-bamboo tag:github.com,2008:https://github.com/OpenNMS/opennms/releases Release notes from opennms 2026-05-13T13:57:07Z https://www.opennms.com/?p=21250 OpenNMS Releases OpenNMS Plugin for Grafana Version 12

I am happy to announce that our OpenNMS Plugin for Grafana (OPG) version 12 has been released! Compatibility & What’s New This version is compatible with Grafana 12 (12.4 as of this post) and should also work with Grafana 10 and 11. It works with Horizon 34 or newer as well as with Meridian 25 [...]

The post OpenNMS Releases OpenNMS Plugin for Grafana Version 12 appeared first on The OpenNMS Group, Inc..

I am happy to announce that our OpenNMS Plugin for Grafana (OPG) version 12 has been released!

Compatibility & What’s New

This version is compatible with Grafana 12 (12.4 as of this post) and should also work with Grafana 10 and 11. It works with Horizon 34 or newer as well as with Meridian 25 and the upcoming Meridian 26.

It also features various bug fixes, library, and security updates. These under-the-hood improvements help ensure OPG 12 remains stable, performant, and secure as your monitoring environment grows. Keeping dependencies current also means better compatibility with the broader Grafana ecosystem and reduces exposure to known vulnerabilities — an important consideration for teams running OpenNMS in production environments.

Upgrading Your Dashboards

Any dashboards you have built that work with Grafana 9 or greater should still work with OPG v12. You can use our Dashboard Converter tool to convert any dashboards from Grafana 8-11 to a Grafana 12 / OPG 12 compatible version. Dashboards built using Grafana 8 or the older OpenNMS HELM plugin will need to be converted with this tool.

The Dashboard Converter is designed to be straightforward — point it at your existing dashboard JSON, and it handles the migration automatically, preserving your panels, queries, and layout so you can pick up right where you left off without rebuilding from scratch.

Take a look at our previous blog post by OpenNMS engineer Saul Bernabe to see how you can use OpenNMS and Grafana together to visualize your network.

Special thanks to Saul Bernabe, Marshall Massengill, and Christian Pape for testing and suggestions!

Screenshots of OPG 12 in Action

1. Node Details

Node Information

2. Alarm Details With Custom Alarm Table Panel

Alarm Information

3. Outage Details

Outage Info

Ready to Get Started?

Whether you’re upgrading an existing OPG deployment or exploring OpenNMS and Grafana for the first time, our team is here to help. From installation and integration to custom dashboard design and ongoing support, OpenNMS’s professional services team can guide you every step of the way.

Have questions about OPG 12 or want to discuss your network monitoring setup? Contact the OpenNMS team today — we’d love to help you get the most out of your OpenNMS and Grafana environment.

The post OpenNMS Releases OpenNMS Plugin for Grafana Version 12 appeared first on The OpenNMS Group, Inc..

 2026-03-30T14:26:41Z Scott Theleman https://www.opennms.com/ https://www.opennms.com/wp-content/uploads/2021/04/OpenNMS_Favicon_36px.png The OpenNMS Group, Inc. 2026-06-05T17:40:02Z https://www.opennms.com/?p=21236 A Day in the Life of the OpenNMS Services Resident Engineer: Investigating Networks at Carrier Scale

When people think about professional service and support teams, they often imagine ticket queues and reactive troubleshooting. For the OpenNMS support and services team, the work is far more collaborative. On any given day, our resident engineers are embedded in customer environments, exploring complex networks alongside operators, helping them better understand how their infrastructure behaves [...]

The post A Day in the Life of the OpenNMS Services Resident Engineer: Investigating Networks at Carrier Scale appeared first on The OpenNMS Group, Inc..

When people think about professional service and support teams, they often imagine ticket queues and reactive troubleshooting. For the OpenNMS support and services team, the work is far more collaborative.

On any given day, our resident engineers are embedded in customer environments, exploring complex networks alongside operators, helping them better understand how their infrastructure behaves and how to get more value from the tools they already use.

Here’s a look at what that work looks like through the lens of a recent engagement with a major telecommunications company.

Starting the Day Inside the Network

Rather than beginning with a ticket, our support and services engineers often start by stepping directly into a customer’s network topology.

In this case, the work centers around a GraphML based topology used to visualize microwave links across a large carrier network. These topologies are hierarchical by design, allowing engineers to navigate from high-level views down to individual sites and devices.

This kind of navigation is essential at scale. Large networks aren’t flat. Understanding how components relate to one another is often the first step towards a more meaningful investigation. Our resident engineers can explore and refine these views, so they reflect how the network is operated, not just how it’s documented.

Connecting Topology to Live Network Behavior

Once inside a specific site, the focus shifts from structure to what the network is doing right now.

A core part of our service is helping customers bring live operational data into context. Rather than forcing operators to jump between multiple tools, we can help surface real-time metrics directly within topology views.

In this engagement, that meant pulling dynamic measurements into information panels associated with nodes and links. Metrics are retrieved at runtime and displayed alongside the relevant network elements, allowing engineers to understand performance metrics in context. This approach transforms topology beyond a basic map into a working surface for investigation and understanding.

Making Performance Visible at a Glance

One of the most valuable outcomes of this kind of work is visual clarity.

By comparing live measurements against expected target values defined in the topology, links can be visually highlighted when performance drifts outside acceptable ranges. Color-coded indicators allow engineers to quickly identify areas that may require attention before they escalate.

For large telecommunications networks, where issues can develop gradually and across many locations, this kind of visual feedback is critical. It enables proactive investigation rather than reactive troubleshooting.

Helping customers implement and refine these visual cues is a common theme in OpenNMS engineering engagements and one of the biggest values for OpenNMS as a platform.

Working With Real World Network Complexity

No two customer environments are the same, and our support and services team works closely with customers to adapt solutions to real-world constraints, specific to each customer.

Microwave networks, for example, are often deployed in locations where fiber isn’t practical. As a result, site topologies tend to be compact and highly specialized. At the same time, large carrier environments frequently include multiple device types and vendors, sometimes spanning several generations of hardware.

Part of our role is helping customers navigate that complexity. Our engineers understand how different data models, terminologies, and behaviors fit together, and how to represent them consistently within monitoring and visualization tools.

This work isn’t about forcing uniformity. It’s about making diversity manageable.

Working at OpenNMS Often Involves Exploration

In this case, some of the topology rendering and templating capabilities being used haven't been heavily documented yet. Advancing the solution required examining existing implementations, reviewing code, and experimenting directly within the platform to understand what was possible.

That kind of investigative work is a regular part of how we operate. By deeply understanding the platform and the equipment we are monitoring, we’re able to help customers unlock capabilities they may not have realized were available to them.

Laying the Groundwork for Long-term Value

Much of this work takes place in staging environments, where ideas can be tested and refined without risk production data. The goal is to validate and shape solutions that can evolve alongside the customer’s network and business needs.

By helping customers explore topology-driven visualization, dynamic metrics, and contextual investigation, OpenNMS resident engineers lay the foundation for more scalable, more intuitive network operations over time.

What Modern Support and Services Really Look Like

A day in the life of the OpenNMS support and services team isn’t about closing tickets as quickly as possible or burning buckets of hours. It’s about working alongside customers to deeply understand their networks and help them operate with confidence.

That means:

  • Navigating complex, layered network environments
  • Connecting static topology with live operational data
  • Making performance issues visible and intuitive
  • Exploring platform capabilities to solve real customer problems

This is the kind of service modern networks require — and the kind of partnership OpenNMS strives to deliver every day.

Interested in learning more about what the OpenNMS support and services team can do for you? Contact us to speak with one of our network monitoring experts.

The post A Day in the Life of the OpenNMS Services Resident Engineer: Investigating Networks at Carrier Scale appeared first on The OpenNMS Group, Inc..

 2026-03-13T13:02:08Z Marshall Massengill https://www.opennms.com/ https://www.opennms.com/wp-content/uploads/2021/04/OpenNMS_Favicon_36px.png The OpenNMS Group, Inc. 2026-06-05T17:40:02Z tag:github.com,2008:Repository/9377198/opennms-35.0.4-1 OpenNMS Horizon 35.0.4

Release 35.0.4

Bug
  • FE: Fix warnings in EventConfigurationDetail unit tests (Issue NMS-19492)
  • Missing EventId changes in Meridian 2025 (Issue NMS-19556)
  • ParseException in log files (Issue NMS-19558)
  • Pollerd is slow to start after async support added (Issue NMS-19538)
  • Realtime graphing doesn't work when the Cortex TSS plugin is used (Issue NMS-19489)
  • Update com.hubspot.jinjava:jinjava library (Issue NMS-19511)
  • Update com.mchange:c3p0 library (Issue NMS-19568)
  • Update com.mchange:mchange-commons-java library (Issue NMS-19569)
  • Update com.squareup.okhttp3:okhttp library (Issue NMS-19525)
Enhancement
  • Offer the fancy new Resource Graphs interface in the sidebar (Issue NMS-19532)
New Feature
  • Karaf Command to Clear Alarms (Issue NMS-19552)
Story
  • OpenNMS fails to start after dropdb due to missing provisiond-configuration.xml (Issue NMS-19565)
Task
  • Backport of Jung depenedncies (Issue NMS-19571)
 2026-03-11T14:44:00Z mershad-manesh tag:github.com,2008:https://github.com/OpenNMS/opennms/releases Release notes from opennms 2026-05-13T13:57:07Z https://www.opennms.com/?p=21225 March 2026 Releases – Meridian 2025.0.4 and 2024.3.7

In March, we released updates to all OpenNMS Meridian versions under active support. Meridian Stable Updates Meridians 2025.0.4 and 2024.3.7 contains a couple of bug fixes, enhancements and new features. For a list of changes, see the release notes: 2024.3.7 2025.0.4

The post March 2026 Releases – Meridian 2025.0.4 and 2024.3.7 appeared first on The OpenNMS Group, Inc..

In March, we released updates to all OpenNMS Meridian versions under active support.

Meridian Stable Updates

Meridians 2025.0.4 and 2024.3.7 contains a couple of bug fixes, enhancements and new features.

For a list of changes, see the release notes:

The post March 2026 Releases – Meridian 2025.0.4 and 2024.3.7 appeared first on The OpenNMS Group, Inc..

 2026-03-11T14:39:03Z Morteza Ershad-Manesh https://www.opennms.com/ https://www.opennms.com/wp-content/uploads/2021/04/OpenNMS_Favicon_36px.png The OpenNMS Group, Inc. 2026-06-05T17:40:02Z tag:github.com,2008:Repository/9377198/meridian-foundation-2025.0.4-1 meridian-foundation-2025.0.4-1

OpenNMS Meridian Foundation 2025.0.4

 2026-03-11T13:51:48Z opennms-bamboo tag:github.com,2008:https://github.com/OpenNMS/opennms/releases Release notes from opennms 2026-05-13T13:57:07Z tag:github.com,2008:Repository/9377198/meridian-foundation-2024.3.7-1 meridian-foundation-2024.3.7-1

OpenNMS Meridian Foundation 2024.3.7

 2026-03-11T13:32:55Z opennms-bamboo tag:github.com,2008:https://github.com/OpenNMS/opennms/releases Release notes from opennms 2026-05-13T13:57:07Z https://www.opennms.com/?p=21208 When TV Imitates IT Reality: What The Pitt’s Hospital Outage Teaches Us About Network Monitoring

If you watched the newest season of The Pitt, you likely felt your stomach drop the moment the hospital’s computer systems went down. The episode perfectly captures the dire consequences of a computer outage in an emergency department, including high-stakes delays and operational turmoil. This dramatic moment mirrors the real challenges hospitals face when their [...]

The post When TV Imitates IT Reality: What <i>The Pitt’s</i> Hospital Outage Teaches Us About Network Monitoring appeared first on The OpenNMS Group, Inc..

If you watched the newest season of The Pitt, you likely felt your stomach drop the moment the hospital’s computer systems went down. The episode perfectly captures the dire consequences of a computer outage in an emergency department, including high-stakes delays and operational turmoil.

This dramatic moment mirrors the real challenges hospitals face when their networks fail. Recent data shows that outages are a persistent and costly threat to hospitals across the U.S.

Hospital Outage Statistics

Major studies examining recent healthcare disruption events found:

Pop Culture Reflects Real Risks

Healthcare IT networks are complex ecosystems: EMRs, imaging devices, nurse call systems, telemedicine systems, patient monitoring systems, and medication delivery platforms all rely on a functioning digital backbone that is often spread across disparate network vendors.

Just like it was depicted in The Pitt, IT failures can affect patient-facing systems, operational tools, and essential clinical communication systems.

This underscores the urgent need for real-time network visibility and proactive outage detection tools.

Why OpenNMS Is the Best Choice for Hospital Network Monitoring

OpenNMS delivers exactly the type of observability that could prevent the kind of cascading failures dramatized in The Pitt—and the ones hospitals experienced in the nationwide outages described above.

1. End-to-End Visibility Across Critical Systems

Hospitals often manage tens of thousands of networked devices. OpenNMS consolidates monitoring into a coherent view, allowing IT teams to detect failures before they disrupt care.

2. Proactive Alerting to Minimize Downtime

With uptime costing upwards of $7,500 per minute, reactive troubleshooting is not sufficient. OpenNMS gives admins the ability to detect issues in real time, helping hospital IT teams isolate and resolve problems quickly.

3. Open Source Transparency + Enterprise Durability

Healthcare organizations benefit from flexibility, auditability, and traceability, combined with enterprise-grade scale, security, and reliability.

4. Designed for Distributed, Multi-Site Healthcare Systems

Whether you're monitoring a single facility or coordinating multiple hospitals and outpatient clinics, OpenNMS scales seamlessly to support complex distributed environments.

If The Pitt's IT Team Had OpenNMS…

With real-time insights, hospitals can drastically mitigate potential outages:

  • Early warnings can identify the malfunctioning services.

  • Proactive alerting strategies keep critical systems online by alerting those who need to know.

  • Staff can maintain continuity of care instead of scrambling blindly.

While it might make for less dramatic television, it makes for significantly better patient outcomes.

Healthcare Needs Reliable Network Monitoring

As both pop culture and real-world statistics show, the cost of downtime in clinical settings is too high. Hospitals require resilient network monitoring platforms to seamlessly access digital clinical tools, protect patient safety, and ensure operational efficiency.

Contact us to learn how OpenNMS delivers the observability, reliability, and speed that modern healthcare demands.

The post When TV Imitates IT Reality: What <i>The Pitt’s</i> Hospital Outage Teaches Us About Network Monitoring appeared first on The OpenNMS Group, Inc..

 2026-02-17T23:25:56Z Jen Fekin https://www.opennms.com/ https://www.opennms.com/wp-content/uploads/2021/04/OpenNMS_Favicon_36px.png The OpenNMS Group, Inc. 2026-06-05T17:40:02Z https://www.opennms.com/?p=21200 February 2026 Releases – Meridian 2025.0.3, 2024.3.6 and 2023.2.5

In February, we released updates to all OpenNMS Meridian versions under active support. Meridian Stable Updates Meridians 2025.0.3, 2024.3.6 and 2023.2.5 contains a couple of bug fixes, enhancements and new features. For a list of changes, see the release notes: 2023.2.5 (Crazy Harry) 2024.3.6 2025.0.3

The post February 2026 Releases – Meridian 2025.0.3, 2024.3.6 and 2023.2.5 appeared first on The OpenNMS Group, Inc..

In February, we released updates to all OpenNMS Meridian versions under active support.

Meridian Stable Updates

Meridians 2025.0.3, 2024.3.6 and 2023.2.5 contains a couple of bug fixes, enhancements and new features.

For a list of changes, see the release notes:

The post February 2026 Releases – Meridian 2025.0.3, 2024.3.6 and 2023.2.5 appeared first on The OpenNMS Group, Inc..

 2026-02-11T16:16:06Z Morteza Ershad-Manesh https://www.opennms.com/ https://www.opennms.com/wp-content/uploads/2021/04/OpenNMS_Favicon_36px.png The OpenNMS Group, Inc. 2026-06-01T16:30:02Z tag:github.com,2008:Repository/9377198/opennms-35.0.3-1 OpenNMS Horizon 35.0.3

Release 35.0.3

Release 35.0.3 contains a couple of bug fixes and enhancements.

Bug
  • Update multiple libraries (Issue NMS-19438)
  • MailTransportMonitor steps all over itself (Issue NMS-8099)
  • Schema for prometheus collector missing from packages (Issue NMS-19269)
  • Update glibc library (Issue NMS-19408)
  • Update glibc-common library (Issue NMS-19410)
  • Update glibc-minimal-langpack library (Issue NMS-19413)
  • Update gnupg2 library (Issue NMS-19334)
  • Update libbrotli library (Issue NMS-19217)
  • Update libpng library (Issue NMS-19157)
  • Update org.bitbucket.b_c:jose4j library (Issue NMS-19434)
  • Update org.lz4:lz4-java library (Issue NMS-19198)
  • Update sqlite-libs library (Issue NMS-19155)
  • Update uglify-js library (Issue NMS-19245)
  • opennms:twin-subscribe missing on minion (Issue NMS-19404)
Enhancement
  • Expose SNMP Trapd queue size metrics via JMX (Issue NMS-19277)
  • Expose SNMP Traps dispatched not just in batch size (Issue NMS-19278)
  • Investigate if we can measure SNMP Traps on the listener (Issue NMS-19279)
  • Provide a unique identifier for Events and Alarms for log tracing across multiple instances (Issue NMS-19402)
  • Provide internal SNMP Trap listener JMX metrics per device (Issue NMS-19403)
Story
  • Show configurable topics for Kafka Producer feature (Issue NMS-19366)
Task
  • Add a copy of COPYING in OpenNMS Core (Issue NMS-19442)
  • Add a script to install and configure rrd for Mac/Ubuntu environments (Issue NMS-19144)
  • Create CentOS 10 install documentation (Issue NMS-19060)
  • Update the link for Version in about page (Issue NMS-19407)
 2026-02-11T16:03:53Z mershad-manesh tag:github.com,2008:https://github.com/OpenNMS/opennms/releases Release notes from opennms 2026-05-13T13:57:07Z tag:github.com,2008:Repository/9377198/meridian-foundation-2025.0.3-1 meridian-foundation-2025.0.3-1

OpenNMS Meridian Foundation 2025.0.3

 2026-02-11T15:16:49Z opennms-bamboo tag:github.com,2008:https://github.com/OpenNMS/opennms/releases Release notes from opennms 2026-05-13T13:37:57Z tag:github.com,2008:Repository/9377198/meridian-foundation-2024.3.6-1 meridian-foundation-2024.3.6-1

OpenNMS Meridian Foundation 2024.3.6

 2026-02-11T14:56:40Z opennms-bamboo tag:github.com,2008:https://github.com/OpenNMS/opennms/releases Release notes from opennms 2026-05-13T13:19:49Z tag:github.com,2008:Repository/9377198/meridian-foundation-2023.2.5-1 meridian-foundation-2023.2.5-1

OpenNMS Meridian Foundation 2023.2.5

 2026-02-11T14:36:01Z opennms-bamboo tag:github.com,2008:https://github.com/OpenNMS/opennms/releases Release notes from opennms 2026-04-08T14:41:12Z https://www.opennms.com/?p=21178 In a World Short on Memory, Lean Network Monitoring Still Matters

Today, the tech industry is grappling with a global memory-chip crunch. Demand for DRAM and NAND is being driven to unprecedented levels by AI infrastructure build-outs, leading to supply tightening and soaring prices. For many organizations, this shortage has real cost and procurement implications. RAM and flash memory have suddenly become expensive and hard to [...]

The post In a World Short on Memory, Lean Network Monitoring Still Matters appeared first on The OpenNMS Group, Inc..

Today, the tech industry is grappling with a global memory-chip crunch. Demand for DRAM and NAND is being driven to unprecedented levels by AI infrastructure build-outs, leading to supply tightening and soaring prices.

For many organizations, this shortage has real cost and procurement implications. RAM and flash memory have suddenly become expensive and hard to source.

In that environment, deploying a heavy, resource-hungry monitoring stack isn’t just difficult; it could be impossible. That’s where the virtues of a lean network monitoring system like OpenNMS come into play.

Lightweight Data Collection

OpenNMS can run effectively in memory-constrained environments. That’s not just our opinion; we’re backing it up with fully open benchmarking that anyone can examine themselves.

As an example, we have been testing OpenNMS performance when OpenNMS Core is used to collect metrics and then forward them to a northbound system via Kafka, and the results speak for themselves. With an OpenNMS core system that has only 8GB of memory allocated for the Java Heap, we can push well over 3600 metrics per second (or 176 metrics per host with over 6000 hosts with our default 5-minute interval collection).

Furthermore, the design of the OpenNMS architecture is flexible, enabling you to put resources where you need them, be that on the OpenNMS Core, the remote collecting Minions, or downstream on your backend databases for metric storage.

Java has a reputation for being a resource hog, and it couldn’t be further from the truth. The fact is that well-architected and well-built Java enterprise applications can be some of the most performant applications in an IT environment. You don’t just have to take our word for it, as one of our long-time community members recently put it: “I used to believe that OpenNMS was a resource hog; I no longer believe so.”

Lean Event Processing: OpenNMS Holds Up

The benchmarks also cover event-driven workloads (like SNMP traps) and high-volume log ingestion (syslog). The “SNMP Traps load testing” and “Syslog load testing” scenarios demonstrate that OpenNMS doesn’t require heavy memory overhead to handle real-world volumes of asynchronous events and log messages.

Specifically for trap processing, with just 8GB of memory for the Java Heap, OpenNMS Core can scale to handle over 2000 traps per second with no loss. That adds up too! A single 8GB (with a paltry 4 CPU cores) instance of OpenNMS could handle up to 172,800,000 traps per day, and that’s without saturating dependencies like PostgreSQL, Kafka, or our remote collectors (Minions).

Start Small, Scale as You Need it to Future-Proof Monitoring Amidst a Memory Crisis

One of the biggest advantages of OpenNMS’s architecture is that you can begin with a modest and lightweight deployment (just a single Core and a PostgreSQL database are all you need), then scale up or out as your monitoring needs grow and change.

Scaling OpenNMS isn’t just dependent on the resources for the OpenNMS core, though; we are reliant on external services like our core PostgreSQL database, message brokers (Kafka), storage, or indexing back-ends. This means that rather than loading everything into a single, memory-heavy box, you can break out the services you need and scale them each as you need to expand your monitoring needs.

In the context of a memory-scarce market, where DRAM prices have surged, and memory supply is expected to remain tight through 2027, this flexibility matters more than ever. You’re not forced to commit to a high-resource server up front. Instead, you can deploy with minimal resources and grow capacity only when and where it's needed.

Why OpenNMS Makes Sense in 2026’s Resource Tight World

  • OpenNMS’s efficient, modular architecture is well-suited to low-memory environments (edge servers, containers, small VMs), yet can still reliably handle SNMP polling, traps, syslog, and other workloads at large scale.

  • When demand grows with more devices, more metrics, and more logs, OpenNMS scales vertically and horizontally by leveraging flexible external services (message queues, databases, time series storage back-ends).

  • In a time when memory is expensive, scarce, and prioritized for AI data centers, that scalability is not just convenient, but strategic.

Ready to see what OpenNMS can do for you? Contact us to set up a demo and learn how OpenNMS’s lean network monitoring system can work for your organization.

The post In a World Short on Memory, Lean Network Monitoring Still Matters appeared first on The OpenNMS Group, Inc..

 2026-01-16T19:44:26Z Marshall Massengill https://www.opennms.com/ https://www.opennms.com/wp-content/uploads/2021/04/OpenNMS_Favicon_36px.png The OpenNMS Group, Inc. 2026-05-28T20:10:01Z tag:github.com,2008:Repository/9377198/opennms-35.0.2-1 OpenNMS Horizon 35.0.2

Release 35.0.2

Release 35.0.2 contains a couple of bug fixes and enhancements.

Bug
  • Event translator problem after upgrade to 35 (Issue NMS-19276)
  • UI : Event config events display gets cut off when label is longer than normal (Issue NMS-19359)
  • WS-Man datacollection failures with new WS-Man Client v1.3.2 (Issue NMS-18072)
Enhancement
  • Enable Kafka Producer to sent separate topics to different Kafka Servers (Issue NMS-19082)
  • FE: Make Severity and Status coulmns sortable on Event Config details UI (Issue NMS-19214)
  • Handle new Event Conf UI due to changes in NMS-19070 (Issue NMS-19182)
  • Improve error handling when Kafka topics don't exist (Issue NMS-19117)
  • JSON parsing SNMP Property Extender (Issue NMS-19147)
Epic
  • Investigate and implement use of a more modern Javascript package manager (Issue NMS-19190)
Task
  • Add support to sort by Severity and Status for eventconf events (Issue NMS-19099)
  • Expose rest endpoint for creating/updating source (Issue NMS-19134)
  • FE: Integrate api for creating/updating the source (Issue NMS-19161)
  • Fix tests that are failing due to missing jrrd2 (Issue NMS-19308)
 2026-01-14T18:33:08Z mershad-manesh tag:github.com,2008:https://github.com/OpenNMS/opennms/releases Release notes from opennms 2026-04-08T14:20:05Z https://www.opennms.com/?p=21170 January 2026 Releases – Meridian 2025.0.2, 2024.3.5 and 2023.2.4

In January, we released updates to all OpenNMS Meridian versions under active support. Meridian Stable Updates Meridians 2025.0.2, 2024.3.5 and 2023.2.4 contains a couple of bug fixes, enhancements and new features. For a list of changes, see the release notes: 2023.2.4 (Dr. Strangepork) 2024.3.5 2025.0.2

The post January 2026 Releases – Meridian 2025.0.2, 2024.3.5 and 2023.2.4 appeared first on The OpenNMS Group, Inc..

In January, we released updates to all OpenNMS Meridian versions under active support.

Meridian Stable Updates

Meridians 2025.0.2, 2024.3.5 and 2023.2.4 contains a couple of bug fixes, enhancements and new features.

For a list of changes, see the release notes:

The post January 2026 Releases – Meridian 2025.0.2, 2024.3.5 and 2023.2.4 appeared first on The OpenNMS Group, Inc..

 2026-01-14T16:39:02Z Morteza Ershad-Manesh https://www.opennms.com/ https://www.opennms.com/wp-content/uploads/2021/04/OpenNMS_Favicon_36px.png The OpenNMS Group, Inc. 2026-05-19T13:50:02Z tag:github.com,2008:Repository/9377198/meridian-foundation-2025.0.2-1 meridian-foundation-2025.0.2-1

OpenNMS Meridian Foundation 2025.0.2

 2026-01-14T15:47:33Z opennms-bamboo tag:github.com,2008:https://github.com/OpenNMS/opennms/releases Release notes from opennms 2026-04-08T14:00:40Z tag:github.com,2008:Repository/9377198/meridian-foundation-2024.3.5-1 meridian-foundation-2024.3.5-1

OpenNMS Meridian Foundation 2024.3.5

 2026-01-14T15:32:03Z opennms-bamboo tag:github.com,2008:https://github.com/OpenNMS/opennms/releases Release notes from opennms 2026-03-11T14:15:28Z tag:github.com,2008:Repository/9377198/meridian-foundation-2023.2.4-1 meridian-foundation-2023.2.4-1

OpenNMS Meridian Foundation 2023.2.4

 2026-01-14T15:16:33Z opennms-bamboo tag:github.com,2008:https://github.com/OpenNMS/opennms/releases Release notes from opennms 2026-03-11T13:51:48Z tag:github.com,2008:Repository/9377198/opennms-35.0.1-1 OpenNMS Horizon 35.0.1

Release 35.0.1

Release 35.0.1 contains a couple of bug fixes and enhancement.

Bug
  • Update confd service-template to match the new compact layout (Issue NMS-19249)
  • Upgrade to OpenNMS 35 on Debian breaks installation (Issue NMS-19228)
New Feature
  • FE: Change Structured Node page pagination values (Issue NMS-19162)
 2025-12-16T22:18:55Z mershad-manesh tag:github.com,2008:https://github.com/OpenNMS/opennms/releases Release notes from opennms 2026-03-11T13:32:55Z tag:github.com,2008:Repository/9377198/opennms-35.0.0-1 OpenNMS Horizon 35.0.0

Release 35.0.0

Release 35.0.0 is the first in the Horizon 35 series.

Introducing new features, including event definitions are now stored in the database, enabling dynamic management without requiring eventd restarts.

Bug
  • Broken stylesheets for links in the legacy web components (Issue NMS-18326)
  • Update commons-fileupload library (Issues NMS-18406, NMS-19083 and NMS-18216)
  • Update activeMQ library (Issue NMS-19085)
  • Clear Key and Auto Clean description is incorrect (Issue NMS-19087)
  • Clicking an alarm in the "Nodes with Pending Alarms" on landing page leads to an alarm page without menu (Issue NMS-18221)
  • EnhancedLinkd OSPF discovery causes RPC deadlock due to blocking nested SNMP GET in callback (Issue NMS-19109)
  • FE: Description is overlapping on search bar (Issue NMS-19027)
  • FE: Admin menu page and global search for event configuration does not point to new event configuration UI (Issue NMS-19102)
  • FE: Cannot reorder columns (Issue NMS-18167)
  • FE: During folder upload duplicate files are being uploaded. (Issue NMS-19116)
  • FE: Ensure plugins menu item is only displayed if plugins are installed (Issue NMS-18285)
  • FE: Integrate api for getting event source by source id (Issue NMS-19073)
  • FE: Node list filters: Various bug fixes (Issue NMS-18226)
  • FE: Search term persists after cleared (Issue NMS-18166)
  • FE: The Add/Update request fails when the event XML includes HTML tags. (Issue NMS-18971)
  • FE: UI not checking roles during route validation (Issue NMS-18533)
  • FE: Update CSP in web.xml for tile provider (Issue NMS-18549)
  • Fix IntegrationAPIIT test failure related to event loading behavior (Issue NMS-19009)
  • Fix flaky test : SituationRestIT (Issue NMS-18205)
  • Fix invalid HTML tags in vendor event configuration examples (Issue NMS-19179)
  • Fix login redirecting to css file (Issue NMS-18175)
  • Flows menu item should display for ROLE_ADMIN as well as ROLE_FLOW_MANAGER (Issue NMS-19100)
  • Inconsistent tile provider configuration (Issue NMS-18274)
  • Inconsistent tile server in the geographical maps (Issue NMS-18290)
  • Incorrect extraction of IPs during SNMP discovery (Issue NMS-18051)
  • Investigate upload failures on eventconf upload page (Issue NMS-19028)
  • Loading bean from BeanUtils concurrently is causing deadlock (Issue NMS-18228)
  • Main Menu Dashboards → Dashboards doesn’t go to Dashboards (Issue NMS-18194)
  • Open Redirect on "redirect" Parameter (Issue NMS-19037)
  • OpenNMS fails to start when SnmpPoller is enabled (Issue NMS-18220)
  • Fix permissions for classifications and Provision cm (Issue NMS-19046 and NMS-19047))
  • Prometheus JMX exporter doesn’t expose database connection pool metrics by default (Issue NMS-18542)
  • Improve input validation on forecast graph page (Issue NMS-19055)
  • Remove unnecessary 2nd click for menus with just one entry (Issue NMS-18193)
  • Remove vertical spacing on top of Node List page (Issue NMS-19103)
  • SCV broken in 34-SNAPSHOT (Issue NMS-18131)
  • SFlow Parser doesn’t respect dnslookupsEnabled=false (Issue NMS-18242)
  • SNMP Configuration page has bad formatting (Issue NMS-18186)
  • Same icons for different menus (Issue NMS-18195)
  • Improve Provision Requisition Name (Issue NMS-19038)
  • Shortcut to set search focus is not working (Issue NMS-18269)
  • Update SCV Rest Service for admin only (Issues NMS-18535, NMS-18548 and NMS-18325)
  • Update activemq-client, activemq-openwire-legacy library (Issue NMS-18224)
  • Update com.hubspot.jinjava:jinjava library (Issues NMS-18343, NMS-19062)
  • Update com.squareup.okhttp3:okhttp library (Issue NMS-19112)
  • Update cups-libs library (Issues NMS-18312, NMS-18336)
  • Update expat library (Issue NMS-18337)
  • Update io.grpc:grpc-netty-shaded library (Issue NMS-19063)
  • Update io.netty:netty-codec-http library (Issue NMS-19142)
  • Update io.netty:netty-codec-http2 library (Issue NMS-18315)
  • Update io.netty:netty-codec-smtp library (Issue NMS-19064)
  • Update java-17-openjdk-headless library (Issue NMS-18102)
  • Update libarchive library (Issues NMS-18230, NMS-18313, NMS-18338)
  • Update okio library (Issue NMS-18215)
  • Update org.apache.zookeeper:zookeeper library (Issue NMS-18037)
  • Update pam library (Issues NMS-18314, NMS-18339)
  • Update python3 library (Issue NMS-18069)
  • Update python3-libs library (Issue NMS-18071)
  • Update sqlite-libs library (Issues NMS-18340, NMS-18356, NMS-18368, NMS-18402, NMS-19110, NMS-19111, NMS-19140)
  • When you click on an alarm the navigation and application header is gone (Issue NMS-18266)
  • Whitespace and menu and navigation header should be ignored (Issue NMS-18268)
  • decodeBER throws exception on PDU with long numeric BER value encoding (Issue NMS-18160)
Enhancement
  • Add REST Endpoint for Viewing, Creating, and modifying Situations (Issue NMS-18004)
  • Add an option to upload all existing files in etc/events (Issue NMS-19029)
  • Cleanup event conf file loading from file system (Issue NMS-18966)
  • Disable loading of events from filesystem (Issue NMS-18295)
  • FE: Delete a specifc event by source and event ID (Issue NMS-18263)
  • FE: Display empty list if no node available (Issue NMS-18214)
  • FE: Reduce whitespace in menu, combine expand/collapse with lock (Issue NMS-18279)
  • Identify a trap with OID instead of variable position (Issue NMS-19070)
  • Improve Confd template for opennms-datasources.xml and documentation (Issue NMS-18757)
  • Investigation of IPFIX config distribution to Minions (Issue NMS-18032)
  • Make Poller service scheduling asynchronous to improve startup time (Issue NMS-18963)
  • Optionally include query and results in reason code of JDBCQueryMonitor (Issue NMS-18335)
  • Expose surveillance categories in a single comma-delimited tag/label (Issue NMS-18238)
  • Remove JRobin implementation in v35 (Issue NMS-17897)
  • Remove TestLoadLibraries from service configuration (Issue NMS-19040)
  • Removed outdated references in shipped config (Issue NMS-18239)
  • Show alarm types as human-readable names (Issue NMS-19090)
  • Simplify opennms-datasources.xml by making factory and class-name attributes optional with defaults (Issue NMS-18964)
  • Simplify service-configuration.xml by removing defaults (Issue NMS-19007)
  • Support EventConf coming from Integration API (Issue NMS-19136)
  • Switch decode string and decode value in event definition user interface (Issue NMS-19089)
Epic
  • Create a Meta-Data context from environment variables (Issue NMS-18531)
  • Support OpenConfig flow to Minion (Issue NMS-18142)
New Feature
  • Add system properties for UI display of date and time (Issue NMS-17992)
  • Delete multiple events from a source. (Issue NMS-18236)
  • Delete one or more sources by ID (also deletes associated events) (Issue NMS-18234)
  • Enable or disable one or more sources (and optionally cascade to their events). (Issue NMS-18233)
  • Expose a REST API to add an event to EventConfSource. (Issue NMS-18324)
  • Expose a REST API to update an event in EventConfSource (Issue NMS-18308)
  • FE: Ability to resize width of side menu (Issue NMS-18289)
  • FE: Add icons for submenus (Issue NMS-18979)
  • FE: Add validation for already uploaded event sources (Issue NMS-18306)
  • FE: Delete a specifc source by its ID (Issue NMS-18262)
  • FE: Display confirmation dialog when deleting EventConf source (Issue NMS-18272)
  • FE: Display confirmation dialog when deleting event in EventConf Source (Issue NMS-18273)
  • FE: Display initial table for events in source details (Issue NMS-18264)
  • FE: Edit an event under a specific source by event and source ID (Issue NMS-18265)
  • FE: Enable/Disable a specific source (Issue NMS-18260)
  • FE: Enable/Disable event under a specific resource (Issue NMS-18261)
  • FE: Hide enable/disable/delete source and events where vendor is opennms (Issue NMS-18318)
  • FE: Hover over menu items opens flyout menu (Issue NMS-18287)
  • FE: Integrate VAceEditor with EventConfigEventEditDrawer to save event in xml format. (Issue NMS-18961)
  • FE: Integrate api for creating an event by source id (Issue NMS-18327)
  • FE: Integrate api for editing an event by source id (Issue NMS-18300)
  • FE: Integrate rest api for getting all events by source ID (Issue NMS-18259)
  • FE: Integrate rest api for getting all sources (Issue NMS-18258)
  • FE: Node List advanced filters drawer (Issue NMS-18044)
  • FE: On Send Events page give an autocomplete to select a Vendor (Issue NMS-19121)
  • FE: Test coverage for ChangeEventConfigSourceStatusDialog.vue (Issue NMS-18968)
  • FE: Test coverage for DeleteEventConfigSourceDialog.vue (Issue NMS-18969)
  • FE: Test coverage for EventConfigFilesUploadReportDialog.vue (Issue NMS-18970)
  • FE: Test coverage for EventConfigUploadFilesTab.vue (Issue NMS-18538)
  • FE: Test coverage for EventConfiguration.vue (Issue NMS-18530)
  • FE: Test coverage for UploadedFileRenameDialog.vue (Issue NMS-18973)
  • FE: Test coverage for eventConfigSourceTable (Issue NMS-18529)
  • FE: Top Expand/Collapse button should maintain state (Issue NMS-18288)
  • FE: Update Event Config pagination values (Issue NMS-19163)
  • Flows menu item displaying at bottom of side menu (Issue NMS-19120)
  • Implement sorting and searching functionality for events of a source (Issue NMS-18552)
  • Move Alarms and Events to top of Monitoring menu (Issue NMS-19119)
  • OpenConfig Flow Streaming: Enable / Disable on Nodes (Issue NMS-18277)
  • OpenConfig JTI gRPC Stream Persists After Channel Closure (Issue NMS-18323)
  • Provide a REST API endpoint to fetch all event conf sources. (Issue NMS-18270)
  • Provide a REST API endpoint to fetch events by sourceId (Issue NMS-18271)
Story
  • Add liquibase changeset for event conf related tables (Issue NMS-18149)
  • Add new REST endpoint "action" to handle alarm actions (Issue NMS-18187)
  • Exclude selfmonitor requisition in the Quick Add Node page (Issue NMS-18184)
  • Expose TwinPublishers on OSGi (Issue NMS-18310)
  • Extend functionality to support alarm action methods (Issue NMS-18188)
  • FE: Event Config details - XML editing (Issue NMS-18209)
  • FE: Event config details page (Issue NMS-18208)
  • FE: Initial EventConf route and scaffolding (Issue NMS-18206)
  • FE: Initial EventConf table (Issue NMS-18207)
  • FE: Refine ADD A NODE page (Issue NMS-18181)
  • FE: Support downloading of events in xml format for a given source (Issue NMS-19051)
  • FE: Upload event config files (Issue NMS-18210)
  • FE: Upload event config files via Rest API (Issue NMS-18211)
  • FE: Validate event XML files before uploading (Issue NMS-18213)
  • FE: Validate eventconfig.xml before uploading (Issue NMS-18212)
  • Fixed file ordering in upload multiple event conf XML files (Issue NMS-18156)
  • Handle new Alarm action config (Issue NMS-18190)
  • Implement API to filter event conf by uei, vendor, source name. (Issue NMS-18154)
  • Implement API to upload single/multiple eventconf files (Issue NMS-18153)
  • Implement JPA entities and repositories (Issue NMS-18150)
  • Migrate all opennms events to DB (Issue NMS-18152)
  • Support Downloading events from a given source in xml format (Issue NMS-19050)
  • Update BeanUtils to remove DefaultLocatorFactory (Issue NMS-18085)
  • Update DefaultEventConfDao with loading from database (Issue NMS-18151)
Task
  • Add existing opennms files in events-defaults folder for reference (Issue NMS-19061)
  • Add OpenConfig Documentation Guide for Minion (Issue NMS-18532)
  • Add documentation for EventConf migration (Issue NMS-19130)
  • Add filters for UEI and Event Label on the EventConf Sources page. (Issue NMS-19081)
  • Add smoke test for upload failures on eventconf upload page (Issue NMS-19044)
  • Change fileOrder values in eventConfSource.sql from ascending to descending order. (Issue NMS-18309)
  • Clean up references to Java 11 (Issue NMS-18227)
  • Cleanup code in uploadEventConfFiles to remove references to eventconf.xml (Issue NMS-19048)
  • DevOps: Use standard install location for RPM and Debian packages (Issue NMS-18317)
  • Docs builds contains errors and warnings (Issue NMS-16500)
  • Enable Static OpenConfig Configuration on Minion for Flow Collection Initiation (Issue NMS-18170)
  • Expose rest endpoint to get events by vendor (Issue NMS-19135)
  • Expose service to Get EventConfSource by sourceID (Issue NMS-19053)
  • FE: Add back notification count bubble on the top menu (Issue NMS-18133)
  • FE: Add support for alarm data in new Add Event UI (Issue NMS-19039)
  • FE: Add support for mask element in new Add Event UI (Issue NMS-19019)
  • FE: Add support for mask varbinds in new Add Event UI (Issue NMS-19020)
  • FE: Add support for varbind decodes in new Add Add Event UI (Issue NMS-19021)
  • FE: Buttons on some pages display over side menu (Issue NMS-17993)
  • FE: Change self-service menu in top menu to be icon-only (Issue NMS-18281)
  • FE: Clean up drawer logic for Add event (Issue NMS-19018)
  • FE: Combine SPA and legacy Vue code into a single project (Issue NMS-18010)
  • FE: Comment-out logic for validating eventconf.xml (Issue NMS-18299)
  • FE: Create New UI for Add Event (Issue NMS-19017)
  • FE: Create UI for adding event conf source (Issue NMS-19133)
  • FE: Date/time on menu should have time on top line (Issue NMS-18200)
  • FE: Display Created Date, Modified Date and uploadedBy in the Event conf detail page. (Issue NMS-19079)
  • FE: Do not display menu on embedded Wallboard page (Issue NMS-18198)
  • FE: Do not display menus on password gate page (Issue NMS-17987)
  • FE: Edit event using new Add Event UI (Issue NMS-19022)
  • FE: Fix CSS bleed into main JSP pages, or have JSP pages use Feather styles (Issue NMS-17976)
  • FE: Fix main Search input - parity with legacy (Issue NMS-17975)
  • FE: Fix smoke and integration tests for legacy pages (Issue NMS-17986)
  • FE: Fix smoke or integration tests for ui (Issue NMS-17985)
  • FE: Fixes to ensure plugins work after menu redesign (Issue NMS-18061)
  • FE: Font references are incorrect (Issue NMS-17984)
  • FE: Geomap on main page displays over side menu (Issue NMS-17995)
  • FE: Get menus working on BSM page (Issue NMS-17970)
  • FE: Get menus working on Ops Board / Wallboard page (Issue NMS-17971)
  • FE: Get menus working on Topology Map page (Issue NMS-17969)
  • FE: Hide add a node button by default (Issue NMS-18196)
  • FE: Implement initial version of top/side menus (Issue NMS-17968)
  • FE: Incorporate new Feather SideNav with customized push content (Issue NMS-18173)
  • FE: Menu on legacy pages should displace main content when expanded (Issue NMS-18135)
  • FE: Move Node Search input (Issue NMS-18043)
  • FE: Move date/time to just to the left of the Notifications control (Issue NMS-18180)
  • FE: Naming updates and consistency in Event Config pages (Issue NMS-19178)
  • FE: Need proper icons for Notifications on/off (Issue NMS-17973)
  • FE: Node List table updates (Issue NMS-18046)
  • FE: Node search should search across more fields (Issue NMS-18047)
  • FE: Remove "User" section from side menu template (Issue NMS-18282)
  • FE: Remove Description field from eventConf sources page (Issue NMS-19080)
  • FE: Remove description column and add hint for uei and event label on the eventConf sources filter input (Issue NMS-19139)
  • FE: Remove description column from event conf source table (Issue NMS-19115)
  • FE: Remove font-awesome icons and dependencies in both ui and ui-components (Issue NMS-17983)
  • FE: Remove restriction of disabling, adding, editing on OpenNMS event conf on source (Issue NMS-19069)
  • FE: Reorder columns using drag and drop (Issue NMS-18168)
  • FE: Replace dropdown in Send Event UI for event selection with autocomplete field (Issue NMS-19077)
  • FE: Replace old URL for Customize Events with new URL (Issue NMS-19065)
  • FE: Save menu expand status in local storage (Issue NMS-18134)
  • FE: Test coverage for ChangeEventConfigEventDialog.vue (Issue NMS-19012)
  • FE: Test coverage for Create Event Config dialog (Issue NMS-19145)
  • FE: Test coverage for DeleteEventConfigEventDialog.vue (Issue NMS-19014)
  • FE: Test coverage for DeleteEventConfigSourceDialog.vue (Issue NMS-19015)
  • FE: Test coverage for EventConfEventCreate.vue (Issue NMS-19074)
  • FE: Test coverage for EventConfigEventTable.vue (Issue NMS-18753)
  • FE: Test coverage for EventConfigTabContainer.vue (Issue NMS-18750)
  • FE: Test coverage for EventConfigurationDetail.vue (Issue NMS-18751)
  • FE: Test coverage for components/EventConfigEventCreate/BasicInformation.vue (Issue NMS-19075)
  • FE: Test coverage for eventConfigDetailStore.ts (Issue NMS-18755)
  • FE: Test coverage for eventConfigStore.ts (Issue NMS-18754)
  • FE: Test coverage for eventConfigXmlValidator.ts (Issue NMS-18745)
  • FE: UI Dependabot updates for August 2025 (Issue NMS-17867)
  • FE: Update Node List column customization (Issue NMS-18045)
  • FE: Update menu organization based on latest UX prototype (Issue NMS-18055)
  • FE: Update search label on source table (Issue NMS-19143)
  • FE: Update the Poweredby/Meridian Stylesheet and images (Issue NMS-18767)
  • FE: Use new Feather SideNav component (Issue NMS-18024)
  • Fe: Test coverage for ChangeEventConfigSourceStatusDialog.vue (Issue NMS-19013)
  • Fix SNMP Config page formatting (Issue NMS-18197)
  • Fix smoke tests to use the new logout mechanism implemented in the menu redesign (Issue NMS-18054)
  • Handle programmatic events from ThresholdController (Issue NMS-19041)
  • Manage OpenConfig Connections via TwinAPI Dynamically (Issue NMS-18178)
  • Menu Redesign: Update all existing documentation (Issue NMS-18176)
  • Menu Redesign: Update documentation (Issue NMS-18140)
  • Move menu template documentation from Operation to Development (Issue NMS-18276)
  • Netty update of indirect dependencies to older version (Issue NMS-16551)
  • OpenNMS UI dependabot updates for Horizon 35, December 2025 (Issue NMS-19177)
  • Profile bulk adding of EventConf and reloading of EventConf into memory (Issue NMS-19072)
  • Refactor EventConfProgrammaticService/EventConfPersistenceService to use some common utils (Issue NMS-19105)
  • Remove Authorization Bypass Logic from gRPC Exporter. (Issue NMS-18075)
  • Remove menu template docs from documentation, move to readme-style file in ui (Issue NMS-18284)
  • Strip folder name when uploading event conf files from a given folder (Issue NMS-19068)
  • Support OpenConfig Connector to minion (Issue NMS-18147)
  • Update SNMP MIB Compiler page to use DB instead of filesystem (Issue NMS-18546)
  • Update Send Event page to use DB instead of filesystem (Issue NMS-18763)
  • Update Ubuntu 24 install documentation (Issue NMS-19122)
  • Update the MenuProvider and Menu Rest Service to use a json template (Issue NMS-17977)
  • Validate if Traps/Syslog messages gets processed properly (Issue NMS-19031)
Upgrade
  • Move test utility classes from source to test directory for better code organization (Issue NMS-19032)
 2025-12-12T14:49:14Z mershad-manesh tag:github.com,2008:https://github.com/OpenNMS/opennms/releases Release notes from opennms 2026-02-11T15:41:02Z https://www.opennms.com/?p=21161 December 2025 Releases – Meridian 2025.0.1, 2024.3.4 and 2023.2.3

In December, we released updates to all OpenNMS Meridian versions under active support. Meridian Stable Updates Meridians 2025.0.1, 2024.3.4 and 2023.2.3 contains a couple of bug fixes, enhancements and new features. For a list of changes, see the release notes: 2023.2.3 (Camilla the Chicken) 2024.3.4 2025.0.1

The post December 2025 Releases – Meridian 2025.0.1, 2024.3.4 and 2023.2.3 appeared first on The OpenNMS Group, Inc..

In December, we released updates to all OpenNMS Meridian versions under active support.

Meridian Stable Updates

Meridians 2025.0.1, 2024.3.4 and 2023.2.3 contains a couple of bug fixes, enhancements and new features.

For a list of changes, see the release notes:

The post December 2025 Releases – Meridian 2025.0.1, 2024.3.4 and 2023.2.3 appeared first on The OpenNMS Group, Inc..

 2025-12-10T16:20:00Z Morteza Ershad-Manesh https://www.opennms.com/ https://www.opennms.com/wp-content/uploads/2021/04/OpenNMS_Favicon_36px.png The OpenNMS Group, Inc. 2026-05-07T19:10:02Z tag:github.com,2008:Repository/9377198/meridian-foundation-2025.0.1-1 meridian-foundation-2025.0.1-1

OpenNMS Meridian Foundation 2025.0.1

 2025-12-10T14:30:08Z opennms-bamboo tag:github.com,2008:https://github.com/OpenNMS/opennms/releases Release notes from opennms 2026-02-11T15:16:49Z tag:github.com,2008:Repository/9377198/meridian-foundation-2024.3.4-1 meridian-foundation-2024.3.4-1

OpenNMS Meridian Foundation 2024.3.4

 2025-12-10T14:12:06Z opennms-bamboo tag:github.com,2008:https://github.com/OpenNMS/opennms/releases Release notes from opennms 2026-02-11T14:56:40Z tag:github.com,2008:Repository/9377198/meridian-foundation-2023.2.3-1 meridian-foundation-2023.2.3-1

OpenNMS Meridian Foundation 2023.2.3

 2025-12-10T13:54:10Z opennms-bamboo tag:github.com,2008:https://github.com/OpenNMS/opennms/releases Release notes from opennms 2026-02-11T14:36:01Z https://www.opennms.com/?p=21141 Meridian 2025: Our Biggest Release Yet

The Most Significant UI Update in Meridian History Meridian 2025 isn’t just another upgrade—it’s the largest release we’ve ever delivered, featuring the most substantial user interface overhaul in our history. We’ve moved from a vertical layout to a sleek horizontal design that organizes workflows into clear modules, reduces clicks, and makes navigation intuitive. This [...]

The post Meridian 2025: Our Biggest Release Yet appeared first on The OpenNMS Group, Inc..

The Most Significant UI Update in Meridian History

Meridian 2025 isn’t just another upgrade—it’s the largest release we’ve ever delivered, featuring the most substantial user interface overhaul in our history. We’ve moved from a vertical layout to a sleek horizontal design that organizes workflows into clear modules, reduces clicks, and makes navigation intuitive. This isn’t just a facelift—it’s about giving you a smoother experience, so you can focus on what matters: keeping your network healthy and your operations running seamlessly.

But that’s not all. Meridian 2025 gives you more flexibility to customize and optimize network flow data. We’ve added support for Elasticsearch 8.x and composable templates, giving you more flexibility to customize and optimize your data workflows. The new ServiceNow plugin makes ITSM integration easier than ever, bridging network monitoring with your broader operational processes. Plus, we’ve introduced virtual appliance options for simplified deployment, enhanced security features like PKCS#12 support, and performance improvements based on your feedback. These updates aren’t just technical—they’re practical, designed to help you work smarter and adapt quickly in a changing network landscape.

Key Highlights

  • Modern UI: Horizontal layout for faster navigation and better workflow organization.
  • Advanced Integration: ServiceNow plugin for seamless ITSM connectivity.
  • Flow processing: Full support for Elasticsearch 8.x and composable templates.
  • Deployment Made Easy: Virtual appliance options for flexible environments.
  • Security & Performance: PKCS#12 support, extended metadata, and key optimizations.
  • Breaking Changes: Removal of JRobin time-series engine for improved scalability.

Ready to Explore More?

Networks are growing more complex every year and monitoring them shouldn’t feel like a chore. Check out the full details in our release notes and see how these updates can transform your network monitoring experience. Meridian 2025 isn’t just an update—it’s your next step toward smarter, more efficient network management.

If you’re ready to upgrade or want to learn more about integration options like ServiceNow, reach out to our team today or send us an email.

The post Meridian 2025: Our Biggest Release Yet appeared first on The OpenNMS Group, Inc..

2025-11-20T19:28:58Z Jen Fekin https://www.opennms.com/ https://www.opennms.com/wp-content/uploads/2021/04/OpenNMS_Favicon_36px.png The OpenNMS Group, Inc. 2026-04-27T20:40:02Z https://www.opennms.com/?p=21134 Thinking About Switching Network Monitoring Platforms? Here’s What You Need to Know

If you’re reading this, chances are your current network monitoring solution isn’t quite cutting it anymore—or maybe it’s cutting too deep into your budget. With recent private equity investments in major players like SolarWinds and Paessler, we’re seeing a wave of changes across the industry. These firms are known for driving growth, but also for [...]

The post Thinking About Switching Network Monitoring Platforms? Here’s What You Need to Know appeared first on The OpenNMS Group, Inc..

If you’re reading this, chances are your current network monitoring solution isn’t quite cutting it anymore—or maybe it’s cutting too deep into your budget.

With recent private equity investments in major players like SolarWinds and Paessler, we’re seeing a wave of changes across the industry. These firms are known for driving growth, but also for restructuring pricing models and streamlining product portfolios. Translation? If you’re a customer, you might be facing steep renewal hikes or reduced support for the features you actually use.

So, if you're considering a switch, you're not alone. And you're not wrong.

Why Companies Are Making the Move

Here are some of the most common reasons we hear from customers who are exploring new platforms:

  • Price hikes without added value: Some vendors are increasing renewal costs by up to 300%.
  • Lack of innovation: Legacy platforms often lag behind in adopting AI, automation, and cloud-native capabilities.
  • Vendor lock-in: Deep integrations can make switching hard, but staying might be harder on your budget and flexibility.
  • Security concerns: With evolving threats, outdated platforms may not offer the visibility or protection you need.
  • Poor support or slow updates: If your vendor isn’t keeping up, your network—and your team—could suffer.

Best Practices for Switching Network Monitoring Platforms

1. Map Your Monitoring Scope

Before migrating, clearly define what needs to be monitored—devices, services, cloud assets, and endpoints. This ensures your new platform can handle your full environment without gaps or overkill.

2. Validate Compatibility and Integrations

Check that the new solution supports your existing infrastructure, protocols (SNMP, WMI, NetFlow, etc.), and integrates with your critical tools (SIEM, ticketing, cloud providers). Avoid surprises post-deployment.

3. Plan for Data Portability

Ensure you can export historical data and configurations from your current system and import them into the new one. Look for platforms that support open standards, APIs, and flexible data ingestion.

4. Test Performance and Scalability

Run a pilot to assess how the new platform handles your network load, alerting logic, and reporting needs. Make sure it scales with your growth—especially if you're hybrid or cloud-heavy.

The Bigger Picture

The network monitoring landscape is shifting. With private equity firms backing major vendors, we expect more consolidation, more pricing changes, and—hopefully—more innovation. But for many customers, that also means re-evaluating their options.

If you’re feeling the pressure, now might be the perfect time to explore a platform that’s built for today’s hybrid environments, offers predictable pricing, and puts customer success first.

OpenNMS is built to meet those needs. Whether you're monitoring thousands of devices across multiple sites or managing a hybrid cloud infrastructure, OpenNMS offers scalable, open-source solutions with powerful automation, deep visibility, and flexible integrations. With transparent pricing and a commitment to community-driven innovation, OpenNMS helps you stay in control—without vendor lock-in or surprise renewals.

We’re here to help you navigate that journey. Contact us to learn more.

The post Thinking About Switching Network Monitoring Platforms? Here’s What You Need to Know appeared first on The OpenNMS Group, Inc..

 2025-11-13T15:53:52Z Kyle Callahan https://www.opennms.com/ https://www.opennms.com/wp-content/uploads/2021/04/OpenNMS_Favicon_36px.png The OpenNMS Group, Inc. 2026-03-30T19:10:01Z https://www.opennms.com/?p=21122 November 2025 Releases – Meridian 2024.3.3 and 2023.2.2

In November, we released updates to all OpenNMS Meridian versions under active support. Meridian Stable Updates Meridians 2024.3.3 and 2023.2.2 contains a couple of bug fixes and enhancements. For a list of changes, see the release notes: 2023.2.2 (Rowlf the Dog) 2024.3.3

The post November 2025 Releases – Meridian 2024.3.3 and 2023.2.2 appeared first on The OpenNMS Group, Inc..

In November, we released updates to all OpenNMS Meridian versions under active support.

Meridian Stable Updates

Meridians 2024.3.3 and 2023.2.2 contains a couple of bug fixes and enhancements.

For a list of changes, see the release notes:

The post November 2025 Releases – Meridian 2024.3.3 and 2023.2.2 appeared first on The OpenNMS Group, Inc..

 2025-11-12T19:49:53Z Morteza Ershad-Manesh https://www.opennms.com/ https://www.opennms.com/wp-content/uploads/2021/04/OpenNMS_Favicon_36px.png The OpenNMS Group, Inc. 2026-03-16T18:20:02Z tag:github.com,2008:Repository/9377198/meridian-foundation-2023.2.2-1 meridian-foundation-2023.2.2-1

OpenNMS Meridian Foundation 2023.2.2

 2025-11-12T19:36:21Z opennms-bamboo tag:github.com,2008:https://github.com/OpenNMS/opennms/releases Release notes from opennms 2026-01-14T15:16:33Z tag:github.com,2008:Repository/9377198/opennms-34.1.0-1 OpenNMS Horizon 34.1.0

Release 34.1.0

Release 34.1.0 contains a couple of bug fixes, enhancements and documentation updates.

Starting with this release when upgrading OpenNMS, custom.properties, config.properties and opennms.properties files will be overridden.

Bug
  • Adding IP Address Range to Discovery Fails (Issue NMS-18537)
  • Comma-separated categories enhancement tries to create empty Prometheus labels (Issue NMS-18976)
  • FE: Top menu can have 2 overlapping dropdowns for self-service and notifications (Issue NMS-18977)
  • Page Sequence Monitor invalid range spec for paramter response-range (Issue NMS-19008)
  • Path Traversal Allowing File Write Outside Intended Directory (Issue NMS-19045)
  • SNMP SET via minion fails - wrong XML adapter in SnmpSetRequestDTO (Issue NMS-19043)
  • Top nav bar style changes between classic and new UI pages (Issue NMS-15000)
  • Update com.fasterxml.jackson.core:jackson-core library (Issue NMS-18357)
  • Update cups-libs library (Issues NMS-18873, NMS-18922, NMS-18939)
  • Update io.grpc:grpc-netty-shaded library (Issue NMS-18782)
  • Update io.netty:netty-codec library (Issue NMS-18346)
  • Update io.netty:netty-codec-http library (Issue NMS-18347)
  • Update io.netty:netty-codec-smtp library (Issue NMS-19025)
  • Update jackson-databind library (Issue NMS-16675)
  • Update libarchive library (Issues NMS-18354, NMS-18366, NMS-18400)
  • Update pam library (Issues NMS-18367, NMS-18381, NMS-18401)
Story
  • Always overwrite opennms.properties in upgrade process (Issue NMS-18201)
Task
  • FE: Menu template fix to remove unwanted menu header (Issue NMS-18773)
  • Update CentOS 9 install documentation (Issue NMS-18547)
  • Update Node List page documentation (Issue NMS-18534)
Enhancement
  • Allow users to control core services via environment variables (Issue NMS-18965)
  • Configurable structured logging output in JSON format (Issue NMS-19016)
  • Give SSLCertMonitor the option to resolve the server-name (Issue NMS-19078)
  • Improve ActiveMQ visualization (Issue NMS-19049)
 2025-11-12T17:10:25Z mershad-manesh tag:github.com,2008:https://github.com/OpenNMS/opennms/releases Release notes from opennms 2026-01-14T16:07:05Z tag:github.com,2008:Repository/9377198/meridian-foundation-2025.0.0-1 meridian-foundation-2025.0.0-1

OpenNMS Meridian Foundation 2025.0.0

 2025-11-12T16:13:26Z opennms-bamboo tag:github.com,2008:https://github.com/OpenNMS/opennms/releases Release notes from opennms 2026-01-14T15:47:33Z tag:github.com,2008:Repository/9377198/meridian-foundation-2024.3.3-1 meridian-foundation-2024.3.3-1

OpenNMS Meridian Foundation 2024.3.3

 2025-11-12T15:53:13Z opennms-bamboo tag:github.com,2008:https://github.com/OpenNMS/opennms/releases Release notes from opennms 2026-01-14T15:32:03Z https://www.opennms.com/?p=21101 October 2025 Releases – Meridian 2024.3.2, 2023.2.1 and 2022.2.1

In October, we released updates to all OpenNMS Meridian versions under active support. Meridian Stable Updates Meridians 2024.3.2, 2023.2.1 and 2022.2.1 contains a couple of security updates, bug fixes and enhancements. For a list of changes, see the release notes: 2022.2.1 (Camelopardalis) 2023.2.1 (Fozzie Bear) 2024.3.2

The post October 2025 Releases – Meridian 2024.3.2, 2023.2.1 and 2022.2.1 appeared first on The OpenNMS Group, Inc..

In October, we released updates to all OpenNMS Meridian versions under active support.

Meridian Stable Updates

Meridians 2024.3.2, 2023.2.1 and 2022.2.1 contains a couple of security updates, bug fixes and enhancements.

For a list of changes, see the release notes:

The post October 2025 Releases – Meridian 2024.3.2, 2023.2.1 and 2022.2.1 appeared first on The OpenNMS Group, Inc..

 2025-11-06T16:18:21Z Morteza Ershad-Manesh https://www.opennms.com/ https://www.opennms.com/wp-content/uploads/2021/04/OpenNMS_Favicon_36px.png The OpenNMS Group, Inc. 2026-03-11T14:40:02Z tag:github.com,2008:Repository/56323430/v2.6.1 v2.6.1

autogenerated runtime build artifacts

 2025-10-28T19:36:49Z opennms-bamboo tag:github.com,2008:https://github.com/OpenNMS/opennms-js/releases Release notes from opennms-js 2025-10-28T19:36:49Z https://opennmsdev.wpengine.com/?p=21090 Empowering Smarter Networks: The Value of the OpenNMS VAR Program and Our New Strategic Alliance with Ni2

In a world where digital infrastructure is the backbone of business, network monitoring is no longer optional—it’s mission-critical. That’s why at OpenNMS, we’re proud to offer a Value-Added Reseller (VAR) Program, a powerful initiative that enables partners to deliver scalable, open-source network monitoring solutions that drive real results. Why Network Monitoring Matters More Than Ever [...]

The post Empowering Smarter Networks: The Value of the OpenNMS VAR Program and Our New Strategic Alliance with Ni2 appeared first on The OpenNMS Group, Inc..

In a world where digital infrastructure is the backbone of business, network monitoring is no longer optional—it’s mission-critical. That’s why at OpenNMS, we’re proud to offer a Value-Added Reseller (VAR) Program, a powerful initiative that enables partners to deliver scalable, open-source network monitoring solutions that drive real results.

Why Network Monitoring Matters More Than Ever

Modern networks are complex, distributed, and constantly evolving. Organizations need real-time visibility into their infrastructure to:

  • Detect and resolve issues before they impact users
  • Optimize performance and resource utilization
  • Ensure compliance and security across hybrid environments
  • Support digital transformation with actionable insights

OpenNMS delivers on all fronts with a flexible, extensible platform that supports everything from fault and performance monitoring to flow analysis and event correlation.

The OpenNMS VAR Program: Built for Partner Success

The OpenNMS Value-Added Resellers are equipped with tools and support to help their customers monitor smarter. The program offers:

  • Access to enterprise-grade OpenNMS solutions tailored to diverse industries

  • Technical training and enablement to ensure expert-level implementation

  • Sales and marketing collaboration to accelerate customer acquisition

  • A community-driven roadmap that evolves with real-world needs

This partnership model allows us to go beyond reselling—we become trusted advisors in our customers’ network operations journey.

A Strategic Alliance with Ni2: Unified Intelligence for Service Assurance

Ni2 is an agile OSS solution that enables the modeling of a Digital Twin—providing a unified, accurate view of physical and logical network, service, and customer relationships. Through integration with OpenNMS, Ni2 contextualizes this data to enable advanced root cause analysis, incident correlation, and triage. This combined approach transforms raw monitoring data into actionable intelligence, helping operators proactively assess service impact, accelerate resolution, and enhance overall service reliability.

Looking Ahead

As networks grow in complexity, the need for intelligent, adaptable monitoring solutions will only increase. Through the OpenNMS VAR Program—and with the added strength of our partnership with Ni2—we’re ready to help organizations take control of their networks and unlock new levels of performance and reliability.

Learn more about OpenNMS’s partnership options or contact us to find out what would work best for your company and your customers.

The post Empowering Smarter Networks: The Value of the OpenNMS VAR Program and Our New Strategic Alliance with Ni2 appeared first on The OpenNMS Group, Inc..

 2025-10-23T16:43:05Z Paul Mayheu https://www.opennms.com/ https://www.opennms.com/wp-content/uploads/2021/04/OpenNMS_Favicon_36px.png The OpenNMS Group, Inc. 2026-02-18T20:40:02Z tag:github.com,2008:Repository/56323430/v2.6.0 OpenNMS.js v2.6.0

What's Changed

  • build(deps): bump the babel-and-eslint group across 1 directory with 9 updates by @dependabot[bot] in #1081
  • build(deps-dev): bump the docs group across 1 directory with 3 updates by @dependabot[bot] in #1084
  • build(deps): bump axios from 1.7.7 to 1.7.9 by @dependabot[bot] in #1089
  • build(deps-dev): bump chai from 5.1.1 to 5.2.0 by @dependabot[bot] in #1091
  • build(deps): bump the babel-and-eslint group across 1 directory with 7 updates by @dependabot[bot] in #1092
  • build(deps-dev): bump webpack-cli from 5.1.4 to 6.0.1 by @dependabot[bot] in #1070
  • build(deps-dev): bump serialize-javascript from 6.0.1 to 6.0.2 by @dependabot[bot] in #1086
  • build(deps-dev): bump @types/jest from 29.5.13 to 29.5.14 in the jest group by @dependabot[bot] in #1093
  • OPG-502: Add fake 'replace' method when toJSON is defined by @synqotik in #1118

Full Changelog: v2.5.11...v2.6.0

 2025-10-23T15:45:42Z mershad-manesh tag:github.com,2008:https://github.com/OpenNMS/opennms-js/releases Release notes from opennms-js 2025-10-28T19:36:49Z https://opennmsdev.wpengine.com/?p=21040 OpenNMS + Grafana: A Unified Solution for Your Monitoring Needs

In today's complex IT environments, monitoring goes beyond just checking if a server is up. We're flooded with data from every corner of our network, from traditional SNMP devices to modern APIs and cloud services. The real challenge isn't just collecting this data—it's making sense of it. While OpenNMS is a powerhouse for discovery, data [...]

The post OpenNMS + Grafana: A Unified Solution for Your Monitoring Needs appeared first on The OpenNMS Group, Inc..

In today's complex IT environments, monitoring goes beyond just checking if a server is up. We're flooded with data from every corner of our network, from traditional SNMP devices to modern APIs and cloud services. The real challenge isn't just collecting this data—it's making sense of it. While OpenNMS is a powerhouse for discovery, data collection, and event management, visualizing that data in a way that provides immediate, actionable insights can be a different story.

This is where Grafana comes in. By pairing OpenNMS as your robust data collection and event engine with Grafana as your flexible and dynamic visualization layer, you can create a unified monitoring solution that is both powerful and intuitive. This post will show you why this combination is a perfect match and how you can get started, using a real-world example to illustrate the process.

Why OpenNMS and Grafana Together?

Think of OpenNMS and Grafana as a tag team. Each tool excels in its own arena, and together, they cover all the bases of a comprehensive monitoring strategy.

  • OpenNMS's Role: The Data Engine. OpenNMS is built for scale and reliability. Its strengths lie in:
    • Extensive Data Collection: It can ingest metrics from almost any source (SNMP, Prometheus, JMX, etc.).
    • Automated Discovery: It can automatically find and provision devices on your network.
    • Event and Alarm Management: It processes events, correlates them into alarms, and notifies the right people.
  • Grafana's Role: The Visualization Layer. Grafana is a front-end designed for one thing: making data beautiful and understandable. Its key features include:
    • Complex Dashboards: Create complex and customizable dashboards (graphs, gauges, heatmaps, etc.).
    • Multi-Source Support: It pulls data from OpenNMS using the OpenNMS Plugin for Grafana and it can even pull directly from some OpenNMS time-series backends, like Prometheus.
    • Advanced Querying: Use queries languages like PromQL or ElasticQL to perform calculations and filter for deeper insights.

By combining the two, OpenNMS handles the heavy lifting of collection and event management, while Grafana provides the perfect interface for visualizing that data in a single, unified view.

Three Common Use Cases: A Quick Look

OpenNMS excels at collecting data from a variety of sources. Here's how you can use OpenNMS collectors with Grafana for some common monitoring needs.

1. JMX for Java Applications ☕️
  • Problem: Monitor Java application performance (e.g., Kafka, Tomcat).
  • Solution: OpenNMS's JmxCollector scrapes metrics like memory usage, garbage collection stats, and thread sizes.
  • Payoff: Visualize real-time heap usage and thread counts in a Grafana dashboard for a clear view of application health.
Dashboard View
2. SNMP for Network Devices📈
  • Problem: Track network bandwidth on routers and switches.
  • Solution: The SnmpCollector polls devices for metrics like interface traffic.
  • Payoff: Create a "Network Traffic" dashboard in Grafana with graphs showing historical bandwidth usage and gauges for real-time traffic.
Dashboard View
3. Alarm/Event Data Visualization 🚨
  • Problem: You need a high-level view of active alarms across your entire network, including historical trends.
  • Solution: OpenNMS processes incoming events and creates alarms. Using the OpenNMS Grafana plugin, you can query this event and alarm data directly.
  • Payoff: Build a "Network Health" dashboard in Grafana with panels showing the count of open alarms by severity, a timeline of recent critical events, and a breakdown of alarm categories.
Dashboard View

Beyond the Use Case: The Bigger Picture

This isn't just a solution for one specific problem. The OpenNMS and Grafana combination can be applied to a wide range of monitoring needs, including:

  • IoT Device Monitoring: Collect and visualize data from sensors and smart devices.
  • Application Performance: Track key metrics for your applications and microservices.
  • Business KPIs: Monitor metrics directly tied to your business's success.
  • Network Operations Center (NOC) Dashboards: Create a single-pane-of-glass view for your entire infrastructure.

This flexibility highlights OpenNMS's evolution from a network monitoring tool to a robust data collection platform, capable of handling virtually any time-series data you need.

Conclusion

If you're looking for a more powerful way to visualize your monitoring data, look no further than the dynamic duo of OpenNMS and Grafana. You can leverage OpenNMS's deep capabilities for data collection and event management while gaining the unparalleled visualization and dashboarding power of Grafana.

Ready to see what else OpenNMS can do for you? Check out our documentation and start building your unified monitoring solution today. Or contact us to set up a demo and learn how OpenNMS Meridian can make it easier to monitor your enterprise network.

The post OpenNMS + Grafana: A Unified Solution for Your Monitoring Needs appeared first on The OpenNMS Group, Inc..

2025-10-14T19:31:24Z Saul Bernabe https://www.opennms.com/ https://www.opennms.com/wp-content/uploads/2021/04/OpenNMS_Favicon_36px.png The OpenNMS Group, Inc. 2026-02-11T16:20:02Z https://www.opennms.com/?p=21027 October 2025 Releases – Meridian 2024.3.2, 2023.2.1 and 2022.2.1

In October, we released updates to OpenNMS Meridian versions under active support. Meridian Stable Updates Meridian 2024.3.2, 2023.2.1 and 2022.2.1 contains a couple of bug fixes and enhancements. For a list of changes, see the release notes: 2024.3.2 2023.2.1 (Fozzie Bear) 2022.2.1 (Camelopardalis)

The post October 2025 Releases – Meridian 2024.3.2, 2023.2.1 and 2022.2.1 appeared first on The OpenNMS Group, Inc..

In October, we released updates to OpenNMS Meridian versions under active support.

Meridian Stable Updates

Meridian 2024.3.2, 2023.2.1 and 2022.2.1 contains a couple of bug fixes and enhancements.

For a list of changes, see the release notes:

The post October 2025 Releases – Meridian 2024.3.2, 2023.2.1 and 2022.2.1 appeared first on The OpenNMS Group, Inc..

 2025-10-08T15:43:46Z Morteza Ershad-Manesh https://www.opennms.com/ https://www.opennms.com/wp-content/uploads/2021/04/OpenNMS_Favicon_36px.png The OpenNMS Group, Inc. 2025-10-08T16:00:01Z tag:github.com,2008:Repository/9377198/opennms-34.0.2-1 OpenNMS Horizon 34.0.2

Release 34.0.2

Release 34.0.2 contains a couple of bug fixes, enhancements and a new feature.

Epic
  • Remove EOL componts from our dependencies and docs (Issue NMS-17902)
Story
  • Remove end of life version CentOS 7/8 (Issue NMS-17901)
  • Exclude selfmonitor requisition in the Quick Add Node page (Issue NMS-18184)
  • Expose TwinPublishers on OSGi (Issue NMS-18310)
Task
  • Menu Redesign: Update all existing documentation (Issue NMS-18176)
  • FE: Do not display menu on embedded Wallboard page (Issue NMS-18198)
  • DevOps: Clean up Some problems were encountered while building the effective model warnings (Issue NMS-18316)
  • FE: Update the Poweredby/Meridian Stylesheet and images (Issue NMS-18767)
  • FE: Menu template fix to remove unwanted menu header (Issue NMS-18773)
Bug
Enhancement
  • Update JMX Prometheus exporter to 1.4.0 (Issue NMS-18544)
  • Improve Confd template for opennms-datasources.xml and documentation (Issue NMS-18757)
New Feature
  • FE: Hover over menu items opens flyout menu (Issue NMS-18287)
 2025-10-08T15:33:44Z mershad-manesh tag:github.com,2008:https://github.com/OpenNMS/opennms/releases Release notes from opennms 2025-12-16T21:58:47Z tag:github.com,2008:Repository/9377198/meridian-foundation-2024.3.2-1 meridian-foundation-2024.3.2-1

OpenNMS Meridian Foundation 2024.3.2

 2025-10-08T13:56:21Z opennms-bamboo tag:github.com,2008:https://github.com/OpenNMS/opennms/releases Release notes from opennms 2025-12-10T15:08:22Z tag:github.com,2008:Repository/9377198/meridian-foundation-2023.2.1-1 meridian-foundation-2023.2.1-1

OpenNMS Meridian Foundation 2023.2.1

 2025-10-08T13:38:44Z opennms-bamboo tag:github.com,2008:https://github.com/OpenNMS/opennms/releases Release notes from opennms 2025-12-10T14:30:08Z tag:github.com,2008:Repository/9377198/meridian-foundation-2022.2.1-1 meridian-foundation-2022.2.1-1

OpenNMS Meridian Foundation 2022.2.1

 2025-10-08T13:10:39Z opennms-bamboo tag:github.com,2008:https://github.com/OpenNMS/opennms/releases Release notes from opennms 2025-12-10T14:12:06Z tag:github.com,2008:Repository/9377198/opennms-34.0.1-1 OpenNMS Horizon 34.0.1

Release 34.0.1

Release 34.0.1 contains bug fixes, enhancements and a new feature..

Bug
  • Update org.apache.zookeeper:zookeeper (Issue NMS-18037)
  • Update commons-fileupload:commons-fileupload (Issue NMS-18081)
  • decodeBER throws exception on PDU with long numeric BER value encoding (Issue NMS-18160)
  • Remove unnecessary 2nd click for menus with just one entry (Issue NMS-18193)
  • Main Menu Dashboards -> Dashboards doesn't go to Dashboards (Issue NMS-18194)
  • Fix flaky test : SituationRestIT (Issue NMS-18205)
  • Update okio library (Issue NMS-18215)
  • Update commons-fileupload library (Issue NMS-18216)
  • OpenNMS fails to start when SnmpPoller is enabled (Issue NMS-18220)
  • Clicking an alarm in the "Nodes with Pending Alarms" on landing page leads to an alarm page without menu (Issue NMS-18221)
  • Updaye activemq-client, activemq-openwire-legacy library (Issue NMS-18224)
  • FE: Node list filters: Various bug fixes (Issue NMS-18226)
  • Loading bean from BeanUtils concurrently is causing deadlock (Issue NMS-18228)
  • Update libarchive library (Issue NMS-18230)
  • Update pam library (Issue NMS-18231)
  • SFlow Parser doesn't respect dnslookupsEnabled=false (Issue NMS-18242)
  • When you click on an alarm the navigation and application header is gone (Issue NMS-18266)
  • Shortcut to set search focus is not working (Issue NMS-18269)
  • Inconsistent tile provider configuration (Issue NMS-18274)
  • Inconsistent tile server in the geographical maps (Issue NMS-18290)
Enhancement
  • Set the RRDTool as the default time series storage implementation (Issue NMS-17883)
  • FE: Display empty list if no node available* (Issue NMS-18214)
  • Please expose surveillance categories in a single comma-delimited tag/label (Issue NMS-18238)
  • FE: Reduce whitespace in menu, combine expand/collapse with lock (Issue NMS-18279)
Task
  • FE: UI Dependabot updates for August 2025 (Issue NMS-17867)
  • FE: Node search should search across more fields (Issue NMS-18047)
  • Clean up references to Java 11 (Issue NMS-18227)
  • Move menu template documentation from Operation to Development (Issue NMS-18276)
  • FE: Change self-service menu in top menu to be icon-only (Issue NMS-18281)
  • FE: Remove "User" section from side menu template (Issue NMS-18282)
  • Remove menu template docs from documentation, move to readme-style file in ui (Issue NMS-18284)
New Feature
  • FE: Top Expand/Collapse button should maintain state (Issue NMS-18288)
 2025-09-10T19:57:36Z mohsindataq tag:github.com,2008:https://github.com/OpenNMS/opennms/releases Release notes from opennms 2025-12-10T13:54:10Z https://www.opennms.com/?p=21008 September 2025 Releases – Meridian 2024.3.1, 2023.2.0 and 2022.2.0

In September, we released updates to OpenNMS Meridian versions under active support. Meridian Stable Updates Meridian 2024.3.1, 2023.2.0 and 2022.2.0 contains a couple of bug fixes. For a list of changes, see the release notes: 2024.3.1 2023.2.0 (Constantine) 2022.2.0 (Mensa)

The post September 2025 Releases – Meridian 2024.3.1, 2023.2.0 and 2022.2.0 appeared first on The OpenNMS Group, Inc..

In September, we released updates to OpenNMS Meridian versions under active support.

Meridian Stable Updates

Meridian 2024.3.1, 2023.2.0 and 2022.2.0 contains a couple of bug fixes.

For a list of changes, see the release notes:

The post September 2025 Releases – Meridian 2024.3.1, 2023.2.0 and 2022.2.0 appeared first on The OpenNMS Group, Inc..

2025-09-10T17:02:47Z Mohsin Cheema https://www.opennms.com/ https://www.opennms.com/wp-content/uploads/2021/04/OpenNMS_Favicon_36px.png The OpenNMS Group, Inc. 2026-02-06T17:30:02Z tag:github.com,2008:Repository/9377198/meridian-foundation-2024.3.1-1 meridian-foundation-2024.3.1-1

OpenNMS Meridian Foundation 2024.3.1

 2025-09-10T16:13:39Z opennms-bamboo tag:github.com,2008:https://github.com/OpenNMS/opennms/releases Release notes from opennms 2025-11-12T16:50:24Z tag:github.com,2008:Repository/9377198/meridian-foundation-2023.2.0-1 meridian-foundation-2023.2.0-1

OpenNMS Meridian Foundation 2023.2.0

 2025-09-10T15:32:11Z opennms-bamboo tag:github.com,2008:https://github.com/OpenNMS/opennms/releases Release notes from opennms 2025-11-12T16:50:24Z tag:github.com,2008:Repository/9377198/meridian-foundation-2022.2.0-1 meridian-foundation-2022.2.0-1

OpenNMS Meridian Foundation 2022.2.0

 2025-09-10T14:48:30Z opennms-bamboo tag:github.com,2008:https://github.com/OpenNMS/opennms/releases Release notes from opennms 2025-11-12T16:13:26Z https://www.opennms.com/?p=20992 Navigating the Future: UI Improvements Coming to OpenNMS

Introduction At OpenNMS, we’ve always believed that powerful functionality should be paired with intuitive design. When Meridian 2025 is released in Q4, we’re excited to introduce a major overhaul of our user interface—one that makes it easier, faster, and more intuitive for users to get value from the platform. Why We’re Updating the UI The [...]

The post Navigating the Future: UI Improvements Coming to OpenNMS appeared first on The OpenNMS Group, Inc..

Introduction

At OpenNMS, we’ve always believed that powerful functionality should be paired with intuitive design. When Meridian 2025 is released in Q4, we’re excited to introduce a major overhaul of our user interface—one that makes it easier, faster, and more intuitive for users to get value from the platform.

Why We’re Updating the UI

The goal of this project is simple: reduce the time it takes for users to go from installation to insight. That means streamlining the experience from login, through node setup, to viewing alarms, outages, and reports.

As Christopher Wong from our UX team put it:
“Getting lost in the very first step does not really help anybody. This project is about clarifying the path—especially for new users—so they know exactly where to go and what to do next.”

This isn’t just about aesthetics. It’s about usability, accessibility, and speed. Research shows that companies who invest in UI improvements see benefits like increased revenue, reduced support costs, and improved customer retention. A well-designed interface builds trust, improves engagement, and helps users accomplish tasks more efficiently.

What’s Changing

Here’s what users can expect:

  • Streamlined Navigation: Menus are now clearer, larger, and better organized.

  • Editable Menu Structure: Menu items are defined in a JSON file, making it easy to update based on user feedback.
  • Improved Node Management: It’s now more obvious where to go to add nodes and view data.
  • Troubleshooting Efficiency: Relevant tools are grouped together to support high-uptime environments.
  • Modern UI Design: We’ve implemented Feather DS components for a consistent, accessible experience.

Christopher explained the challenge this way:
“We had over 40–50 menu items scattered across regular and advanced options. Some features—like Business Service Management—were buried so deep that users couldn’t find them, even after we improved them. This redesign brings those features to the surface.”

Behind the Scenes

This project began in late May 2025, and has been a collaborative effort across UX, engineering, our product teams, and the community. We’ve removed outdated toolkits and moved closer to a pure JavaScript architecture, making future updates easier and more sustainable.

One of the biggest technical challenges was scaling the menu system. As Christopher noted:
“We had to rethink how menus expand. Instead of a long scrollable list, we now use a side-view pop-out—consistent with modern design patterns and easier to navigate.”

UI Updates

We are using the Feather DS design system to power these changes. We built Feather DS an open-source design system under the Apache License, which focuses on simplicity, consistency, and accessibility.

Looking Ahead

These updates mark a major step forward in making OpenNMS more approachable and efficient for both new and existing users. We’re excited to share these updates and look forward to hearing your feedback. This is just the beginning of a more intuitive, powerful OpenNMS experience.

The post Navigating the Future: UI Improvements Coming to OpenNMS appeared first on The OpenNMS Group, Inc..

 2025-08-27T17:59:42Z José Anés https://www.opennms.com/ https://www.opennms.com/wp-content/uploads/2021/04/OpenNMS_Favicon_36px.png The OpenNMS Group, Inc. 2026-01-14T16:40:02Z https://www.opennms.com/?p=20975 August 2025 Releases – Meridian 2024.3.0, 2023.1.28 and 2022.1.33

In August, we released updates to OpenNMS Meridian versions under active support. Meridian Stable Updates Meridian 2024.3.0, 2023.1.28 and 2022.1.33 contains a couple of bug fixes. For a list of changes, see the release notes: 2024.3.0 2023.1.28 (Floyd Pepper) 2022.1.33 (Norma)

The post August 2025 Releases – Meridian 2024.3.0, 2023.1.28 and 2022.1.33 appeared first on The OpenNMS Group, Inc..

In August, we released updates to OpenNMS Meridian versions under active support.

Meridian Stable Updates

Meridian 2024.3.0, 2023.1.28 and 2022.1.33 contains a couple of bug fixes.

For a list of changes, see the release notes:

The post August 2025 Releases – Meridian 2024.3.0, 2023.1.28 and 2022.1.33 appeared first on The OpenNMS Group, Inc..

2025-08-13T19:40:57Z Mohsin Cheema https://www.opennms.com/ https://www.opennms.com/wp-content/uploads/2021/04/OpenNMS_Favicon_36px.png The OpenNMS Group, Inc. 2025-12-16T22:30:02Z