Hi Andrew, thanks for this KIP. I had a few questions regarding the "Error handling" section.
1. It mentions that "The 5 and 30 minute retries are to eventually trigger a retry and avoid having to restart clients if the cluster metrics configuration is disabled temporarily, e.g., by operator error, rolling upgrades, etc." But this 30 min interval isn't mentioned anywhere else. What is it referring to? 2. For the actual errors: INVALID_RECORD : The action required is to "Log a warning to the application and schedule the next GetTelemetrySubscriptionsRequest to 5 minutes". Why is this 5 minutes, and not something like PushIntervalMs? And also, why are we scheduling a GetTelemetrySubscriptionsRequest in this case, if the serialization is broken? UNKNOWN_SUBSCRIPTION_ID , UNSUPPORTED_COMPRESSION_TYPE : just to confirm, the GetTelemetrySubscriptionsRequest needs to be scheduled immediately after the PushTelemetry response, correct? 3. For "Subsequent GetTelemetrySubscriptionsRequests must include the ClientInstanceId returned in the first response, regardless of broker": Will a broker error be returned in case some implementation of this KIP violates this accidentally and sends a request with ClientInstanceId = Null even when it's been obtained already? Or will a new ClientInstanceId be returned without an error? Thanks! On Tue, Jun 13, 2023 at 8:38 PM Andrew Schofield < andrew_schofield_j...@outlook.com> wrote: > Hi, > I would like to start a new discussion thread on KIP-714: Client metrics > and observability. > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-714%3A+Client+metrics+and+observability > > I have edited the proposal significantly to reduce the scope. The overall > mechanism for client metric subscriptions is unchanged, but the > KIP is now based on the existing client metrics, rather than introducing > new metrics. The purpose remains helping cluster operators > investigate performance problems experienced by clients without requiring > changes to the client application code or configuration. > > Thanks, > Andrew
