+1 As a member of a team which operates several Kafka clusters, I am unequipped when it comes to troubleshooting issues with project teams that did not understand the importance of configuring client-side monitoring. Kafka represents a fraction of their work and they don't have enough experience, time or interest in trying to understand the meaning behind every metric.
I stand 100% behind what Colin stated back in June in the Discuss thread : > Magnus and I explained a few times the reasons why it does matter. Within > most organizations, there are usually several teams using clients, which > are separate from the team which maintains the Kafka cluster. The Kafka > team has the Kafka experts, which makes it the best place to centralize > collecting and analyzing Kafka metrics. Thanks for this KIP. Le mer. 26 janv. 2022 à 16:01, rifer...@riferrei.com <rifer...@riferrei.com> a écrit : > +1 > > I think this KIP solves a problem that has been around for some time with > Kafka deployments, which is the ability to assess the current state of a > Kafka architecture but looking at the whole picture. I also share other > folks' concerns regarding adding runtime dependencies to the clients; this > may be problematic for large deployments. Still, I think it is worth > refactoring. > > IMHO, it is a fair trade-off. > > — Ricardo > > > On Jan 26, 2022, at 9:34 AM, Magnus Edenhill <mag...@edenhill.se> wrote: > > > > Hi all, > > > > it's been a while and there's been some more discussions of the KIP which > > have been > > addressed on the KIP page. > > > > I think it's a good time to revive this vote thread and get things > moving. > > > > We're currently at +3 (non-binding) and -1 (non-binding) votes. > > > > Regards, > > Magnus > > > > > > Den mån 1 nov. 2021 kl 21:19 skrev J Rivers <jrivers...@gmail.com>: > > > >> +1 > >> > >> Thank you for the KIP! > >> > >> Our organization runs kafka at large scale in a multi-tenant > configuration. > >> We actually have many other enterprises connecting up to our system to > >> retrieve stream data. These feeds vary greatly in volume and velocity. > The > >> peak rates are a multiplicative factor of the nominal. There is extreme > >> skew in our datasets in a number of ways. > >> > >> We don't have time to work with every new internal/external client to > tune > >> their feeds. They need to be able to take one of the many kafka clients > and > >> go off to the races. > >> > >> Being able to retrieve client metrics would be invaluable here as it's > hard > >> and time consuming to communicate out of the enterprise walls. > >> > >> This KIP is important to us to expand the use of our datasets internally > >> and outside the borders of the enterprise. Our clients like the > performance > >> and data safeties related to the kafka connection. The observability has > >> been a problem... > >> > >> Jonathan Rivers > >> jrivers...@gmail.com > >> > >> > >> > >> > >> On Mon, Oct 18, 2021 at 11:56 PM Ryanne Dolan <ryannedo...@gmail.com> > >> wrote: > >> > >>> -1 > >>> > >>> Ryanne > >>> > >>> On Mon, Oct 18, 2021, 4:30 AM Magnus Edenhill <mag...@edenhill.se> > >> wrote: > >>> > >>>> Hi all, > >>>> > >>>> I'd like to start a vote on KIP-714. > >>>> https://cwiki.apache.org/confluence/x/2xRRCg > >>>> > >>>> Discussion thread: > >>>> https://www.mail-archive.com/dev@kafka.apache.org/msg119000.html > >>>> > >>>> Thanks, > >>>> Magnus > >>>> > >>> > >> > >
