Hello, Igor. Thanks for the KIP. I have a couple of comments for it:
> Motivation > It is highly demanded in most businesses to have the ability of obtaining > audit information in case someone changes cluster configuration (like > creation/deletion/modify/description of any topic or ACLs). Can you, please, make it more specific? Why does a business want to have this information? What are the use-cases for it? Who will be analyzing these events and how? Why it’s not convenient to implement it with third-party tools? It’s not clear for me where and when AuditEvents will be sent? Who will be the receiver of events? > void audit<T extends AbstractRequest>(AuditEvent<T> event); 1. `audit` name sounds too general for me. How about `onEvent`? 2. Should we introduce a special marker interface for audit events? `AuditableRequest`, for example? > public interface AuditEvent<T extends AbstractRequest> { > String guid(); Where this `guid` comes from? Will it be the same on each node that receives an auditable event? Do we have `guid` for any extensions of `AbstractRequest`? If this field is `guid` why do we format this as a String on the API level? > One or more of AuditExtension's implementations can be configured via the > configuration audit.extension.classes Can you, please, add a full list of proposed new configuration properties and examples for each to clarify your intentions? > 24 янв. 2020 г., в 18:12, Alexander Dunayevsky <a.a.dunayev...@gmail.com> > написал(а): > > Hello Igor, > > Thanks for your KIP 🙌🏽 > It would be great to adopt this functionality and getting the best of > tracking cluster activity. > > +1 vote from me > > Cheers, > Alex Dunayevsky > > > On Fri, 24 Jan 2020, 15:35 Игорь Мартемьянов, <ledost...@gmail.com> wrote: > >> Motivation: >> >> >> *It is highly demanded in most businesses to have the ability of obtaining >> audit information in case someone changes cluster configuration (like >> creation/deletion/modify/description of any topic or ACLs).We may add this >> ability. Since audit requirements are so broad, it's impractical to support >> all of them.Hence we have to provide ability for users to plug resources >> helping to achieve required capabilities.* >> >> >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-567%3A+Kafka+Cluster+Audit >> >> >> пт, 24 янв. 2020 г., 17:29 Игорь Мартемьянов <ledost...@gmail.com>: >> >>> Hello there. >>> Please review this KIP. >>> Thanks. >>> >>