Hi all, I've updated the KIP following our recent discussions on the mailing list: - split the protocol in two, one for getting the metrics subscriptions, and one for pushing the metrics. - simplifications: initially only one supported metrics format, no client.id in the instance id, etc. - made CLIENT_METRICS subscription configuration entries more structured and allowing better client matching selectors (not only on the instance id, but also the other client resource labels, such as client_software_name, etc.).
Unless there are further comments I'll call the vote in a day or two. Regards, Magnus Den mån 4 okt. 2021 kl 20:57 skrev Magnus Edenhill <mag...@edenhill.se>: > Hi Gwen, > > I'm finishing up the KIP based on the last couple of discussion points in > this thread > and will call the Vote later this week. > > Best, > Magnus > > Den lör 2 okt. 2021 kl 02:01 skrev Gwen Shapira <g...@confluent.io.invalid > >: > >> Hey, >> >> I noticed that there was no discussion for the last 10 days, but I >> couldn't >> find the vote thread. Is there one that I'm missing? >> >> Gwen >> >> On Wed, Sep 22, 2021 at 4:58 AM Magnus Edenhill <mag...@edenhill.se> >> wrote: >> >> > Den tis 21 sep. 2021 kl 06:58 skrev Colin McCabe <cmcc...@apache.org>: >> > >> > > On Mon, Sep 20, 2021, at 17:35, Feng Min wrote: >> > > > Thanks Magnus & Colin for the discussion. >> > > > >> > > > Based on KIP-714's stateless design, Client can pretty much use any >> > > > connection to any broker to send metrics. We are not associating >> > > connection >> > > > with client metric state. Is my understanding correct? If yes, how >> > about >> > > > the following two scenarios >> > > > >> > > > 1) One Client (Client-ID) registers two different client instance id >> > via >> > > > separate registration. Is it permitted? If OK, how to distinguish >> them >> > > from >> > > > the case 2 below. >> > > > >> > > >> > > Hi Feng, >> > > >> > > My understanding, which Magnus can clarify I guess, is that you could >> > have >> > > something like two Producer instances running with the same client.id >> > > (perhaps because they're using the same config file, for example). >> They >> > > could even be in the same process. But they would get separate UUIDs. >> > > >> > > I believe Magnus used the term client to mean "Producer or Consumer". >> So >> > > if you have both a Producer and a Consumer in your application I would >> > > expect you'd get separate UUIDs for both. Again Magnus can chime in >> > here, I >> > > guess. >> > > >> > >> > That's correct. >> > >> > >> > > >> > > > 2) How about the client restarting? What's the expectation? Should >> the >> > > > server expect the client to carry a persisted client instance id or >> > > should >> > > > the client be treated as a new instance? >> > > >> > > The KIP doesn't describe any mechanism for persistence, so I would >> assume >> > > that when you restart the client you get a new UUID. I agree that it >> > would >> > > be good to spell this out. >> > > >> > > >> > Right, it will not be persisted since a client instance can't be >> restarted. >> > >> > Will update the KIP to make this clearer. >> > >> > /Magnus >> > >> >> >> -- >> Gwen Shapira >> Engineering Manager | Confluent >> 650.450.2760 | @gwenshap >> Follow us: Twitter | blog >> >
