Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[improve] [client] Add api to get producer/consumer stats for partition topic #18212

Merged
merged 2 commits into from
Nov 1, 2022

Conversation

rdhabalia
Copy link
Contributor

@rdhabalia rdhabalia commented Oct 26, 2022

Motivation

Right now, client is not able to fetch producer/consumer stats for individual partition if topic is partitioned topic and it returns non-set value 0 or some aggregate value across all partitions which is not useful if client wants to track individual partition in case if any specific partition is having issue at broker side and individual partition metrics are useful for debugging issue specially various latency metrics.

Modifications

Add API to fetch producer/consumer stats for partition topics.

Verifying this change

  • Make sure that the change passes the CI checks.

(Please pick either of the following options)

This change is a trivial rework / code cleanup without any test coverage.

(or)

This change is already covered by existing tests, such as (please describe tests).

(or)

This change added tests and can be verified as follows:

(example:)

  • Added integration tests for end-to-end deployment with large payloads (10MB)
  • Extended integration test for recovery after broker failure

Does this pull request potentially affect one of the following parts:

If the box was checked, please highlight the changes

  • Dependencies (add or upgrade a dependency)
  • The public API
  • The schema
  • The default values of configurations
  • The threading model
  • The binary protocol
  • The REST endpoints
  • The admin CLI options
  • Anything that affects deployment

Documentation

  • doc
  • doc-required
  • doc-not-needed
  • doc-complete

Matching PR in forked repository

PR in forked repository:

@codecov-commenter
Copy link

codecov-commenter commented Oct 26, 2022

Codecov Report

Merging #18212 (b25ee34) into master (6c65ca0) will increase coverage by 3.73%.
The diff coverage is 34.64%.

Impacted file tree graph

@@             Coverage Diff              @@
##             master   #18212      +/-   ##
============================================
+ Coverage     34.91%   38.64%   +3.73%     
- Complexity     5707     8248    +2541     
============================================
  Files           607      685      +78     
  Lines         53396    67351   +13955     
  Branches       5712     7216    +1504     
============================================
+ Hits          18644    26029    +7385     
- Misses        32119    38330    +6211     
- Partials       2633     2992     +359     
Flag Coverage Δ
unittests 38.64% <34.64%> (+3.73%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
...org/apache/bookkeeper/mledger/LedgerOffloader.java 0.00% <ø> (ø)
...che/bookkeeper/mledger/LedgerOffloaderFactory.java 0.00% <ø> (ø)
...pache/bookkeeper/mledger/LedgerOffloaderStats.java 0.00% <ø> (ø)
...ookkeeper/mledger/LedgerOffloaderStatsDisable.java 0.00% <ø> (ø)
...a/org/apache/bookkeeper/mledger/ManagedCursor.java 85.71% <ø> (ø)
...che/bookkeeper/mledger/ManagedLedgerException.java 41.17% <ø> (ø)
...bookkeeper/mledger/ManagedLedgerFactoryConfig.java 86.66% <ø> (ø)
...g/apache/bookkeeper/mledger/ManagedLedgerInfo.java 22.22% <ø> (ø)
...he/bookkeeper/mledger/OffloadedLedgerMetadata.java 0.00% <ø> (ø)
...ava/org/apache/bookkeeper/mledger/ScanOutcome.java 0.00% <ø> (ø)
... and 726 more

@@ -353,7 +353,8 @@ public synchronized ProducerStatsRecorderImpl getStats() {
return null;
}
stats.reset();
producers.values().forEach(p -> stats.updateCumulativeStats(p.getStats()));
producers.forEach(
(partition, producer) -> stats.updateCumulativeStats(producer.getTopic(), producer.getStats()));
Copy link
Contributor

Choose a reason for hiding this comment

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

producer.getTopic() -> partition ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

here, we are keeping map of <topicName, stats> to maintain consistency with consumer-stats.
so, code change is correct where we are not using partition but we are using actual topic name of the partition.

Copy link
Contributor

Choose a reason for hiding this comment

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

make sense

@@ -145,7 +146,12 @@ public void reset() {
}

@Override
public void updateCumulativeStats(ConsumerStats stats) {
public void updateCumulativeStats(String partition, ConsumerStats stats) {
Copy link
Contributor

Choose a reason for hiding this comment

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

  1. If we change the method singuture, I'm not sure will it bring some compatible problem�, because this method is public.

  2. The name of this method is updateCumulativeStats, doing some partitioned stats work is not cumulative I think. How about add a new method like updatePartitionedStats() :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have removed the api change.

/**
* @return stats for each partition if topic is partitioned topic
*/
Map<String, ConsumerStats> getPartitionStats();
Copy link
Contributor

Choose a reason for hiding this comment

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

Here is not only about partition stats. Users can provide topic lists and topic patterns.
Is it better to use a new interface MultiTopicConsumerStats extends ConsumerStats?

For the producer side, we can have a new interface PartitionedTopicProducerStats extends ProducerStats

So that we can add new methods to the MultiTopicConsumerStats and PartitionedTopicProducerStats such getStatsForInternalTopics and getStatsForPartitions

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes, sure, we can have separate interface for partitioned topic with more clear code.
However, the current implementation with combined stats-recorder and stats-interface implementation has complicated things though they are two separate entities (recorder can't become stats but recorder should record the stats ). combining both entities incorrectly complicates the inheritance.
We also should still keep the Partitioned topic abstraction from user. Producer/Consumer::getStats() should return one interface with all required API and user doesn't have to cast based on topic type. Because Partitioned-topic-stats are just a collection of stats so, we should have getPartitionedTopicStats() API with in Stats interface and it should return empty response if topic is not partitioned topic.
Atleast this will be a good start to creating the abstraction and without having existing API changes in this PR.
I will create a separate PR with further improvement.

This PR has addressed all comments.

@rdhabalia
Copy link
Contributor Author

@codelipenghui @AnonHxy comments are addressed. can you PTAL.

Copy link
Contributor

@eolivelli eolivelli left a comment

Choose a reason for hiding this comment

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

Lgtm

@rdhabalia rdhabalia merged commit 26f9ffa into apache:master Nov 1, 2022
Technoboy- pushed a commit that referenced this pull request Nov 3, 2022
…on topic (#18212)

* [improve] [client] Add api to get producer/consumer stats for partition topic

* introduce partition topic stats interface
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants