Status

Current state: VotingAdopted

Discussion thread: here 

JIRA: here

...

These will be exposed on the processor-level with topic level (newly added metrics scope by this KIP) with the following tags:

• type = stream-processor-node-metrics
• thread-id=[threadId]
• task-id=[taskId]
• processor-node-id=[processorNodeId]
• topic=[topic-name]

...

1. Including the corresponding -rate metrics alongside the -total metrics, as is often done for Streams metrics. For one thing reporting the cumulative sums should be sufficient for any monitoring service to compute the rate if desired, and furthermore allows that service to have full control over how this rate is defined and computed over what window of time.Another possibility that may occur to some while reading this is to round out the Streams metrics by introducing the corresponding processor-level metrics for the consumed throughput as well. I have left that out of this KIP for the reasons outlined above as the analogous consumer-side throughput values can already be derived just from the current suite of consume metrics. It should be noted however that this breaks down if/when the baseline assumption no longer holds that each consumer group, and thus Streams application, can only consume once from a given topic. Since the assumption is likely to hold for the foreseeable future it seems like overkill to expand the scope of this KIP to account for it, but it is worth noting nonetheless to make sure we're not caught off guard when it does finally comes to pass