Counter name/type inference changed in 1.6.1 for untyped metrics, breaking downstream expectation of UNKNOWN (original) (raw)

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:

• kafka_consumer_request

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:

1. explicit or locally inferred metric type, and
2. 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:

• kafka_consumer_request

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.