Problem Statement
The windows_exchange_ldap_search_time_sec metric in the Exchange collector is exposed as a counter, but it does not include a corresponding base/count metric needed to compute meaningful averages.
On Windows, the underlying PerfMon counter (MSExchange ADAccess Processes\LDAP Search Time) is an average timer type metric: it requires both a cumulative time value and a base counter (# of operations) to compute an average per operation (similar to what PerfMon shows). However, the exporter exposes only the “time” component:
# TYPE windows_exchange_ldap_search_time_sec counter
windows_exchange_ldap_search_time_sec{…} <value>
but no count/base metric (e.g., total searches) is exposed alongside it.
Impact
Without the base counter, this metric cannot be interpreted as intended — it simply accumulates absolute time, not average time per search.
In practice:
• Prometheus/Grafana graphs show large increasing values (seconds total), which are not comparable to PerfMon’s average per search.
• There is no way to calculate a meaningful rate per operation (e.g. latency distribution) using PromQL.
This leads to confusion and incorrect interpretation of this metric in monitoring dashboards.
Proposed Solution
For an average timer metric, the exporter should expose both:
1. A cumulative numerator (total time) — already exported as windows_exchange_ldap_search_time_sec, and
2. A cumulative denominator (number of operations) — e.g. windows_exchange_ldap_search_total or similar.
This allows users to compute average time per operation via:
rate(time[5m]) / rate(count[5m])
Additional information
The problem probably also affects the other metrics such as:
- windows_exchange_ldap_read_time_sec
- windows_exchange_ldap_write_time_sec
If I have completely misunderstood something here and simply misunderstand the metric - then please enlighten me :-)
Screenshots
Acceptance Criteria
No response
Problem Statement
The windows_exchange_ldap_search_time_sec metric in the Exchange collector is exposed as a counter, but it does not include a corresponding base/count metric needed to compute meaningful averages.
On Windows, the underlying PerfMon counter (MSExchange ADAccess Processes\LDAP Search Time) is an average timer type metric: it requires both a cumulative time value and a base counter (# of operations) to compute an average per operation (similar to what PerfMon shows). However, the exporter exposes only the “time” component:
but no count/base metric (e.g., total searches) is exposed alongside it.
Impact
Without the base counter, this metric cannot be interpreted as intended — it simply accumulates absolute time, not average time per search.
In practice:
• Prometheus/Grafana graphs show large increasing values (seconds total), which are not comparable to PerfMon’s average per search.
• There is no way to calculate a meaningful rate per operation (e.g. latency distribution) using PromQL.
This leads to confusion and incorrect interpretation of this metric in monitoring dashboards.
Proposed Solution
For an average timer metric, the exporter should expose both:
1. A cumulative numerator (total time) — already exported as windows_exchange_ldap_search_time_sec, and
2. A cumulative denominator (number of operations) — e.g. windows_exchange_ldap_search_total or similar.
This allows users to compute average time per operation via:
Additional information
The problem probably also affects the other metrics such as:
If I have completely misunderstood something here and simply misunderstand the metric - then please enlighten me :-)
Screenshots
Acceptance Criteria
No response