[
https://issues.apache.org/jira/browse/KAFKA-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13527078#comment-13527078
]
Swapnil Ghike edited comment on KAFKA-646 at 12/8/12 6:17 AM:
--------------------------------------------------------------
Attached patch v2.
The changes from patch v1:
1. Deleted KafkaHistogram class. (There is also no need for KafkaMeter class.)
2. Deleted the Aggregated*Stats objects.
- The metrics of SyncProducer and SimpleConsumer for different brokers are
aggregated together using the same way the producerTopicStats are aggregated
for "All.Topics".
- Measuring the time for produce requests and fetch requests is achieved by
passing a list of timers to KafkaTimer.
was (Author: swapnilghike):
Attached patch v2.
The changes from patch v1:
1. Deleted KafkaHistogram class. (There is also no need for KafkaTImer class.)
2. Deleted the Aggregated*Stats objects.
- The metrics of SyncProducer and SimpleConsumer for different brokers are
aggregated together using the same way the producerTopicStats are aggregated
for "All.Topics".
- Measuring the time for produce requests and fetch requests is achieved by
passing a list of timers to KafkaTimer.
> Provide aggregate stats at the high level Producer and
> ZookeeperConsumerConnector level
> ---------------------------------------------------------------------------------------
>
> Key: KAFKA-646
> URL: https://issues.apache.org/jira/browse/KAFKA-646
> Project: Kafka
> Issue Type: Bug
> Affects Versions: 0.8
> Reporter: Swapnil Ghike
> Assignee: Swapnil Ghike
> Priority: Blocker
> Labels: bugs
> Fix For: 0.8
>
> Attachments: kafka-646-patch-num1-v1.patch,
> kafka-646-patch-num1-v2.patch
>
>
> WIth KAFKA-622, we measure ProducerRequestStats and
> FetchRequestAndResponseStats at the SyncProducer and SimpleConsumer level
> respectively. We could also aggregate them in the high level Producer and
> ZookeeperConsumerConnector level to provide an overall sense of
> request/response rate/size at the client level. Currently, I am not
> completely clear about the math that might be necessary for such aggregation
> or if metrics already provides an API for aggregating stats of the same type.
> We should also address the comments by Jun at KAFKA-622, I am copy pasting
> them here:
> 60. What happens if have 2 instances of Consumers with the same clientid in
> the same jvm? Does one of them fail because it fails to register metrics?
> Ditto for Producers.
> 61. ConsumerTopicStats: What if a topic is named AllTopics? We use to handle
> this by adding a - in topic specific stats.
> 62. ZookeeperConsumerConnector: Do we need to validate groupid?
> 63. ClientId: Does the clientid length need to be different from topic length?
> 64. AbstractFetcherThread: When building a fetch request, do we need to pass
> in brokerInfo as part of the client id? BrokerInfo contains the source broker
> info and the fetch requests are always made to the source broker.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
