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:
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:
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:
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.




