>
> 1. Did you consider using a `default ClientTelemetryReceiver
> clientReceiver() { return null; }` method on the existing MetricsReporter
> interface, avoiding the need for the ClientTelemetry trait?I did. Part of the motivation was to separate more clearly the MetricsReporter methods which are more directly tied to the KafkaMetrics framework from the metrics collected from clients by the broker. It would also make it more explicit that this trait only makes sense in the context of a broker, unlike more general MetricsReporters which can be run inside client or connect plugins. That being said, ClientTelemetry would typically still rely on the configuration and context provided via the metrics reporter, so I agree that there might not be much value in a separate interface yet. Maybe we'd be better served if we did a clean break like we did in KIP-504 with the Authorizer interface and revampt the interfaces altogether. Currently the initialization of a metrics reporter is somewhat difficult, due to the mix of context information being provided via Reconfigurable, ClusterResourceListener, and MetricsContext. There is a lack of a clear initialization sequence, and detecting whether the reporter runs inside of a client, connect, or a broker is somewhat brittle. I felt that fixing those aspects would be outside of the scope of this KIP, which is already quite large, and would instead keep changes to existing interfaces minimal. I don't have a strong feeling though, so if we decide that having a default method is in line with our current conventions I'd be happy to change that.
