Page History

...

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.
2. In addition the -total metrics don't require checking the current system time as an input and thus don't have the potential performance impact of the -rate or other time-based metrics discussed in previous KIPs. This means we can avoid the tradeoff and feel safe reporting these new metrics at the INFO level despite typically reporting anything task-level or below at DEBUG.
3. Another possibility that may occur to some while reading this is to round out the Streams metrics by introducing the corresponding task-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