Nagios is the tool that defined infrastructure monitoring as a discipline: a scheduling engine that runs small check programs on an interval, interprets their exit codes, and notifies someone when a host or service leaves its expected state. It does not store rich time-series or parse logs - it answers a narrower, older question reliably: is this thing up, and is this metric within bounds? Decades after its release, the check-plugin model it established underlies a large share of monitoring tools, including the ones that replaced its static config files with auto-discovery.

The check-plugin contract

The genius of Nagios is a tiny contract any program can satisfy. A check plugin runs, prints one line of human-readable status, and exits with a code that Nagios reads as state: 0 OK, 1 WARNING, 2 CRITICAL, 3 UNKNOWN. Optional performance data after a | on the output line carries the numeric values. Because the contract is just exit codes and stdout, you can write a check in any language in minutes, and a vast community library of plugins already covers disks, ports, certificates, databases, and APIs.

$ /usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /var
DISK WARNING - free space: /var 3500 MB (18% inode=92%); | /var=15800MB;18000;20000;0;20480
$ echo $?
1

Hosts, services, and notifications

You describe the world in object-definition config files: hosts, the services to check on each, the command that performs each check, and the contacts to notify. A service definition binds a host to a check command and a schedule, with thresholds passed as arguments. Notifications escalate through contact groups and time periods, and "flapping" detection suppresses alerts when a service rapidly toggles state.

define service {
    host_name              db-primary
    service_description    Disk /var
    check_command          check_nrpe!check_var_disk
    check_interval         5
    retry_interval         1
    max_check_attempts     3
    notification_interval  30
    contact_groups         dba-oncall
}

Frequently asked questions

How does a Nagios check report status? The plugin exits with a code Nagios maps to a state - 0 OK, 1 WARNING, 2 CRITICAL, 3 UNKNOWN - and prints a status line, optionally with performance data after a pipe character.

Why is Nagios still relevant? Its exit-code plugin contract is simple, language-agnostic, and backed by a huge plugin library, so it remains a dependable up/down and threshold checker across data centers and underpins many later tools.

What is check_nrpe? The Nagios Remote Plugin Executor - it runs check plugins on a remote host and returns the result to the central Nagios server, the standard way to monitor metrics local to a machine.

What does Nagios not do well? Rich metric storage, dashboards, and log analysis. It is a state checker and notifier; pair it with a time-series database and a log platform for full observability.

See the monitoring & logging overview and compare with Datadog.