Component(s)

receiver/apache

Is your feature request related to a problem? Please describe.

The Apache receiver currently does not expose several useful metrics available from Apache's server-status?auto endpoint:

1. Max worker slots — There is no metric to understand the total worker capacity of the server. The scoreboard string length represents MaxRequestWorkers (or ServerLimit × ThreadsPerChild), which is essential for capacity planning. Without it, users cannot calculate worker utilization (busy workers / max workers).

2. Bytes per second (BytesPerSec) — Apache natively reports the served bytes per second rate, but the receiver only collects cumulative Total kBytes via apache.traffic. Users who want the instantaneous rate must compute it themselves from the cumulative counter.

3. Requests per second (ReqPerSec) — Similarly, Apache natively reports the request rate, but the receiver only collects cumulative Total Accesses via apache.requests.

Describe the solution you'd like

Add three new metrics to the Apache receiver, all with stability: development:

1. apache.workers.max (gauge, int)

• Derived from len(Scoreboard) — the total number of worker slots configured.
• Useful for computing utilization: apache.workers{state=busy} / apache.workers.max.

2. apache.bytes_per_sec (gauge, double)

• Read directly from the BytesPerSec field in server-status?auto output.
• Represents the server's average bytes served per second since the server was started.

3. apache.requests_per_sec (gauge, double)

• Read directly from the ReqPerSec field in server-status?auto output.
• Represents the server's average requests served per second since the server was started.

All three fields are standard outputs of Apache's mod_status when ExtendedStatus On is configured.

Example server-status?auto output showing these fields:

Total Accesses: 524897
Total kBytes: 1028498
BytesPerSec: 5765.43
ReqPerSec: 2.94
Scoreboard: _W_K_....W__K...

Describe alternatives you've considered

• Computing rates from cumulative counters (apache.traffic, apache.requests) at the query layer (e.g., using rate() in PromQL). However, since Apache already computes and exposes these rates natively, exposing them directly is simpler and avoids potential counter-reset artifacts.

• For max workers, reading the Apache config directly. However, deriving it from the scoreboard length is the standard approach and requires no additional configuration or access.

Additional context

These fields are documented in the Apache mod_status output:
https://httpd.apache.org/docs/2.4/mod/mod_status.html

The async connection fields (ConnsAsyncWriting, ConnsAsyncKeepAlive, ConnsAsyncClosing) are intentionally excluded from this request as they are already covered by the existing apache.connections.async metric with the connection_state attribute.