Should Strimzi Metrics Reporter use separate default values for controller and broker nodes?

[scholzj]

Currently, we have exactly the same default metrics configuration for both controller and broker nodes. But some of the included metrics are only on brokers and some are only on controllers. That seems inefficient. Should we split this and have a separate default list for brokers and controllers (and merge them for mixed nodes?)

[fvaleri]

That seems inefficient.

I don't think it is inefficient. Do you have any number that shows that?

• Regex matching happens once per metric at registration, not during each Prometheus scrape.
• We have a single compiled pattern. All allowlist entries are combined into one regex, so matching cost is almost the same whether you have 2 or 100 patterns (regex length has minimal to no impact on matching performance).

[scholzj]

That seems inefficient.

I don't think it is inefficient. Do you have any number that shows that?

• Regex matching happens once per metric at registration, not during each Prometheus scrape.
• We have a single compiled pattern. All allowlist entries are combined into one regex, so matching cost is the same whether you have 2 or 100 patterns (regex length has minimal to no impact on matching performance).

TBH, I think the idea that because it is one regex, the cost is the same regardless of how complex it is seems pretty naive. And the matching maybe happens once per metric at registration, but I guess the metric registration does not happen once per an application lifetime.

[fvaleri]

You are suggesting that this is inefficient without any figure. That's naive. Sorry.

[scholzj]

Wouldn't a more tailored regex with fewer options always be more efficient because its complexity and time to execute will be a function of n, where n is the number of items in the list? Please teach me how that is a naive assumption, and show me where else we should add more unnecessary items to make things faster.

What I obviously don't have is any measure of how much more efficient the split configuration would be. So it would be fair to discuss whether the gain is not worth the effort. And whether the current implementation is maybe not as efficient as it could be, but good enough for its purpose.

However, one of the main motivations for the Strimzi Metrics Reporter was that Prometheus JMX Reporter is slow because it executes endless matching loops and that this impacts both the metric quality as well as Kafka performance (somehow, this was somehow assumed to be true without any figures, just based on the same assumption that I make here 🤔). This issue proposes to make things more efficient on the broker side with slightly more complexity on the operator side (i.e. not affecting the Kafka nodes). So I think that is in line with the general goals of the whole Strimzi Metrics Reporter effort.

[fvaleri]

Wouldn't a more tailored regex with fewer options always be more efficient because its complexity and time to execute will be a function of n, where n is the number of items in the list?

We build practical systems and we are probably talking about few nanoseconds here. Java is very efficient to optimize pattern matching.

So it would be fair to discuss whether the gain is not worth the effort. And whether the current implementation is maybe not as efficient as it could be, but good enough for its purpose.

Agreed. I'm just expressing my opinion here, and it is not fair to call it naive. Of course I would be happy with the extra complexity required to handle this if it is justified by a significant gain, but I doubt it.

[scholzj]

We build practical systems and we are probably talking about few nanoseconds here. Java is very efficient to optimize pattern matching.

I don't think this is something Java can really optimize. Less items in the list will always be faster than more items.

[scholzj]

Triaged on 8.1.2026: This makes sense.