Nagios Monitoring: NRPE, Checks & Alerting

Monitoring only earns its keep if it tells you a service is down before a customer does, and tells the right person, not a channel everyone has muted. Nagios Core has been the reference implementation of that idea since 2002: a lightweight scheduler that runs small, single-purpose plugins against hosts and services, tracks their state, and fires notifications when that state changes. It is not the newest tool in this space, but it is the one you will find running quietly in the largest number of production data centers — which makes it a skill worth having even if your next job runs Prometheus.

This guide covers Nagios the way you would actually deploy it: a central Nagios server, the NRPE agent on every monitored host so checks that need local visibility (disk, load, processes) can run where the data actually is, and alerting that reaches a human over email via Postfix — with a note on wiring the same alert into Slack. By the end you will be able to stand up monitoring for a small fleet of Linux servers from scratch and explain every line of the resulting config.

Who this is for

• Linux administrators who need server/service visibility without a heavyweight metrics stack.
• Engineers supporting a fleet of VMs where "is it up" matters more than time-series dashboards.
• Anyone prepping for interviews where classic monitoring concepts (active/passive checks, NRPE, escalations) come up.

Have the following ready before working through the installation and configuration sections:

Active vs. passive checks

In an active check, Nagios initiates the check on its own schedule — it runs a plugin (locally, or remotely via NRPE) and waits for the result. This is the default and covers the vast majority of checks: disk space, load, HTTP status, ping.

In a passive check, the monitored host (or an external process) pushes a result intoNagios instead of Nagios asking for it — usually via the external command file or NSCA. This suits checks Nagios can't easily schedule itself: results from a batch job, a security scanner, or a check that only makes sense to run from inside an application's own deploy pipeline.

Check intervals and state changes

Every service definition has a normal_check_interval (how often to check when the state is stable) and a retry_check_interval(a faster interval used while a problem is unconfirmed). A check that returns non-OK doesn't alert immediately — it enters a SOFT state and Nagios re-checks it max_check_attempts times at the retry interval. Only after it fails that many times in a row does it become a HARD state and trigger a notification. This exists specifically to absorb one-off blips (a slow DNS lookup, a momentary CPU spike) without paging anyone.

The four states

A typical deployment has one Nagios server polling many monitored hosts. Checks that only need external visibility (ping, HTTP, TCP port) run directly from the server. Checks that need to see inside the host — disk usage, load average, process counts — run through the NRPE (Nagios Remote Plugin Executor) agent installed on each monitored host, which executes a local plugin and returns just the result over an encrypted connection on TCP port 5666.

Install Nagios Core and the standard plugins package on the monitoring server itself. Package names and paths differ slightly between distribution families.

# Update package index
sudo apt update

# Nagios Core, the standard plugin bundle, and Apache for the web UI
sudo apt install -y nagios4 nagios-plugins-contrib apache2

# Set the web UI admin password (user: nagiosadmin)
sudo htpasswd -c /etc/nagios4/htpasswd.users nagiosadmin

# Enable and start
sudo systemctl enable --now nagios4
sudo systemctl enable --now apache2

# Config lives under /etc/nagios4, plugins under /usr/lib/nagios/plugins

Install and configure NRPE on each monitored host

NRPE is installed on the monitored host, not the Nagios server. It runs local plugins on request and needs an explicit allow-list of which IPs may query it.

# Debian/Ubuntu
sudo apt install -y nagios-nrpe-server nagios-plugins-contrib

# RHEL/Rocky (EPEL)
sudo dnf install -y epel-release nrpe nagios-plugins-all

Edit /etc/nagios/nrpe.cfg (Debian: /etc/nagios/nrpe.cfg, RHEL: same path) to allow the Nagios server's IP and define the commands it's allowed to run:

# Only accept connections from the Nagios server
allowed_hosts=127.0.0.1,10.0.0.10

# Bind address and port (default is fine for most setups)
server_port=5666

# Allow arguments passed from the server in command definitions
dont_blame_nrpe=1

# Command definitions this host will answer to
command[check_disk]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /
command[check_load]=/usr/lib/nagios/plugins/check_load -w 5,4,3 -c 10,8,6
command[check_users]=/usr/lib/nagios/plugins/check_users -w 5 -c 10
command[check_zombie_procs]=/usr/lib/nagios/plugins/check_procs -w 5 -c 10 -s Z
command[check_total_procs]=/usr/lib/nagios/plugins/check_procs -w 250 -c 400

sudo systemctl enable --now nagios-nrpe-server   # Debian/Ubuntu
sudo systemctl enable --now nrpe                 # RHEL/Rocky

# Open the NRPE port to the Nagios server only
sudo ufw allow from 10.0.0.10 to any port 5666 proto tcp     # Ubuntu
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.0.0.10" port protocol="tcp" port="5666" accept'
sudo firewall-cmd --reload   # RHEL

Define the NRPE command on the Nagios server

On the Nagios server, one reusable command object wraps the check_nrpe plugin so it can be referenced by host name and remote command name from any service definition:

define command {
    command_name    check_nrpe
    command_line    /usr/lib/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
}

Define hosts

define host {
    use             linux-server
    host_name       web01
    alias           Web Server 01
    address         10.0.0.21
    max_check_attempts   3
    check_period    24x7
    notification_interval  30
    notification_period    24x7
}

define host {
    use             linux-server
    host_name       db01
    alias           Primary Database
    address         10.0.0.22
    parents         web01
    max_check_attempts   3
    check_period    24x7
    notification_period    24x7
}

Define services

define service {
    use                     generic-service
    host_name               web01
    service_description     Disk Usage /
    check_command            check_nrpe!check_disk
    normal_check_interval    5
    retry_check_interval     1
    max_check_attempts       3
}

define service {
    use                     generic-service
    host_name               web01
    service_description     HTTP
    check_command            check_http
    normal_check_interval    2
    retry_check_interval     1
}

define service {
    use                     generic-service
    host_name               web01
    service_description     Current Load
    check_command            check_nrpe!check_load
    normal_check_interval    5
}

Define contacts, contact groups, and notification periods

Contacts control whogets notified, through which command, during which hours — this is the piece that separates "monitoring exists" from "monitoring actually reaches someone":

define contact {
    contact_name                    jsmith
    alias                           J Smith - On Call
    service_notification_period     24x7
    host_notification_period        24x7
    service_notification_options    w,u,c,r
    host_notification_options       d,u,r
    service_notification_commands   notify-service-by-email
    host_notification_commands      notify-host-by-email
    email                           jsmith@example.com
}

define contactgroup {
    contactgroup_name    ops-team
    alias                 Operations Team
    members               jsmith
}

Reference the contact group from each host/service (or set it once as a default in generic-service) so notifications actually fire:

define service {
    name                            generic-service
    active_checks_enabled           1
    passive_checks_enabled          1
    check_period                    24x7
    max_check_attempts              3
    contact_groups                  ops-team
    notification_interval           60
    notification_period             24x7
    register                        0
}

Validate configuration before every restart

# Debian/Ubuntu path
sudo nagios4 -v /etc/nagios4/nagios.cfg

# RHEL/Rocky path
sudo nagios -v /etc/nagios/nagios.cfg

Service management

sudo systemctl restart nagios4     # Debian/Ubuntu
sudo systemctl restart nagios      # RHEL/Rocky
sudo systemctl status nagios
sudo systemctl reload nagios       # re-read config without dropping check history

Testing NRPE manually from the Nagios server

Before trusting a service definition, always confirm the plugin works end to end by calling it exactly the way Nagios will:

# Confirm NRPE is reachable and check its version
/usr/lib/nagios/plugins/check_nrpe -H 10.0.0.21

# Run a specific remote command exactly as the service definition will
/usr/lib/nagios/plugins/check_nrpe -H 10.0.0.21 -c check_disk

# Expected output:
# DISK OK - free space: / 12000 MB (65% inode=88%);| /=6400MB;16000;18000;0;20000

A complete monitoring setup for one host, built up service by service:

Scenario:a team runs eight Linux servers behind a load balancer with no monitoring at all. The requirement: alert on disk usage before it becomes an outage, alert immediately if a service process dies, and get both into email and the team's Slack channel — without paging anyone at 3 AM for a blip that self-resolves in one retry.

• Manage nrpe.cfg and host/service definitions through Ansible or another config tool — hand-editing eight hosts individually guarantees drift.
• Set max_check_attempts and retry_check_interval deliberately per service — a flaky HTTP check needs more retries than a database process check.
• Use host templates (generic-host, linux-server) and service templates instead of repeating the same attributes on every definition.
• Set up parent/child host relationships so a switch or router failure doesn't generate a storm of unrelated DOWN alerts.
• Route different severities to different channels — CRITICAL to a paging service, WARNING to a low-priority Slack channel — instead of one firehose.
• Keep a staging Nagios instance (or a spare install) to test config changes before touching production monitoring — a broken monitoring config is itself an outage.

• Restrict allowed_hosts — set NRPE's allowed_hosts to the Nagios server's exact IP, never a wildcard or broad subnet.
• Firewall the NRPE port — allow TCP 5666 only from the Nagios server's IP, both on the host firewall and any upstream security group.
• Never run checks as root — the nagios/nrpe service accounts should have only the specific sudo rules a check plugin genuinely needs (e.g. reading a restricted log), not blanket root.
• Secure the web UI — put it behind HTTP basic auth at minimum (already required for the CGIs), and terminate it behind TLS (a reverse proxy with Let's Encrypt is the common pattern) rather than serving it over plain HTTP.
• Keep dont_blame_nrpe off unless required — enabling command-line arguments from the server side widens what a compromised Nagios server could execute on every monitored host; scope it tightly if you must use it.
• Patch the NRPE package — it has had real CVEs historically; track updates for it the same way you would any network-facing daemon.

Nagios earns its long production track record through a small number of composable ideas: plugins that speak a strict exit-code contract, active checks scheduled by the server and passive checks pushed in when that doesn't fit, NRPE for visibility inside remote hosts, and a notification pipeline (contacts, contact groups, notification periods) that decides exactly who hears about a problem and when. Get those fundamentals — plus the SOFT/HARD state machine that keeps you from paging on every blip — solid on a small fleet, and scaling to hundreds of hosts is mostly more of the same config, driven through Ansible instead of by hand.

• Official Nagios Core documentation — nagios.org
• Nagios Exchange (community plugins and configs) — exchange.nagios.org
• Nagios Plugins project (check_disk, check_http, etc. source and docs) — nagios-plugins.org
• NRPE project documentation — github.com/NagiosEnterprises/nrpe
• Postfix documentation (for wiring up email notifications) — postfix.org