Monitoring Nginx and Apache is something most teams set up too late – usually after a slow response time complaint turns into a full outage. Whether you’re running a high-traffic e-commerce site or a handful of internal apps, understanding which web server health metrics actually matter is fundamental to stable operations.
Web servers sit at the edge of your stack, handling every user request before anything else. When Nginx or Apache starts struggling – whether from connection exhaustion, memory pressure, or misconfigured workers – the effect ripples immediately to end users. The challenge is knowing which metrics actually indicate trouble versus which ones just look alarming at first glance.
Why Web Server Metrics Are Often Overlooked
Most infrastructure monitoring setups start with the basics: CPU, memory, disk. Web server-specific metrics tend to come later, often after an incident. That’s a mistake. A server can sit at 15% CPU while Nginx silently queues hundreds of connections, or Apache runs out of available workers – and nothing in your standard metrics will catch it.
The other common failure is over-reliance on basic uptime checks. If your monitoring only verifies that port 80 is responding, you’re flying blind. A server can return a valid HTTP response while being severely degraded – slow, queuing, or partially misconfigured.
Key Nginx Metrics to Watch
Nginx exposes a compact but useful status page via the ngx_http_stub_status_module. The core metrics from this endpoint are:
Active connections – the total number of connections currently being handled. This number fluctuates constantly, but watch for it pushing consistently toward your configured worker_connections limit.
Requests per second – derived from the requests counter over time. Sudden drops (not just spikes) are often a sign of upstream failure or a misconfigured upstream block.
Waiting connections – connections in keep-alive state waiting for a new request. A high waiting count relative to active connections can indicate clients holding connections open longer than expected, which can starve new visitors.
Worker process count – Nginx workers should be stable. If you see workers being killed and respawned in process monitoring, something is wrong at the config or resource level.
Enable the stub status module in your Nginx config and restrict it to localhost only. Exposing it externally – even with basic auth – is a common security mistake that leaks internal server state.
Key Apache Metrics to Watch
Apache’s mod_status provides more verbose data than Nginx’s stub module. The most actionable metrics:
BusyWorkers vs IdleWorkers – this ratio tells you how close Apache is to saturation. If BusyWorkers is consistently near the MaxRequestWorkers value, requests are queuing or being rejected.
Requests per second and bytes per request – useful for detecting abnormal traffic patterns or payload size changes that could indicate abuse or misconfiguration.
Scoreboard state – the mod_status scoreboard shows individual worker states: reading, writing, keepalive, closing, logging. A scoreboard full of “K” (keepalive) slots with few “W” (writing) slots often means your keepalive timeout is set too generously.
Error log growth rate – Apache’s error log is an underutilized signal. A sudden increase in 5xx responses or backend errors often appears there before it surfaces in application-layer monitoring.
The Myth: More Workers Equals Better Performance
A persistent misconception is that setting MaxRequestWorkers very high improves throughput. In practice, if you have more workers than your server has RAM to support them, Apache will start swapping. A server thrashing swap at 200 workers serves fewer requests per second than one running 40 workers with plenty of free memory.
The same logic applies to Nginx’s worker_connections. Setting it to 65535 on a server with 512MB RAM available for Nginx is asking for OOM kills. Match your configuration to what the hardware can actually sustain under your real traffic profile.
Establishing performance baselines for your web server under normal load is the only reliable way to set these values correctly – and to detect when something has quietly shifted.
Process and Service Monitoring for Web Servers
Metric collection is useful, but it’s reactive. Process-level monitoring adds a proactive layer: detecting when the Nginx or Apache process exits unexpectedly, fails to restart, or starts consuming abnormal resources.
Both servers should be monitored as managed services via systemd or init. Knowing within seconds that nginx.service entered a failed state – rather than discovering it when a user reports a blank page – is the difference between a minor incident and a significant outage. Service status monitoring for web servers should include not just the service state but also the process restart count and memory footprint over time.
Access Log Analysis as a Monitoring Signal
Structured access log parsing is one of the highest-value, lowest-cost additions to web server monitoring. Key signals from logs:
– 4xx error rate by URI path – useful for catching broken links, missing assets, or client-side auth issues
– 5xx rate by upstream or backend – points directly to application server failures
– Response time percentiles – p95 and p99 latency from access logs often reveals slow endpoints invisible in average response times
– Unusual User-Agent or IP volume spikes – early warning for scraping or credential stuffing attempts
Metrics tell you something is wrong. Log analysis often tells you exactly where.
Setting Alerts That Don’t Cry Wolf
A common trap is alerting on raw worker count or active connections without context. These numbers fluctuate normally during business hours. An alert that fires every Tuesday afternoon during peak traffic is an alert that gets ignored.
Effective real-time alerts for web servers should be rate-based and contextual: alert when BusyWorkers exceeds 90% of MaxRequestWorkers for more than two consecutive minutes, not when it briefly spikes. Alert when the 5xx rate exceeds 1% of total requests over a five-minute window, not when a single error occurs.
Threshold calibration takes time and iteration. Start conservative, watch for false positives in the first week, and tighten from there.
Frequently Asked Questions
What’s the difference between monitoring Nginx and Apache?
Nginx uses an event-driven model and exposes minimal metrics via stub_status. Apache uses a process/thread model and exposes more granular worker state via mod_status. Nginx monitoring requires more inference from connection metrics, while Apache gives you direct worker saturation data.
How often should web server metrics be collected?
For active production servers, 15–30 second intervals are practical. Minute-level polling misses short connection spikes that degrade user experience without showing up in coarser data. During incident investigation, 5-second intervals are useful but generate significant data volume.
Do I need a dedicated tool for web server monitoring, or can I use an existing agent?
A lightweight agent that supports custom metric collection – such as polling the Nginx status endpoint or parsing Apache mod_status output locally – is usually sufficient. Dedicated plugins reduce setup time but aren’t required if your agent supports custom metric ingestion.
A Practical Starting Point
If you’re just beginning, enable stub_status on Nginx or mod_status on Apache, collect the core metrics described above, and observe them over a seven-day period to establish a baseline. Layer in service and process monitoring to catch crashes, then add access log parsing once the metric layer is stable.
Web server monitoring doesn’t need to be complex to be effective. The goal is knowing within minutes when something degrades – before users notice. That visibility comes from the right metrics, not the most metrics.