Apache HTTP Server (HTTPD) is the workhorse of the web, but it can often feel like a black box. You might know the process is running, but you don’t necessarily know if your worker pool is saturated, if a specific client is hogging connections, or if your backend is causing a spike in 503 errors.
Effective Apache monitoring requires looking at two different types of data: real-time counters provided by the server itself, and the narrative history recorded in your access logs. By combining these signals, you move from “is it up?” to “how is it performing?”
The primary signal: mod_status
The foundation of Apache monitoring is the mod_status module. Unlike logs, which record events after they happen, mod_status provides a real-time snapshot of what the server is doing right now.
It exposes a plain-text or HTML page that shows how many worker processes are currently busy, what they are doing (reading, writing, or gracefully finishing), and how much traffic has passed through the server since it started.
For any monitoring tool to give you a request rate or CPU load specifically for Apache, it is almost certainly querying this module under the hood.
How to enable mod_status safely
Most Apache installations include mod_status by default, but it is rarely enabled for remote access. You need to configure a specific location to expose the data.
Configuration snippet
To enable it, you typically add a block to your configuration (often in /etc/apache2/mods-enabled/status.conf or your main httpd.conf).
<Location "/server-status">
SetHandler server-status
Require local
# Require ip 192.168.1.0/24 # Optional: allow your monitoring server
</Location>
# Essential for detailed metrics
ExtendedStatus OnThe ExtendedStatus On directive is critical. Without it, Apache only tracks basic connection counts. With it enabled, you get high-fidelity metrics like bytes per second and requests per second.
Validating the setup
Once you’ve reloaded Apache (sudo systemctl reload apache2), you can verify the output using curl:
curl http://localhost/server-status?autoThe ?auto flag is used by monitoring agents to get a machine-readable format that looks like this:
Total Accesses: 15204
Total kBytes: 24892
BusyWorkers: 5
IdleWorkers: 20
Scoreboard: _W___R__...Key Apache metrics to track
While mod_status provides dozens of fields, these four are the most critical for maintaining server health:
1. Busy workers
This is the most important saturation metric. Apache uses a pool of workers to handle connections. If BusyWorkers consistently approaches your MaxRequestWorkers limit, new connections will be queued or dropped. If this number stays high, you either have a traffic surge or your backend is taking too long to release connections.
2. Idle workers
This tells you how much headroom you have. If you have zero idle workers, you are at capacity. A healthy server should always maintain a small buffer of idle workers to handle sudden bursts of traffic without the overhead of spawning new processes.
3. Request rate
This measures throughput. Spikes in request rates can point to a successful marketing campaign, a search engine crawler, or a DDoS attack. When correlated with CPU usage, it helps you understand the cost of a single request on your hardware.
4. Bytes per second
This measures bandwidth. If your request rate is stable but your bytes per second is climbing, you might be serving larger assets than usual (like unoptimized images) or experiencing a “slowloris” style attack where clients are reading data very slowly.
The missing piece: access logs
While mod_status is excellent for tracking the state of the server, it has a major blind spot: it doesn’t know about individual requests once they are finished.
To understand the user experience, you must look at your access logs. This is the only place where you can calculate:
- Error rates: What percentage of your traffic is resulting in 404s (client error) or 500s (server error)?
- Request latency: How many milliseconds did it take to serve a specific URL?
- Traffic distribution: Which specific domain or virtual host is generating the most load?
By default, Apache logs include the status code and the response size. If you want to monitor performance, you should ensure your LogFormat includes the time taken to serve the request (using %D for microseconds or %T for seconds).
Choosing a monitoring approach
There are three common ways to turn these raw signals into actionable dashboards.
1. The DIY path (Prometheus + exporter)
In this setup, you run an Apache exporter on your server. It polls /server-status?auto every few seconds and converts the data into a format Prometheus can scrape. You then build dashboards in Grafana. This is powerful but requires maintaining the exporter, the Prometheus server, and the Grafana instance.
2. The monolith path (Zabbix or PRTG)
Tools like Zabbix or PRTG use templates to monitor Apache. They often use scripts to fetch the status page or query the server via SNMP. These are all-in-one solutions but can be complex to configure and require a dedicated monitoring server.
3. The integrated path (Simple Observability)
For teams that want visibility without the infrastructure overhead, Simple Observability provides an integrated agent.
When you install the agent, it automatically discovers your Apache status page on localhost. It collects connection metrics (busy and idle workers) and simultaneously tails your access logs to extract error rates and latency.
This hybrid approach ensures you see the pulse of the server (metrics) alongside the narrative of the traffic (logs) in a single interface.
Conclusion
Apache monitoring doesn’t have to be an over-engineered project. By enabling mod_status with ExtendedStatus On, you unlock the vital signs of your server’s worker pool. By keeping an eye on your access logs, you ensure you’re aware of error spikes and latency issues before your users are.
Start by getting your BusyWorkers and request rate into a dashboard. Once you have that baseline visibility, you can begin tuning your Apache configuration for the actual traffic patterns your server is handling.