Hi, Rajini, Thanks for the KIP. A few comments.
1. We have 30+ requests and 30+ error code and growing. So, the combination can be large. Perhaps it's useful to expire an error metric if it's no longer updated after some time? We did something similar for the quota metric. 2. It's a bit weird to put the ZK latency metric under type=SessionExpireListener. Perhaps it's more intuitive to put it in a separate type. 3. For the client version metric, since we representing commit_id and version as tags in the metric name. So the mbean will have no attributes? Jun On Wed, Aug 16, 2017 at 4:05 PM, Roger Hoover <roger.hoo...@gmail.com> wrote: > I think it would useful to make clear somewhere for each metric, the level > at which it's counted. I don't know all the details of the Kafka protocol > but it might be something like > > ProduceRequest, Fetch Request - counted at per-partition level > All other requests are 1:1 with client requests? > > Cheers, > > Roger > > On Wed, Aug 16, 2017 at 4:02 PM, Roger Hoover <roger.hoo...@gmail.com> > wrote: > > > Rajini, > > > > Thank you for the KIP. These are very helpful additions. One question > on > > the error code metrics: > > > > Will the total error counting happen at the the level of topic partition? > > For example, if a single ProduceRequest contains messages to append to 3 > > partitions and say all 3 appends are successful, the counter > > for kafka.network:type=RequestMetrics,name=ErrorsPerSec,request= > ProduceRequest,error=0 > > will be incremented by 3? > > > > Thanks, > > > > Roger > > > > On Wed, Aug 16, 2017 at 12:10 PM, Rajini Sivaram < > rajinisiva...@gmail.com> > > wrote: > > > >> I have created a KIP to add some additional metrics to support health > >> checks: > >> > >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-188+-+ > >> Add+new+metrics+to+support+health+checks > >> > >> Feedback and suggestions are welcome. > >> > >> Regards, > >> > >> Rajini > >> > > > > >
