The agent goes onto web-03 at 14:20. Nobody has written a check for it. By 14:25 the console lists an ext4 root at 412 GB with a disk check and a journal-vacuum action attached, a TLS certificate that expires in 54 days with an expiry check and a renewal action, a 1 Gb/s link with a link-state check, and a SMART status check on the drive. The technician who installed it had only come to add the host to a group. She leaves with a list of things about the box that were not in the documentation, one of which, the certificate, would have become a ticket in two months.
A detection plugin is the part of the agent that knows how to recognise one kind of resource on a host and what a sensible check for it looks like. There are 58 of them. Discovery is not a port scan: a port scan tells you 3306 is open; a detection plugin tells you MySQL is running, builds the checks a MySQL host needs, and binds each one to the action that repairs its usual failure. The result is a check per real resource rather than a template applied to a hostname.
That distinction is the whole point. A template monitors what someone assumed was on the host. Discovery monitors what is there, including the resources added in a change window that nobody wrote down. We put it another way on the product page: install it and it already knows.
The list below groups them by kind, with one concrete finding and the action bound to it. It is not the complete catalogue; it is the shape of it.
Services and units. Apache, MySQL, MariaDB, PostgreSQL, Postfix, Suricata, IIS and systemd units. A MySQL host gets checks for connectivity, query performance and replication status, bound to an action that restarts the service if it is down and verifies the fix.
Storage. Mounts and drives. The ext4 root on web-03 gets a disk check bound to a journal vacuum; the drive gets a SMART status check.
Certificates. A TLS certificate found on the host gets an expiry check bound to a renewal action, which is how the 54-day certificate stops being a ticket in two months.
Network. Link state on the host’s interfaces, and SNMP devices (v2c and v3, with trap handling) reached through a collector.
Windows roles. Active Directory, DNS, DHCP, IIS and SQL Server, each with the checks that role needs.
Hypervisors. Hyper-V, checked as a host in its own right rather than as a Windows box that happens to be busy.
Every check carries the action that fixes its usual failure, so the alert and the repair are one record rather than a lookup. Disk full carries the vacuum. Certificate expiring carries the renewal. Service down carries restart-and-verify. When the check fails, the action is what the workflow proposes, and workflows run on demand, on a schedule, or in response to the alert.
Proposes is the word. Before any action runs you see the plan: the objective, each task, its risk level and the exact command. You approve every step, approve the plan once, or let scheduled work you already trust run unattended, and destructive commands stop for a human even then. You can skip a task, reorder the plan, redirect it or stop it without starting over. The approval model has its own post in three approval modes, and the disk example is worked through in web-03 is out of disk.
Not as deep, and we would rather say so than let a demo imply otherwise. Switches, firewalls, printers and appliances cannot run an agent. Promote one agent on that network to a collector and it watches the rest from the outside. The difference between what a collector sees and what an agent sees is the difference between the outside and the inside of the machine.
The same split applies to vulnerability scanning: agents scan themselves in depth, and agentless targets are scanned across the network, which is shallower. A finding on either is enriched with CVSS, exploit-prediction scoring and the CISA known-exploited list, and tracked across rescans.
The 58 plugins cover the common resources. Your line-of-business application is not one of them, so you write the check yourself. Remediation actions are written in Python, with separate implementations for Linux, Windows and macOS or a common cross-platform one. You add them to workflows like any built-in action. Custom checks automatically register with the AI system, the same one that matches recognised requests to vetted actions without a model call, and results carry status, metrics and optional remediation actions, so a custom check looks and behaves like a discovered one.
That is how a Nagios shop keeps its 2014 plugin and gains a repair for it: the plugin stays the check, and a Python action becomes the fix bound to it. The migration path is in Nagios to RMM without a rip-and-replace.
Writing checks by hand is an hour per new host on a good day, and the checks you forget are the ones that go silent unnoticed, which is a different post: why did that page anyone? The reconciliation is the monthly walk through the device list looking for the host that is monitored but not documented, or documented but not monitored, which is also its own post: your device list is lying. The outage the client finds first is the certificate. It is always the certificate.
Install the agent on a single server. Within minutes it will have found what runs on it, built the checks, and told you something you did not know.