Thanks for bumping this. I do have a concern: This proposal changes the names of existing metrics - as such, it will require all owners of monitoring systems to update their dashboards. It will also complicate monitoring of multiple clusters with different versions and require some modifications to existing monitoring automation systems.
What do you think of an alternative solution: 1. For the next release, add the validations on the broker side and print a "warning" that this client id is invalid, that it will break metrics and that it will be rejected in newer versions. 2. Few releases later, actually turn the validation on and return InvalidClientID error to clients. We did something similar when we deprecated acks=2. Gwen On Thu, Aug 31, 2017 at 12:13 PM Mickael Maison <mickael.mai...@gmail.com> wrote: > Even though it's pretty non controversial, I was expecting a few comments. > I'll wait until next week for comments then I'll start the vote. > > Thanks > > On Mon, Aug 21, 2017 at 6:51 AM, Mickael Maison > <mickael.mai...@gmail.com> wrote: > > Hi all, > > > > I have created a KIP to cleanup the way client-ids are handled by > > brokers and clients. > > > > Currently the Java clients have some restrictions on the client-ids > > that are not enforced by the brokers. Using 3rd party clients, > > client-ids containing any characters can be used causing some strange > > behaviours in the way brokers handle metrics and quotas. > > > > Feedback is appreciated. > > > > Thanks >
