Summary
After upgrading The JMX Exporter from 1.5.1 to 1.6.1, a metric that was previously discoverable as an untyped/unknown metric is now exposed as a counter with a _total suffix.
This appears to change behavior for metrics where the downstream library did not explicitly configure the type, and only optionally supports its own local heuristic for inferring counters from names.
Why this matters
JMX Exporter supports this config option:
inferCounterTypeFromName: true|false
Expected behavior from the JMX Exporter perspective:
- when
inferCounterTypeFromName: false, metrics without an explicit configured type should remain UNKNOWN
- when
inferCounterTypeFromName: true, names ending in _total may be treated as counters
After upgrading to client_java 1.6.1, it looks like client_java is applying counter naming/type behavior in a way that changes the effective metric identity for downstream code inspecting registry output.
Observed behavior
A generated metric based on JMX rule output is looked up under the name:
With 1.6.1, the actual scraped metric is:
kafka_consumer_request_total
and it is exposed as a counter snapshot.
In other words, the same logical downstream metric appears to have shifted from:
- unknown/untyped metric identity:
kafka_consumer_request
to:
- counter metric identity:
kafka_consumer_request_total
Why this looks like a regression
From the downstream library’s perspective, there is an important distinction between:
- explicit or locally inferred metric type, and
- Prometheus naming normalization
If the downstream library does not set type to counter, we would expect the metric to remain UNKNOWN.
If client_java now turns an untyped metric into counter-style exported identity purely because of naming rules, that seems to bypass downstream type semantics.
This is especially concerning for the equivalent of our inferCounterTypeFromName: false case, where the downstream library is explicitly saying “do not infer counter type from name”.
Reproduction shape
Using JMX Exporter-style logic, a rule generates a metric name from an attribute like request-total, resulting in a base metric name around:
There is no explicit configured type in the rule.
Expected with local inference disabled:
- metric remains
UNKNOWN
- metric remains discoverable as
kafka_consumer_request
Observed in 1.6.1:
- metric is exposed as
kafka_consumer_request_total
- metric is a counter snapshot
Impact
This breaks downstream tests and exact-name registry inspection logic, even though the downstream library did not explicitly opt into counter typing in the affected case.
Summary
After upgrading The JMX Exporter from
1.5.1to1.6.1, a metric that was previously discoverable as an untyped/unknown metric is now exposed as a counter with a_totalsuffix.This appears to change behavior for metrics where the downstream library did not explicitly configure the type, and only optionally supports its own local heuristic for inferring counters from names.
Why this matters
JMX Exporter supports this config option:
inferCounterTypeFromName: true|falseExpected behavior from the JMX Exporter perspective:
inferCounterTypeFromName: false, metrics without an explicit configured type should remainUNKNOWNinferCounterTypeFromName: true, names ending in_totalmay be treated as countersAfter upgrading to
client_java 1.6.1, it looks likeclient_javais applying counter naming/type behavior in a way that changes the effective metric identity for downstream code inspecting registry output.Observed behavior
A generated metric based on JMX rule output is looked up under the name:
kafka_consumer_requestWith
1.6.1, the actual scraped metric is:kafka_consumer_request_totaland it is exposed as a counter snapshot.
In other words, the same logical downstream metric appears to have shifted from:
kafka_consumer_requestto:
kafka_consumer_request_totalWhy this looks like a regression
From the downstream library’s perspective, there is an important distinction between:
If the downstream library does not set type to counter, we would expect the metric to remain
UNKNOWN.If
client_javanow turns an untyped metric into counter-style exported identity purely because of naming rules, that seems to bypass downstream type semantics.This is especially concerning for the equivalent of our
inferCounterTypeFromName: falsecase, where the downstream library is explicitly saying “do not infer counter type from name”.Reproduction shape
Using JMX Exporter-style logic, a rule generates a metric name from an attribute like
request-total, resulting in a base metric name around:kafka_consumer_requestThere is no explicit configured type in the rule.
Expected with local inference disabled:
UNKNOWNkafka_consumer_requestObserved in
1.6.1:kafka_consumer_request_totalImpact
This breaks downstream tests and exact-name registry inspection logic, even though the downstream library did not explicitly opt into counter typing in the affected case.