Monitoring approach, not brand, is what separates these options. Check-based monitors run scheduled checks on hosts and services, auto-discovering network monitors find and poll devices for you, and metrics-first systems collect time series you query. Pick the approach that matches your estate, confirm the project is still active, then run two on a copy of your real hosts.
Replacing Checkmk moves agents, check definitions, notification rules and all of your host configuration, so pick the approach before the brand. Nagios, Naemon, Pandora FMS and Opsview run classic checks; LibreNMS, Observium and PRTG discover and watch network devices; Prometheus is metrics-first; and Centreon presents itself as an observability platform. Here's where I'd start.
The advice I'd give before you replace a monitoring server
Match the approach to what you're watching. If most of your estate is servers and services with known health checks, stay with a check-based monitor and you'll recognise the model straight away. If it's switches, routers and appliances, an auto-discovering network monitor cuts the manual setup. If your applications already expose metrics, a metrics-first system fits better than bolting checks on top.
Then check the project is alive. A monitoring tool sits under everything else you run, so you want a current release, readable docs and a home that's clearly still maintained. A quiet repository matters more for a monitor than for most tools, because you may only find out it's stale when something breaks and the plugin you need isn't being fixed.
When a familiar monitoring name disappears
Zenoss isn't on this list. Its old web address now lands on a Virtana Service Observability page, so the name has been folded into another company. In a category full of long-lived open source names, that's a useful warning: before you pick, check that the project has a current release and an active home, not just a page that ranks for its old name.
Checks, discovery, metrics and commercial suites
Check-based monitors ask each host and service a question on a schedule and alert on the answer. They're the most familiar model if you're leaving Checkmk, and your existing checks give you a ready-made test plan.
Network monitors scan your network, find devices and start polling them with little manual setup. They shine on switches, routers and appliances and are lighter on application checks. My network monitoring software guide goes further into this group.
Metrics-first systems collect numbers over time and let you query and alert on them, which suits modern services that already publish metrics. Commercial suites trade some flexibility for support contracts and a single vendor to call. If you'll put dashboards on top of your metrics, my Grafana alternatives cover that layer.
Build or maintain a monitoring tool that fits one of these approaches? Tell me about it for the next review.
Approach and free use for each monitor
| Tool | Approach | Free option on its site |
|---|---|---|
| Centreon | Observability platform | Not stated |
| LibreNMS | Network discovery | Free and open source |
| Naemon | Check-based | Not stated |
| Nagios | Check-based | Free and open source |
| Observium | Network discovery | Free and open source |
| Opsview (ITRS) | Check-based, commercial | Not stated |
| Pandora FMS | Check-based | Free trial named |
| Prometheus | Metrics-first | Free and open source |
| PRTG Network Monitor | Network monitoring | Not stated |
Nine monitoring tools by name
In no particular order beyond the alphabet. The quoted taglines are the makers' own words, not test results.
Centreon
Best for: One view across infrastructure, cloud, network and digital experience monitoring. Its tagline: observability 'from edge to cloud'.
LibreNMS
Best for: Network teams on a PHP and MySQL stack who want devices discovered automatically, which is how the project describes itself.
Naemon
Best for: Watching the state of networks and applications with a check-based model. Its tagline: 'fast, stable and innovative'.
Nagios
Best for: Self-hosting monitoring for servers, networks and applications under a GPL licence. Its tagline: 'the industry standard in open source IT monitoring tools'.
Observium
Best for: Estates with Cisco, Juniper, Dell and Linux devices, which the vendor names. Its tagline: 'expand visibility, ease planning and improve reliability'.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
Opsview (ITRS)
Best for: Enterprises wanting commercial infrastructure monitoring backed by ITRS. Its tagline: 'discover everything and monitor anything'.
Pandora FMS
Best for: Distributed environments where user experience gets monitored too. Its tagline: 'the all-in-one flexible monitoring solution'.
Prometheus
Best for: Querying time series metrics through a dimensional data model and the project's own query language.
PRTG Network Monitor
Best for: Analysing a whole IT infrastructure from one product. Its tagline: 'complete infrastructure control, deployed today'.
A week of real hosts on two systems
Clone a slice of your real estate, say a few servers, a switch or two and one busy application, and point two candidates at it for a week.
- Count the steps it took to get the first host reporting, and then the steps for the tenth.
- Rebuild your three noisiest alerts and see which tool lets you quieten them without hiding real problems.
- Test notifications end to end: email, chat and whoever is on call.
- Stop a service on purpose and time how long each tool takes to tell you.
- Read what an upgrade involves in the docs, before you ever need one.
Whichever one you keep, run it alongside the old server until every host and check has moved, then switch the old one off. Keep a list of every host and check as it moves across; a monitor that silently lost one service in the move is worse than no monitor, because everyone assumes it's covered.
Want your tool on this list? Featured spots and reviews here are paid partnerships. Here's how to partner with me.
Frequently asked questions
Is a metrics system a replacement for check-based monitoring?
It can be, but it works differently. Metrics systems collect numbers over time and alert on rules you write, while check-based tools ask hosts and services whether they're healthy. You can run both side by side.
Can I reuse my existing check plugins?
Some check-based tools accept plugins in a common format, but don't assume yours will run. Test your most important custom checks on the candidate before you plan the move.
How do I know an open source monitoring project is still active?
Look for a recent release, recent commits in the source repository, and issues that get replies. A homepage that still matches the project name is a good sign too.
Do I need an agent on every server?
It depends on the tool and what you're checking. Some collect data through agents, others poll over SNMP or scrape metrics endpoints. Check each project's docs for the method it uses.
Should network and server monitoring live in one tool?
One tool means one place for alerts and fewer logins. Two specialised tools can go deeper in each area. If you split them, make sure alerts from both reach the same on-call route.
