This vote has passed with 4 binding votes (Ismael, Jason, Jun, me) and 3 non-binding votes (Manikumar, Thomas Crayford, Mickael). Many thanks for the votes and feedback.
I will update the KIP page. Regards, Rajini On Fri, Sep 8, 2017 at 5:12 PM, Rajini Sivaram <rajinisiva...@gmail.com> wrote: > Thank you, Jun. > > If there are no other concerns by the end of the day, I will close the > vote tomorrow. > > > On Fri, Sep 8, 2017 at 5:09 PM, Jun Rao <j...@confluent.io> wrote: > >> Hi, Raijini, >> >> Thanks for the explanation. We can leave those as they are then. >> >> Jun >> >> On Thu, Sep 7, 2017 at 3:23 AM, Rajini Sivaram <rajinisiva...@gmail.com> >> wrote: >> >> > Hi all, >> > >> > I have added one more metric to KIP-188 to show the current status of >> > broker's ZooKeeper connections. Please let me know if you have any >> > concerns. >> > >> > Hi Jun, >> > >> > I was wondering which is a better group for >> FetchMessageConversionsPerSec, >> > now that we have MessageConversionsTimeMs at the request level. I don't >> > have a strong opinion either way, but at the moment, as a topic metric, >> > xxxMessageConversionsPerSec is along with MessagesInPerSec, >> > TotalFetchRequestsPerSec etc. which are all kind of related and are all >> > rate metrics. If we move it to the request level, we will >> > have MessageConversionsTimeMs and MessageConversionsPerSec together, but >> > will lose the topic grouping. Since all the other metrics at request >> level >> > are time histograms, perhaps it is better to leave >> MessageConversionsPerSec >> > along with the other topic rate metrics? >> > >> > I had added a ZooKeeperClient wrapper for my initial PR, but I will >> rebase >> > on Onur's code when it is ready. Thank you! >> > >> > Many thanks, >> > >> > Rajini >> > >> > On Wed, Sep 6, 2017 at 10:52 PM, Jun Rao <j...@confluent.io> wrote: >> > >> > > Hi, Raijini, >> > > >> > > Thanks for the KIP. +1. Just a minor comment. >> > > >> > > Since we only measure MessageConversionsTimeMs at the request type >> level, >> > > is it useful to collect the following metrics at the topic level? >> > > >> > > *MBean*: >> > > kafka.server:type=BrokerTopicMetrics,name=FetchMessageConver >> sionsPerSec, >> > > topic=([-.\w]+) >> > > >> > > *MBean*: >> > > kafka.server:type=BrokerTopicMetrics,name=ProduceMessageConv >> ersionsPerSe >> > > c,topic=([-.\w]+) >> > > >> > > >> > > Also, for the ZK latency metric, Onur added a new ZookeeperClient >> wrapper >> > > and is in the middle of converting existing zkClient usage to the new >> > > wrapper. So, we probably want to add the latency metric in the new >> > wrapper. >> > > >> > > Jun >> > > >> > > On Thu, Aug 24, 2017 at 10:50 AM, Rajini Sivaram < >> > rajinisiva...@gmail.com> >> > > wrote: >> > > >> > > > Hi all, >> > > > >> > > > I would like to start the vote on KIP-188 that adds additional >> metrics >> > to >> > > > support health checks for Kafka Ops. Details are here: >> > > > >> > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP- >> > > > 188+-+Add+new+metrics+to+support+health+checks >> > > > >> > > > Thank you, >> > > > >> > > > Rajini >> > > > >> > > >> > >> > >
