Skip to content

KAFKA-19398: (De)Register oldest-iterator-open-since-ms metric dynamically#20022

Merged
mjsax merged 3 commits intoapache:trunkfrom
mjsax:kafka-19398-iterator-metric
Jun 25, 2025
Merged

KAFKA-19398: (De)Register oldest-iterator-open-since-ms metric dynamically#20022
mjsax merged 3 commits intoapache:trunkfrom
mjsax:kafka-19398-iterator-metric

Conversation

@mjsax
Copy link
Copy Markdown
Member

@mjsax mjsax commented Jun 23, 2025

The metric for oldest-iterator-open-since-ms might report a null value
if there is not open iterator.

This PR changes the behavior to dynamically register/deregister the
entire metric instead of allowing it to return a null value.

Reviewers: Bill Bejeck bbejeck@apache.org

@mjsax mjsax added the streams label Jun 23, 2025
…cally

The metric for oldest-iterator-open-since-ms might report a null value if there is not open iterator.

This PR changes the behavior to dynamically register/deregister the entire metric instead of allowing it to return a null value.
@mjsax mjsax force-pushed the kafka-19398-iterator-metric branch from 71192dc to 05e6afd Compare June 23, 2025 18:00
Copy link
Copy Markdown
Member

@bbejeck bbejeck left a comment

Choose a reason for hiding this comment

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

Thanks for the PR @mjsax overall looks good - just a couple of minor comments


public void add(final MeteredIterator iterator) {
openIterators.add(iterator);
numOpenIterators.increment();
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 not openIterators.size()?

Copy link
Copy Markdown
Member Author

@mjsax mjsax Jun 24, 2025

Choose a reason for hiding this comment

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

Seems this has historic reasons -- I just "refactored" existing code.

KIP-989 introduced 4 new metrics which got added by 4 PRs.

There was also a follow up PR fro numOpenIterators: #16076

@nicktelford do you see any reason why we need both variables, or can we unify them?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Guess we can also do this unification only in trunk to get this into 4.1 on time?

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.

Guess we can also do this unification only in trunk to get this into 4.1 on time?

That works for me

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I'm not certain, but it's possible the LongAdder and Set duplicating the counting functionality is just an oversight. In theory, using the LongAdder would yield improved performance vs. openIterators.size(), however, in practice the total number of open iterators is not likely to be large enough to be a problem, so it seems reasonable to remove numOpenIterators.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Are you interested to do a PR for this @nicktelford? If not, happy to do one myself.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Just did a quick PR for it: #20060

storeLevelMetrics.computeIfAbsent(key, ignored -> new LinkedList<>()).push(metricName);
}

return metricName;
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 does addX return the MetricName obejct?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

We need the MetricName to be able to remove it when the iterator count goes to zero.

final String storeName,
final StreamsMetricsImpl streamsMetrics,
final Gauge<Long> oldestOpenIteratorGauge) {
return streamsMetrics.addStoreLevelMutableMetric(
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.

Same question here

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Same answer :)


public void add(final MeteredIterator iterator) {
openIterators.add(iterator);
numOpenIterators.increment();
Copy link
Copy Markdown
Member Author

@mjsax mjsax Jun 24, 2025

Choose a reason for hiding this comment

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

Seems this has historic reasons -- I just "refactored" existing code.

KIP-989 introduced 4 new metrics which got added by 4 PRs.

There was also a follow up PR fro numOpenIterators: #16076

@nicktelford do you see any reason why we need both variables, or can we unify them?

storeLevelMetrics.computeIfAbsent(key, ignored -> new LinkedList<>()).push(metricName);
}

return metricName;
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

We need the MetricName to be able to remove it when the iterator count goes to zero.

final String storeName,
final StreamsMetricsImpl streamsMetrics,
final Gauge<Long> oldestOpenIteratorGauge) {
return streamsMetrics.addStoreLevelMutableMetric(
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Same answer :)

numOpenIterators.increment();

if (numOpenIterators.intValue() == 1) {
metricName = StateStoreMetrics.addOldestOpenIteratorGauge(taskId.toString(), metricsScope, name, streamsMetrics,
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Answer to your question: we need to remember the MetricName here, to be able to use it to remove the metric if the iterator count goes back to zero.

Copy link
Copy Markdown
Member

@bbejeck bbejeck left a comment

Choose a reason for hiding this comment

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

LGTM

@mjsax mjsax merged commit 4387132 into apache:trunk Jun 25, 2025
28 checks passed
@mjsax mjsax deleted the kafka-19398-iterator-metric branch June 25, 2025 00:02
@mjsax
Copy link
Copy Markdown
Member Author

mjsax commented Jun 25, 2025

Merged to trunk and cherry-picked to 4.1 branch.

mjsax added a commit that referenced this pull request Jun 25, 2025
…cally (#20022)

The metric for oldest-iterator-open-since-ms might report a null value
if there is not open iterator.

This PR changes the behavior to dynamically register/deregister the
entire metric instead of allowing it to return a null value.

Reviewers: Bill Bejeck <bbejeck@apache.org>
jiafu1115 pushed a commit to jiafu1115/kafka that referenced this pull request Jul 2, 2025
…cally (apache#20022)

The metric for oldest-iterator-open-since-ms might report a null value
if there is not open iterator.

This PR changes the behavior to dynamically register/deregister the
entire metric instead of allowing it to return a null value.

Reviewers: Bill Bejeck <bbejeck@apache.org>
jiafu1115 pushed a commit to jiafu1115/kafka that referenced this pull request Jul 3, 2025
…cally (apache#20022)

The metric for oldest-iterator-open-since-ms might report a null value
if there is not open iterator.

This PR changes the behavior to dynamically register/deregister the
entire metric instead of allowing it to return a null value.

Reviewers: Bill Bejeck <bbejeck@apache.org>
lucasbru added a commit to lucasbru/kafka that referenced this pull request Jul 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants