Hi Ismael, Thank you for your feedback.
As you mentioned in [0] we make a conscious attempt to not deprecate request versions used by "recent enough" clients. It also followed from my observations that the number of users that use an old enough client are low and therefore I didn't consider high cardinality to be a big risk initially. However, I do understand that it's hard to make general assumptions about the usage of old clients - some usecases may have a lot of users stuck on old client versions and therefore lead to an inadvertent cardinality explosion on a broker upgrade. Perhaps we can gate adding the `user` tag on a config and have cluster administrators opt into it? I see a precedent for such an approach in DefaultQuotaCallback where we add the user tag only if UserQuota or UserClientIdQuota is enabled. Regards, Gaurav [0]: https://lists.apache.org/thread/bnyh96q06rtbjvxoy99tozovkd723hjn > On 3 Oct 2025, at 19:22, Ismael Juma <[email protected]> wrote: > > Hi, > > Thanks for the KIP. This is definitely useful, but one concern is the large > cardinality - have you considered how to deal with that? > > Ismael > > On Fri, Oct 3, 2025 at 10:37 AM Gaurav Narula <[email protected]> wrote: > >> Hi Everyone, >> >> I'd like to start a discussion on KIP-1223: Add user tag to >> DeprecatedRequestsMetric >> >> >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1223%3A+Add+user+tag+to+DeprecatedRequestsMetric >> >> This will help Kafka administrators identify users who're using old >> clients that send deprecated requests. >> >> Looking forward to your comments. >> >> Regards, >> Gaurav Narula
