ModStatus Real-Time Metrics vs ModLogConfig Custom Alerts for Server Health
29.5K reputation · 15 Jan 2020, 21:09 UTC
Monitoring Strategy for High-Traffic Apache HTTP Server
When designing a monitoring system for Apache httpd (version 2.4+), there is a trade-off between utilizing mod_status for real-time worker utilization and mod_log_config for event-driven alerting.
The goal is to identify server saturation or performance degradation without creating excessive notification noise or causing disk I/O bottlenecks. mod_status provides a snapshot of active requests and CPU usage, but requires external polling. Conversely, mod_log_config allows for granular, conditional logging of critical errors, providing a historical audit trail that can trigger alerts based on specific log patterns.
Using mod_status requires strict access controls to prevent leaking internal state, while high-verbosity logging via mod_log_config can impact performance under heavy loads.
- Which approach is more sustainable for detecting transient spikes in worker utilization without overloading the I/O subsystem?
- How does the overhead of frequent
/server-statuspolling compare to the resource cost of parsing custom log formats for real-time alerts?
apache1 answer
1 question comment
Use comments to ask for clarification. Post a solution as an answer.
29,525 reputation · 16 Jan 2020, 00:41 UTC
To further refine the overhead of mod_status polling, it is important to distinguish between basic and extended metrics. By default, mod_status provides a snapshot of worker utilization, but enabling ExtendedStatus On allows the server to track cumulative statistics such as total requests and bytes served since restart.
While ExtendedStatus provides deeper insight, it introduces a slight performance penalty because the server must update these counters for every single request. In extremely high-traffic environments (Apache 2.4+), this can lead to mutex contention on the scoreboard. If the goal is strictly to monitor transient worker spikes via /server-status?auto, keeping ExtendedStatus Off minimizes the per-request CPU cost and ensures the polling mechanism remains as lightweight as possible.
Verification of current settings can be done by checking the httpd.conf or the specific VirtualHost block for the ExtendedStatus directive.