Nagios Core

Last reviewed Sep 13, 2026 · 794 words

I would not start a new monitoring deployment on Nagios Core in 2026, and I would still run it if a working Nagios setup already existed and the alternative was migration for its own sake. Both positions are defensible because Nagios Core is two different things: an ageing scheduler with a CGI web interface and a configuration model from 1999, and the plugin interface that every serious monitoring tool since has adopted. The plugins are the durable asset. The engine is the part you can replace.

Everything is a text file, and that is the point

Nagios has no database. Hosts, services, commands, contacts, time periods and escalations are define blocks in .cfg files under /usr/local/nagios/etc/objects/, loaded at start and rechecked with nagios -v /usr/local/nagios/etc/nagios.cfg. A minimal host and service look like this:

define host {
    use             linux-server
    host_name       nas01
    address         192.168.1.20
}

define service {
    use                 generic-service
    host_name           nas01
    service_description Root disk
    check_command       check_nrpe_disk_root
}

Templates via use and hostgroups keep this from becoming thousands of lines, and because it is plain text the whole configuration lives in git, is diffed in pull requests, and can be generated by whatever produces your inventory. That is the property people who stay on Nagios cite first. The cost is that every change requires a config reload and a verify step, and there is no UI for adding a host; the web interface is for reading state, not writing config.

The plugin interface is why it is still everywhere

A Nagios plugin is any executable that prints one line and exits 0, 1, 2 or 3 for OK, WARNING, CRITICAL or UNKNOWN, with optional performance data after a pipe. That is the entire specification, and it is why there are thousands of them: check_http, check_disk, check_ping, check_smtp and the rest of the official plugins package, plus community checks for every database, appliance and API you own. Remote execution goes through NRPE, an agent that runs plugins on the target and returns the result, or the newer NCPA agent. Every one of those plugins runs unchanged on Icinga 2, Naemon, Checkmk and Zabbix, so plugin work is never wasted whichever engine you pick.

The install is the part nobody enjoys

Distribution packages exist but lag, so the documented path is a source build: fetch the tarball, ./configure, make all, make install, then the plugins as a separate build, then Apache with the CGI module and an htpasswd file for the nagiosadmin user. Budget an afternoon. The catalogue's "Hard" rating is about this and about the config learning curve, not about resource use; a Nagios server watching 200 hosts idles in 512 MB of RAM. Community Docker images bundle Apache, the core and the plugins and are the sensible route for a lab, with the etc directory mounted so your config outlives the container.

Alerting is flexible and looks its age

Notifications are commands too: a contact has a service_notification_commands entry that calls a script with the alert as environment variables, so email, SMS, a chat webhook or a pager are all one script away. Escalations, time periods, acknowledgements, scheduled downtime and flap detection are all there and have been for 20 years. The web interface shows it all in a frames-based layout that has not fundamentally changed since the early 2000s; it works, it is fast, and nobody chooses Nagios for it.

When a different engine is the right answer

Icinga 2 started as a Nagios fork, runs the same plugins, replaced the config format with a proper language, added a REST API and a modern web interface, and is where I would point anyone who likes the Nagios model. Naemon is the conservative fork that kept the config format and fixed the engine. Checkmk wraps a Nagios-compatible core in agents that discover services automatically, which removes most of the config writing. Zabbix is the different tradition: a database, templates, SNMP, and a UI you configure from. And for a homelab that needs "is it up and is the disk full", Uptime Kuma covers 80 percent of the need in 5 minutes.

What I'd do

Existing Nagios that works: keep it, put the config in git if it is not already, and move to Naemon only if a bug forces it. New deployment where the text-file, plugin-driven model appeals: Icinga 2 from the start, with the same plugins and NRPE-style agents. New deployment where nobody wants to write check definitions: Checkmk. Nagios Core itself I would install only to learn the model that the other three inherited, which remains a good week's education for anyone who runs servers.