So the KIP proposes exposing the metrics registry (second paragraph under motivation). The community has indicated that they would like to 1. access all the metrics and 2. register their own. We provide some helper interfaces for them to register throughput and latency metrics, but ultimately we felt it's best for them to have access to the full registry as well. This is because application code is now intertwined with the streams library and we don't want to limit the kinds of metrics they might want to register, nor do we necessarily want to provide yet another wrapper around Metrics.
Thanks, Eno > On 6 Jan 2017, at 20:34, Ismael Juma <ism...@juma.me.uk> wrote: > > Thanks for the KIP. Sounds useful. One thing that wasn't made clear is that > we are exposing `Metrics` as a public class for the first time. Neither the > consumer or producer expose it at the moment. Do we want to expose the > whole class or would it be better to expose a more limited interface? > > Ismael > > On Sat, Dec 31, 2016 at 4:26 AM, Aarti Gupta <aartigup...@gmail.com> wrote: > >> Hi all, >> >> I would like to start the discussion on KIP-104: Granular Sensors for >> Streams >> <https://cwiki.apache.org/confluence/display/KAFKA/KIP- >> 104%3A+Granular+Sensors+for+Streams?src=contextnavchildmode> >> >> *https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=67636480 >> <https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=67636480 >>> * >> >> Looking forward to your feedback. >> >> Thanks, >> Aarti and Eno >>
