Bug Description
In lib/prom/prom.go, the Observe method creates a fail counter label set via WithLabelValues() but never calls .Inc() on the returned counter:
if res.Error != "" {
pm.requestFailCounter.WithLabelValues(res.Method, res.URL, code, res.Error)
}
This means the request_fail_count Prometheus metric is always zero, regardless of how many errors occur during the attack. The metric label set is registered in the registry (so it shows up in /metrics output), but its value is never incremented.
Impact
Users relying on the Prometheus integration to monitor attack error rates will always see a zero fail count, silently hiding all errors from their Grafana dashboards and alerting rules.
Fix
Add .Inc() to the end of the WithLabelValues() call:
if res.Error != "" {
pm.requestFailCounter.WithLabelValues(res.Method, res.URL, code, res.Error).Inc()
}
Reproduction
A test that verifies the counter value (rather than just checking the metric exists) demonstrates the bug. The existing test TestMetrics_Observe only parses metric names from the scrape output; it doesn't verify the counter has a non-zero value.
PR forthcoming.
Bug Description
In
lib/prom/prom.go, theObservemethod creates a fail counter label set viaWithLabelValues()but never calls.Inc()on the returned counter:This means the
request_fail_countPrometheus metric is always zero, regardless of how many errors occur during the attack. The metric label set is registered in the registry (so it shows up in/metricsoutput), but its value is never incremented.Impact
Users relying on the Prometheus integration to monitor attack error rates will always see a zero fail count, silently hiding all errors from their Grafana dashboards and alerting rules.
Fix
Add
.Inc()to the end of theWithLabelValues()call:Reproduction
A test that verifies the counter value (rather than just checking the metric exists) demonstrates the bug. The existing test
TestMetrics_Observeonly parses metric names from the scrape output; it doesn't verify the counter has a non-zero value.PR forthcoming.