Hey Xavier, Thank you for working on this. This KIP looks very good to me.
Since these configs will work with Kafka's own metrics library, will the configs be part of the clients' configurations? It would be good to point that out explicitly in the KIP. I also second Viktor's question on what this would look like in practice. i.e if we had the following metric: *kafka.cluster:type=Partition,name=UnderMinIsr,topic=foobar,partition=9* Would the regex apply to the whole string? i.e would we be able to match parts of the string like `type=`, `name=`, `topic=`, or would it only apply to the values? Best, Stanislav On Mon, Oct 28, 2019 at 9:06 AM Viktor Somogyi-Vass <viktorsomo...@gmail.com> wrote: > Hi Xavier, > > How would the practical application look like if this was implemented? > Would monitoring agents switch between the whitelist and blacklist > periodically if they wanted to monitor every metrics? > I think we should make some usage recommendations. > > Thanks, > Viktor > > On Sun, Oct 27, 2019 at 3:34 PM Gwen Shapira <g...@confluent.io> wrote: > > > Thanks Xavier. > > > > I really like this proposal. Collecting JMX metrics in clusters with > > 100K partitions was nearly impossible due to the design of JMX and the > > single lock mechanism. Yammer's limitations meant that any metric we > > reported was exposed via JMX, so we couldn't have cheaper reporters > > export one set of metrics, and JMX export another. > > > > Your proposal looks like a great way to lift this limitation and give > > us more flexibility in reporting metrics. > > > > Gwen > > > > On Fri, Oct 25, 2019 at 5:17 PM Xavier Léauté <xav...@confluent.io> > wrote: > > > > > > Hi All, > > > > > > I wrote a short KIP to make the set of metrics exposed via JMX > > configurable. > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-544%3A+Make+metrics+exposed+via+JMX+configurable > > > > > > Let me know what you think. > > > > > > Thanks, > > > Xavier > > > -- Best, Stanislav
