After one too many late-night pages about a downed website, I decided to get serious about proactive monitoring instead of waiting for customers to tell me something was broken. Nagios became my tool of choice for this, and in this post I’ll walk through exactly how I set it up to monitor Apache in real time.
What Is Nagios?
Nagios is a widely-used open-source monitoring system that checks hosts and services, alerting you when something goes wrong — before your users notice. For Apache, this means monitoring things like whether the service is running, whether HTTP responses are healthy, response times, and resource usage.
Why Monitor Apache with Nagios?
- Early warning — get alerted the moment Apache goes down or starts returning errors, instead of finding out from angry customers.
- Historical trends — Nagios can track uptime and performance over time.
- Centralized visibility — if you manage multiple servers, Nagios gives you one dashboard for all of them.
- Custom alerting — email, SMS, Slack, or PagerDuty notifications when thresholds are breached.
Prerequisites
- A Linux server to act as the Nagios monitoring host
- One or more Apache servers to monitor
- Root or sudo access on both the monitoring host and monitored servers
- Basic networking access between the two (firewall rules allowing NRPE or HTTP checks)
Step 1: Install Nagios Core on the Monitoring Server
On Ubuntu/Debian:
sudo apt update
sudo apt install nagios4 nagios-plugins-contrib -y
On CentOS/RHEL, I usually build from source or use the EPEL repository:
sudo yum install epel-release -y
sudo yum install nagios nagios-plugins-all nagios-plugins-nrpe -y
Step 2: Access the Nagios Web Interface
Once installed, Nagios runs a web interface, usually at:
http://your-server-ip/nagios4/ # Debian/Ubuntu
http://your-server-ip/nagios/ # CentOS/RHEL
Set the admin password if it wasn’t set during install:
sudo htpasswd -c /etc/nagios4/htdigest.users nagiosadmin
Restart Apache to apply changes:
sudo systemctl restart apache2
Step 3: Install NRPE on the Monitored Apache Server
NRPE (Nagios Remote Plugin Executor) lets Nagios run checks on a remote server. On the Apache server itself:
sudo apt install nagios-nrpe-server nagios-plugins -y
Edit the NRPE config at /etc/nagios/nrpe.cfg to allow the Nagios server’s IP:
allowed_hosts=127.0.0.1,192.168.1.50
Restart NRPE:
sudo systemctl restart nagios-nrpe-server
Step 4: Define Basic HTTP Checks
The simplest and most direct way to monitor Apache is with the built-in check_http plugin, run directly from the Nagios server (no agent needed on the target).
On the Nagios server, create a new host definition at /etc/nagios4/conf.d/apache_host.cfg:
define host {
use linux-server
host_name web01
alias Apache Web Server 1
address 192.168.1.100
max_check_attempts 5
check_period 24x7
notification_interval 30
notification_period 24x7
}
Then define the service check in the same directory:
define service {
use generic-service
host_name web01
service_description HTTP
check_command check_http
check_interval 5
retry_interval 1
}
This uses Nagios’s default check_http command, which checks that the web server responds with a valid HTTP status.
Step 5: Monitor a Specific URL or Response Content
Sometimes I want to verify more than “the server responds” — I want to confirm a specific page loads correctly. I use check_http with additional flags:
define command {
command_name check_http_page
command_line $USER1$/check_http -H $HOSTADDRESS$ -u /health-check.html -e 200 -s "OK"
}
define service {
use generic-service
host_name web01
service_description Homepage Health Check
check_command check_http_page
check_interval 5
retry_interval 1
}
This checks that /health-check.html returns a 200 status and the string “OK” appears in the response body — a great pattern for verifying that both the web server and any backend it depends on (database, app server) are functioning.
Step 6: Monitor Apache Process and Resource Usage via NRPE
To check the actual Apache process (not just HTTP responses), I set up NRPE-based checks on the web server. Add this to /etc/nagios/nrpe.cfg on the Apache server:
command[check_apache_proc]=/usr/lib/nagios/plugins/check_procs -c 1: -C apache2
command[check_load]=/usr/lib/nagios/plugins/check_load -w 2,1.5,1 -c 4,3,2
command[check_disk]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /
Then on the Nagios server, define the corresponding services:
define service {
use generic-service
host_name web01
service_description Apache Process
check_command check_nrpe!check_apache_proc
}
define service {
use generic-service
host_name web01
service_description CPU Load
check_command check_nrpe!check_load
}
define service {
use generic-service
host_name web01
service_description Disk Space
check_command check_nrpe!check_disk
}
Step 7: Configure Notifications
I always set up email alerts at minimum. Edit /etc/nagios4/objects/contacts.cfg:
define contact {
contact_name admin
use generic-contact
alias Administrator
email admin@mydomain.com
}
Make sure your mail transfer agent (like postfix or sendmail) is configured so Nagios can actually send emails.
Step 8: Validate and Restart Nagios
Always verify your configuration syntax before restarting:
sudo nagios4 -v /etc/nagios4/nagios.cfg
If it returns no errors:
sudo systemctl restart nagios4
Step 9: Setting Up Response Time Thresholds
Beyond just checking whether Apache responds, I also like to alert on degraded performance, not just outright failure. check_http supports warning and critical thresholds based on response time:
define command {
command_name check_http_response_time
command_line $USER1$/check_http -H $HOSTADDRESS$ -w 2 -c 5
}
define service {
use generic-service
host_name web01
service_description HTTP Response Time
check_command check_http_response_time
check_interval 5
}
Here, a response taking longer than 2 seconds triggers a warning, and anything over 5 seconds triggers a critical alert. This has caught slow-creeping performance regressions for me long before they became full outages — a page that used to load in 200ms creeping up to 4 seconds over a week is a strong early signal that something (often a database index issue or a memory leak) needs attention.
Step 10: Grouping Hosts for Easier Management
Once you’re monitoring more than a handful of servers, I find it useful to group them logically in /etc/nagios4/conf.d/hostgroups.cfg:
define hostgroup {
hostgroup_name apache-webservers
alias Apache Web Servers
members web01,web02,web03
}
This lets me apply the same set of service checks to an entire group at once, and view them together in the Nagios dashboard rather than clicking through individual hosts one by one.
Real-World Use Case
I once managed a small e-commerce cluster where the app server would occasionally hang while Apache itself stayed “up.” A plain process check wouldn’t have caught it — but a check_http_page hitting an endpoint that queried the database gave us alerts within a minute of any real degradation, well before customers started complaining about failed checkouts.
Common Mistakes I’ve Made
- Only checking if Apache is “up” without verifying actual page content — the process can be running while the app behind it is broken.
- Forgetting to whitelist the Nagios server’s IP in
allowed_hostson NRPE, resulting in “CHECK_NRPE: Error – Could not complete SSL handshake” errors. - Setting check intervals too aggressively, generating excessive load or alert fatigue.
- Not testing notifications before relying on them in a real incident.
Security Best Practices
- Restrict the Nagios web interface behind authentication and, ideally, a VPN or IP allowlist.
- Use NRPE over SSL/TLS where possible, and restrict
allowed_hostsstrictly to your monitoring server’s IP. - Avoid exposing detailed check output (like server paths) to unauthenticated users.
Performance Optimization Tips
- Stagger check intervals so you’re not hammering the same server with dozens of near-simultaneous checks.
- Use passive checks (where the monitored host pushes results) for high-frequency internal metrics instead of active polling, to reduce Nagios server load at scale.
- Archive Nagios’s historical data periodically so its own database/log files don’t balloon over time.
Troubleshooting Common Issues
CHECK_NRPE: Error – Could not complete SSL handshake — usually means allowed_hosts doesn’t include the Nagios server’s IP, or a firewall is blocking port 5666.
Service shows “UNKNOWN” status — check the command definition for typos in the plugin path or arguments; run the check manually to see the raw error:
/usr/lib/nagios/plugins/check_nrpe -H 192.168.1.100 -c check_apache_proc
No email alerts received — verify your mail server is configured and test manually with echo "test" | mail -s "test" admin@mydomain.com.
FAQs
Do I need NRPE if I only want to check HTTP responses? No — check_http runs directly from the Nagios server without needing an agent on the target. NRPE is only needed for checks like process status, disk space, or load that require local access.
Can Nagios monitor multiple Apache servers at once? Yes, you simply define additional host and service blocks for each server you want to monitor.
Is Nagios still relevant compared to newer tools like Prometheus? Nagios remains popular for its maturity, simplicity, and huge plugin ecosystem, though many teams now pair it with or migrate to Prometheus/Grafana for more modern dashboards.
How often should checks run? For critical production services, I run checks every 1–5 minutes. Less critical internal tools can check every 10–15 minutes to reduce load.
Summary and Key Takeaways
Setting up Nagios to monitor Apache gives you real, proactive visibility into your web server’s health — catching problems before your users do. The combination of check_http for external validation and NRPE-based checks for internal process and resource monitoring covers most real-world failure scenarios. Once configured, take the time to test your notification pipeline so you know alerts will actually reach you during an incident.