hi Mickael thanks for all sharing. it is great to know that all are in progress.
> Broker-side support is next on my todo list and that will include these metrics. KIP-877 appears to intend to allow authorizer implementations to write their own metrics. If this is the case, does KIP-877 plan to deprecate the ` Authorizer#aclCount` method, which is expected used to expose ACL count metrics? Best, Chia-Ping Mickael Maison <mickael.mai...@gmail.com> 於 2025年2月15日 週六 上午1:07寫道： > Hi Chia-Ping, > > The plan is to introduce these metrics as part of KIP-877 which > supersedes KIP-608: > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-877:+Mechanism+for+plugins+and+connectors+to+register+metrics#KIP877:Mechanismforpluginsandconnectorstoregistermetrics-KIP-608 > > So far we added: > - the initial APIs and client-side support in > > https://github.com/apache/kafka/commit/71314739f9b51fa5b443258d68019f58583704eb > - Connect support in > > https://github.com/apache/kafka/commit/c13324fc166fb44bc1ec428f25049dd7eec52364 > > Broker-side support is next on my todo list and that will include these > metrics. > > Thanks, > Mickael > > On Fri, Feb 14, 2025 at 5:41 PM Chia-Ping Tsai <chia7...@gmail.com> wrote: > > > > hi all, > > > > I'm revisiting authorizer metrics, which are currently absent from the > > codebase. While KIP-608 and KIP-801 both propose adding authorizer > metrics, > > neither of them has implemented the actual metrics. Since authorizer > > metrics are valuable for Kafka maintainers, I intend to implement them > > based on these accepted KIPs. > > > > However, I've identified some conflicts between the two KIPs regarding > > metric exposure: > > > > Q0: Who should expose the metrics? > > > > - > > > > KIP-608 suggests that the authorizer itself should expose its metrics > by > > receiving a server metrics object. > > - > > > > In contrast, KIP-801 proposes that the broker/controller should expose > > authorizer metrics by calling methods within the authorizer. > > - > > > > To align with both KIPs, I propose passing the server metrics object > to > > the authorizer, allowing it to define its own "custom" metrics. > > Additionally, the broker/controller should be responsible for exposing > > "general" authorizer metrics. > > > > Q1: What is the suitable metrics name? > > > > - > > > > KIP-608 proposes kafka.server:type=kafka.security.authorizer.metrics, > > while KIP-801 suggests kafka.server:type=Authorizer > > - > > > > I prefer the shorter naming convention. Therefore, I plan to use the > > following metrics names: > > - > > > > kafka.server:type=Authorizer,name=acls-total-count > > - > > > > > kafka.server:type=Authorizer,name=authorization-request-rate-per-minute > > > > - > > > > > kafka.server:type=Authorizer,name=authorization-allowed-rate-per-minute > > > > - > > > > > kafka.server:type=Authorizer,name=authorization-denied-rate-per-minute > > > > > > In short, I plan to implement authorizer metrics. This proposal addresses > > the conflicts between KIP-608 and KIP-801 regarding metric exposure. The > > feedback is welcomed! > > > > references: > > > > KIP-608 https://cwiki.apache.org/confluence/x/zBQRCQ > > > > KIP-801 https://cwiki.apache.org/confluence/x/h5KqCw > > > > Best, > > > > Chia-Ping >
