Copilot commented on code in PR #13506:
URL: https://github.com/apache/trafficserver/pull/13506#discussion_r3724980510
##########
doc/admin-guide/monitoring/statistics/core/http-connection.en.rst:
##########
@@ -201,6 +201,61 @@ HTTP Connection
Current number of TCP connections for tunnels where the far end is the
server,
except for those counted by
``proxy.process.tunnel.current_server_connections_tls``
+.. _per-server-connection-metrics:
+
+Per Server Connection Metrics
+-----------------------------
+
+Unlike the metrics above these do not have fixed names. They are created
dynamically, one set per
+upstream server group as defined by
:ts:cv:`proxy.config.http.per_server.connection.match`, and,
+when the match type is ``both``, one aggregate set per hostname. Whether any
of them are published,
+and at what granularity, is controlled by
+:ts:cv:`proxy.config.http.per_server.connection.metric_enabled`. An optional
+:ts:cv:`proxy.config.http.per_server.connection.metric_prefix` can be inserted
into the names.
+
+Per group names are ``proxy.process.http.per_server.<counter>.<group>``, where
``<group>`` depends on
+the match type: an IP address, an ``address:port`` pair, a hostname, or, for
``both``,
+``<hostname>.<address:port>``. Per hostname names are
+``proxy.process.http.per_server.<counter>.<hostname>``. Aggregates exist only
for match type
+``both``, because that is the only match type with more than one group per
hostname; for match type
+``host`` the group name is already the bare hostname, so an aggregate would
carry the same name as
+the single group it summarises.
+
+For a group, ``<counter>`` is one of:
+
+current_connection
+ Gauge. The number of connections currently open to the group.
+
+total_connection
+ Counter. The total number of connections ever opened to the group. Never
decreases.
+
+blocked_connection
+ Counter. The total number of connection attempts to the group blocked by
+ :ts:cv:`proxy.config.http.per_server.connection.max`. Never decreases.
+
+For a hostname aggregate, ``<counter>`` is one of those three, each summed
across the groups of that
+hostname, plus:
+
+current_connection_max
+ Gauge. The largest ``current_connection`` value among the groups of that
hostname at the moment
+ of sampling, so the maximum rather than the sum of the groups' current
counts. This is useful
+ because :ts:cv:`proxy.config.http.per_server.connection.max` is enforced
per group rather than
+ per hostname, so the busiest group is what determines whether connections
are about to be
+ blocked. Like ``current_connection`` it rises and falls with traffic and is
not a high-water
+ mark. There is no per group ``current_connection_max``; it exists only as a
hostname aggregate.
+
+The aggregates are recomputed periodically, currently every 5 seconds, rather
than on every
+connection event, so a reader sees a value up to that interval old. This
applies to
+``current_connection_max`` as well: it reports the maximum across groups as of
the last sample, not
+a running peak. To obtain the peak over a longer window, compute a maximum
over time from this gauge
+in the monitoring system.
Review Comment:
This section says only the hostname aggregates are recomputed periodically,
but at `metric_enabled` level 2 the per-group metrics are also published via
`Derived` mirroring, so they will lag by up to the same sync interval as well.
The docs should call out that any derived-published per-server metric
(including level-2 group mirrors) is sampled periodically, not updated on each
connection event.
##########
src/records/RecordsConfig.cc:
##########
@@ -395,7 +395,7 @@ static constexpr RecordElement RecordsConfig[] =
,
{RECT_CONFIG, "proxy.config.http.per_server.connection.min", RECD_INT, "0",
RECU_DYNAMIC, RR_NULL, RECC_STR, "^[0-9]+$", RECA_NULL}
,
- {RECT_CONFIG, "proxy.config.http.per_server.connection.metric_enabled",
RECD_INT, "0", RECU_DYNAMIC, RR_NULL, RECC_STR, "[0-1]", RECA_NULL}
+ {RECT_CONFIG, "proxy.config.http.per_server.connection.metric_enabled",
RECD_INT, "0", RECU_DYNAMIC, RR_NULL, RECC_STR, "[0-2]", RECA_NULL}
Review Comment:
The validation regex `[0-2]` will accept multi-digit values like `10`
because the check uses a non-anchored regex match. This means invalid
`metric_enabled` values can pass records.yaml validation even though the
implementation later clamps them.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
