-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Conversation
Codecov Report
@@ 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
Flags with carried forward coverage won't be shown. Click here to find out 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())); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
producer.getTopic()
-> partition
?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-
If we change the method singuture, I'm not sure will it bring some compatible problem�, because this method is public.
-
The name of this method is
updateCumulativeStats
, doing some partitioned stats work is notcumulative
I think. How about add a new method likeupdatePartitionedStats()
:)
There was a problem hiding this comment.
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.
0427832
to
4aabf19
Compare
/** | ||
* @return stats for each partition if topic is partitioned topic | ||
*/ | ||
Map<String, ConsumerStats> getPartitionStats(); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
5309454
to
1e4111d
Compare
1e4111d
to
b25ee34
Compare
@codelipenghui @AnonHxy comments are addressed. can you PTAL. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lgtm
…on topic (#18212) * [improve] [client] Add api to get producer/consumer stats for partition topic * introduce partition topic stats interface
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
(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:)
Does this pull request potentially affect one of the following parts:
If the box was checked, please highlight the changes
Documentation
doc
doc-required
doc-not-needed
doc-complete
Matching PR in forked repository
PR in forked repository: