Apache exporter visibility begins at the mod_status boundary
An Apache exporter reads a status endpoint and converts the response into Prometheus metrics. Port 9117 is commonly used for the exporter itself. The project can expose request counts, worker state, and server health, but only if Apache's mod_status interface is enabled and reachable from the exporter.
The measurements
The count-only queries completed on November 5, 2026:
| Query | Matches | UTC time |
|---|---|---|
port="9117" |
4 | 2026-11-05T00:40:59Z |
app="apache_exporter" |
0 | 2026-11-05T00:41:00Z |
http.body="apache_exporter_build_info" |
5 | 2026-11-05T00:41:02Z |
The application field returned zero. The body and port counts are close but not matched, and neither establishes that an Apache server or exporter is internet-facing. The zero is a successful query result, not a failed request.
Enable status for the collector, not the public
Apache mod_status can expose server activity through a designated URL. The exporter needs a URL, a timeout, and possibly credentials. Restrict that endpoint with Require rules, a private interface, or a reverse proxy that only permits the collector address.
The exporter listener should also be private. Prometheus can reach it through the monitoring network, while ordinary clients cannot. If the exporter endpoint is public, a person can read its metrics even though the original status page is protected. Treat the two endpoints as separate trust boundaries.
Use a dedicated Apache status configuration and a read-only collector account. Do not expose the full server-status page with process details to the internet. Review which modules add fields to the page and whether those fields disclose internal paths, client addresses, or virtual-host names.
The metrics can describe the estate
Apache metrics may reveal server names, worker states, request rates, response codes, and traffic totals. A public dashboard of those values can help an observer infer when a service is busy or when a maintenance window begins. The data is operational, but it is still useful reconnaissance.
Metric cardinality is another issue. A configuration that labels every request path or virtual host can grow quickly. The exporter should use a bounded label set and a reasonable scrape interval. Review any configuration that accepts arbitrary query parameters or target URLs.
Validate the deployment
From the monitoring host, request the exporter's /metrics endpoint and confirm the Apache metric prefix. From the Apache host, inspect the status endpoint's access log and source restriction. From an ordinary user network, confirm both the exporter and the status page are denied.
Check the exporter's startup options and the status URL source. Do not infer the effective URL from a dashboard. A proxy or environment variable can point the exporter at a different server or endpoint. Preserve the configuration hash and compare it after an upgrade.
If the exporter was exposed, review its access logs and the Apache status logs together. Look for requests from unexpected sources or a change in scrape volume. Restrict the path, then change any status credentials that may have been exposed. The exporter itself should not be used as a general-purpose proxy.
The useful inventory
Four port matches are a small review queue. Five body matches may include documentation or copied samples. The owner should identify each Apache exporter, its status URL, credentials, listening address, and network policy.
The article's central point is the two-step dependency: Apache must provide the status data, and the exporter must expose it to Prometheus. A secure review checks both. A count of the exporter port alone cannot tell whether the underlying status page is protected.
Top comments (0)