Monitoring craft

Nagios to RMM without a rip-and-replace: plugins, NagiosQL import, auto-discovery

A regional MSP has a Nagios server that has run since 2011. The senior technician who wrote check_mysql_repl left in 2019; the plugin still runs every five minutes against eleven database pairs and has caught three split-brains since. The owner wants remote desktop, patching, and a way for the juniors to fix things without an SSH key to every box. Every RMM demo so far has begun with “you would replace Nagios”, which means the plugin, the thresholds and the 1,480 service definitions go in the bin. So the estate stays on Nagios, and the juniors keep asking for the keys.

Why do Nagios shops resist RMM?

Because the pitch starts by discarding the one thing they have that most RMM buyers do not: fifteen years of checks that encode exactly what matters on their estate. The reason they stay on Nagios is not nostalgia. It is that nobody has offered them a path that keeps the checks and adds the rest.

That path exists, and it has three parts: the plugins keep running, the configuration moves rather than being re-keyed, and discovery takes over the part Nagios never did well. The order matters. You gain remote access and governed automation on day one; you do not lose a single check to get them.

Do the plugins still run?

Yes. Guardian RMM runs standard Nagios plugins as checks. Your check_http, check_disk and the custom ones your predecessor wrote in 2014 keep working, on the same hosts, with the same thresholds, now with a browser terminal and remote desktop beside them. The agent runs them from inside the host, so the plugin sees what it always saw. For the devices that cannot run an agent, a collector can watch ports, HTTP endpoints, SSH and NRPE from the outside, which covers the remote-plugin habit too.

How does the configuration move?

NagiosQL configurations import directly: hosts, host groups, services and contacts. You are not re-keying an estate; you are moving it. The 1,480 service definitions arrive as 1,480 checks, in their groups, with their contacts. Then discovery starts on the same hosts and finds the checks nobody wrote.

What does discovery add that the config never had?

Fifty-eight detection plugins find what is actually running on each host (Apache, MySQL, PostgreSQL, MariaDB, Postfix, Suricata, IIS, Active Directory, DNS, DHCP, Hyper-V, SQL Server and more) and create a check per real resource, each bound to an action that can repair it. The checks you used to write by hand appear on their own, and the ones you forgot appear too: the certificate that expires in 54 days, the mount nobody documented, the systemd unit that was added in a change window and never monitored. We walk through what the plugins find, group by group, in a check per real resource.

imported, then discovered
NagiosQL import: 212 hosts · 1,480 services · 31 host groups
plugins running: check_http, check_disk, check_mysql_repl (custom)
discovery added: 340 checks nobody had written (certs, mounts, units)
each new check bound to an action: renew, vacuum, restart, verify

What do you gain that Nagios never had?

Remote access with no inbound ports. A real PTY on the far end, not a command runner, and remote desktop for Windows, macOS and Linux, through the agent’s one outbound socket. Every session is audit-logged: operator, host, mode, start and stop. Credentials come from Guardian Vault and are injected server-side, so the junior connects without ever being shown the password.

Patching by category. Security, critical, driver, feature, definition or optional, with a reboot policy per job and a preview of the fleet filter before it runs.

Governed automation. Workflows that detect, repair and verify, on demand, on a schedule or on the alert, and that stop for a human before anything destructive. The plan, the risk of each step and the exact command are shown before it runs.

Alerting that does not lie. Flap damping, recovery bursts held back, silence detection, quiet hours with a break-through, and every suppression recorded with its reason. The four mechanisms are in why did that page anyone?

What changes on the network?

Nothing inbound. The agent dials out over TLS on port 443 and keeps one authenticated socket open; nothing listens on a managed endpoint. A Nagios estate usually has an NRPE listener on every host and an SSH key ring that someone reconciles when a technician leaves. Both go away. The agent does need to validate the server certificate, and an intercepting proxy that re-signs TLS is the usual cause of a client that will not connect, so tell the firewall team before the first install rather than after.

What about the devices that cannot run an agent?

Switches, firewalls, printers and appliances are reached from the outside by a collector: one agent on that network, promoted to watch the rest. A collector can tell you whether a device is up and page you when it is not, watch ports and HTTP endpoints, poll it over SNMP and receive its traps, scan it for vulnerabilities from the network, and map what it is plugged into via LLDP and CDP. Here is the limitation, stated plainly: a collector cannot read CPU, memory or process detail from inside, cannot inventory hardware or software, cannot run a script, and cannot open a terminal or a desktop session. Those need the agent installed, and on a printer that is never going to happen.

What this costs you if you stay

Two consoles: Nagios for the alert and something else for the fix, with a hostname copied from one to the other on every ticket. Call it a few minutes per ticket, per technician, per day, for as long as the two tools stay apart. The SSH key ring is a reconciliation every time someone joins or leaves. And the checks nobody wrote are the outages the client finds first, because Nagios only ever knew what it was told.

What to plan for

Signed installers cover Windows (64-bit, server and desktop), macOS on Intel and Apple Silicon, and Linux on Ubuntu 22 and 24, Rocky 9 and 10, CentOS Stream 9 and SUSE 16. There is no ARM Linux build, and distributions outside that list are not packaged; if yours matters, ask and we will tell you whether it is realistic. Patching covers operating system updates rather than third-party application catalogues. Start with one host: install the agent, import the NagiosQL config for that host, and compare what discovery adds against what you had written.


Migrate one host first

Import your NagiosQL config into the trial and watch discovery add the checks you never wrote. Fourteen days, no card.