]> git.ipfire.org Git - thirdparty/haproxy.git/commit
MINOR: counters: add max-only reset helpers and use them for clear counters
authorAlexander Stephan <alexander.stephan@sap.com>
Thu, 16 Jul 2026 12:40:51 +0000 (12:40 +0000)
committerWilly Tarreau <w@1wt.eu>
Thu, 30 Jul 2026 17:00:47 +0000 (19:00 +0200)
commit5d7be73fa0e72df97f85c10e6cb52da426ea23c8
treefc0f59576eb08cdf5a631b5350124a93c751bb05
parent219b80d79e9519ff3de34c25233c2b2264df8f6d
MINOR: counters: add max-only reset helpers and use them for clear counters

The plain "clear counters" command (OPER level) resets only the max/peak
gauges of each object's counters, leaving cumulative counters intact,
while "clear counters all" (ADMIN) performs a full reset via the
counters_{fe,be}_reset() helpers introduced earlier in this series.

The max-only reset was open-coded inline in proxy_stats_clear_counters()
with a hand-maintained list of fields, duplicated across the backend,
server and listener branches. This is fragile: a new max gauge added to
struct {fe,be}_counters can silently be forgotten here.

Factor the max-only reset into counters_fe_reset_max() and
counters_be_reset_max(), living next to the existing reset helpers, and
call them from proxy_stats_clear_counters(). Unlike the full-reset
helpers these cannot use a blanket memset because the max fields are
interleaved with live cumulative fields, so the gauges are zeroed
individually.

While consolidating, the two open-coded lists turned out to disagree:
the backend branch cleared conn_max / cps_max / rps_max but not
cur_sess_max, while the server branch cleared cur_sess_max but none of
the former. Both used the same struct be_counters, so these were latent
gaps rather than intentional differences. counters_be_reset_max() now
clears the union of all peak gauges, so plain "clear counters"
consistently resets every max gauge for both backends and servers.

No functional change for the full-reset ("all") path.
include/haproxy/counters.h
src/counters.c
src/stats-proxy.c