Skip to content

Use role-based default allowlists for Strimzi Metrics Reporter - #12966

Open
saksham869 wants to merge 1 commit into
strimzi:mainfrom
saksham869:fix/metrics-reporter-role-based-allowlist
Open

Use role-based default allowlists for Strimzi Metrics Reporter#12966
saksham869 wants to merge 1 commit into
strimzi:mainfrom
saksham869:fix/metrics-reporter-role-based-allowlist

Conversation

@saksham869

Copy link
Copy Markdown

Description

Closes #12181

Currently, the Strimzi Metrics Reporter uses a single default allowlist for all Kafka nodes regardless of their role. This means broker-only metrics are sent to controller nodes and controller-only metrics are sent to broker nodes.

Changes

  • Split DEFAULT_METRICS_ALLOW_LIST into three role-specific lists:
    • BROKER_DEFAULT_METRICS_ALLOW_LIST — broker-only metrics
    • CONTROLLER_DEFAULT_METRICS_ALLOW_LIST — controller-only metrics
    • MIXED_DEFAULT_METRICS_ALLOW_LIST — union of both (for mixed nodes)
  • Added metricsForPool(KafkaPool) helper in KafkaCluster to select the appropriate model per pool at config generation time
  • Added isCustomAllowList() to StrimziMetricsReporterModel to distinguish user-configured vs default allowlists
  • Added StrimziMetricsReporterModel(List<String>) constructor for direct default injection
  • Added test testStrimziMetricsReporterDefaultAllowListIsRoleBased verifying role-based defaults per pool

Type of change

  • New feature

Checklist

  • Write tests
  • Make sure all tests pass

@snyk-io

snyk-io Bot commented Jul 17, 2026

Copy link
Copy Markdown

Snyk checks have passed. No issues have been found so far.

Status Scan Engine Critical High Medium Low Total (0)
Open Source Security 0 0 0 0 0 issues
Licenses 0 0 0 0 0 issues
Code Security 0 0 0 0 0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

@saksham869
saksham869 force-pushed the fix/metrics-reporter-role-based-allowlist branch from 04f0516 to c698ea9 Compare July 18, 2026 19:24

@scholzj scholzj left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR. I had a look and left some comments. However, I wonder if in general the correct way forward would be to:

  • In the StrimziMetricsReporterModel constructor, pass only the configuration and if the allow list is set, validate and store it. Otherwise, just store null
  • Change getAllowList to something like getAllowListOrDefault where you pass the default as the parameter. It would check if the allow list is not null and return it. If it is null, it would return the default.

That way, you do not to have multiple instances of the object with different defaults etc. And the impact on the other classes should be minimal as they anyway have the defaults in the constsnt.

PS: Ideally you should use the PR template we have for the PR description.

validate(config);
this.allowList = config.getValues() != null && config.getValues().getAllowList() != null
? config.getValues().getAllowList() : defaultAllowList;
boolean hasCustomList = config.getValues() != null && config.getValues().getAllowList() != null;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this be directly this.customAllowList?

Comment on lines +163 to +166
private static final List<String> MIXED_DEFAULT_METRICS_ALLOW_LIST = Stream.concat(
BROKER_DEFAULT_METRICS_ALLOW_LIST.stream(),
CONTROLLER_DEFAULT_METRICS_ALLOW_LIST.stream()
).distinct().toList();

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why can't you just create a new list and add both lists to it? Or maybe even better, join them on demand when needed instead of keeping it as a constant?

@scholzj

scholzj commented Jul 30, 2026

Copy link
Copy Markdown
Member

@saksham869 Any chance/plans to get back to this? Thanks.

@saksham869

Copy link
Copy Markdown
Author

@saksham869 Any chance/plans to get back to this? Thanks.

Hi @scholzj , yes — I'm actively working on the refactor based on your feedback. Implementing the getAllowListOrDefault(List<String>) approach and removing the secondary constructor. Will push the updated commit shortly.

@scholzj

scholzj commented Jul 30, 2026

Copy link
Copy Markdown
Member

Great, thanks.

@saksham869
saksham869 force-pushed the fix/metrics-reporter-role-based-allowlist branch from c698ea9 to 8a174ca Compare July 30, 2026 21:29
Split the single DEFAULT_METRICS_ALLOW_LIST into three role-specific
lists: BROKER_DEFAULT_METRICS_ALLOW_LIST, CONTROLLER_DEFAULT_METRICS_ALLOW_LIST,
and MIXED_DEFAULT_METRICS_ALLOW_LIST (union of both).

When no custom allowlist is configured, each Kafka node pool now receives
only the metrics relevant to its role. Broker-only nodes get broker
metrics, controller-only nodes get controller metrics, and mixed nodes
get the union of both.

Adds isCustomAllowList() to StrimziMetricsReporterModel and a new
StrimziMetricsReporterModel(List<String>) constructor for direct
default injection. Adds metricsForPool(KafkaPool) helper in
KafkaCluster to select the appropriate model per pool.

Closes strimzi#12181

Signed-off-by: saksham869 <[email protected]>
@saksham869
saksham869 force-pushed the fix/metrics-reporter-role-based-allowlist branch from 8a174ca to 8d089ae Compare July 30, 2026 22:15

@scholzj scholzj left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the changes. I think they look good.

One thing I noticed through:

  • The default metrics are now always defined in a different class from where they are used. So, I think it would make sense to move them to the configuration builder classes and use them locally?
    • It would save us the effort to pass them through the builder methods
    • The KafkaBrokerConfigurationBuilder already has the node field that can be used to decide which metric to use.
  • It would also simplify the tesst as the broker/controler stuff will be now testable from the KafkaBrokerConfigrationBuilder tests directly without the need to test it in KafkaClusterTest.

What do you think?

Comment on lines +165 to +169
for (String s : CONTROLLER_DEFAULT_METRICS_ALLOW_LIST) {
if (!mixed.contains(s)) {
mixed.add(s);
}
}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume you do this to avoid duplicates? I wonder if we should use Sets instead of Lists for the defaults 🤔. But maybe that is something to fix separately.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

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

2 participants