Status

Current state: Under Discussion

Discussion thread: here 

JIRA: TODO 

Motivation

KIP-714 introduced the ClientTelemetryReceiver interface to enable MetricsReporter instances running on brokers to collect client telemetry metrics. Typically a reporter stores metrics it receives in a "metrics registry" and exposes them in a format suitable for the external monitoring system it is built for. This is exactly what JmxReporter does. Kafka clients and brokers explicitly delete their metrics when they are not used anymore. However for client telemetry metrics there isn't an explicit deletion mechanism.

Clients send their telemetry metrics at a regular interval, configured via telemetry subscriptions. Reporters are not aware of this push interval. Without the interval and an explicit deletion mechanism, reporters don't know when to clear client telemetry metrics and stop exposing them. This makes it hard to not expose stale metrics. Having uncertainty in metrics is a major problem as operators rely on them to manage their clusters and investigate issues.

This KIP proposes updating the context associated with each client telemetry push to include the push interval. This will enable reporters to properly manage the life cycle of client telemetry metrics.

Public Interfaces

package org.apache.kafka.server.telemetry;

import org.apache.kafka.server.authorizer.AuthorizableRequestContext;

/**
 * Context provided to {@link ClientTelemetryReceiver} implementations when receiving client metrics.
 */
public interface ClientTelemetryContext extends AuthorizableRequestContext {      
    /**
     * The interval defined via <code>metrics.interval</code> in the client metrics subscription
     * @return The interval in milliseconds
     */
    int pushIntervalMs();

    /**
     * The context associated with this request
     * @return The AuthorizableRequestContext associated with this request
     */
    AuthorizableRequestContext authorizableRequestContext();
}

Proposed Changes

Compatibility, Deprecation, and Migration Plan

The new method has a default implementation so it should not break existing classes implementing ClientTelemetryReceiver.

Implementations that want to benefit from the new context need to override both the new and old exportMetrics() methods. The body for the old method can be the following for example, since it won't be called if the new method is also implemented.

public void exportMetrics(AuthorizableRequestContext context, ClientTelemetryPayload payload) {
    throw new IllegalStateException("Should not be called");
}


The plan is to delete the now deprecated exportMetrics() method in the next major version, Kafka 5.0.0.

Test Plan

Adequate unit and integration tests will be added to ensure ClientTelemetryReceiver implementations use the old or new contexts.

Rejected Alternatives

N/A