...

1. How many partitions are currently paused? A number of paused partitions may indicate backpressure issues, slow state restoration, or application-level processing bottlenecks.
2. Which specific partitions are paused? Knowing which partitions are paused helps pinpoint which topics or partitions are experiencing issues.
3. How long has a partition been paused? A partition that has been paused for an extended period may indicate a stuck consumer, an unrecoverable error in processing, or a state store restoration that is taking too long.
4. How frequently are partitions being paused? A high rate of pause calls may indicate instability in the application's flow control logic or repeated rebalances triggering pause/resume cycles.

This KIP proposes adding new consumer metrics that track paused partitions and their pause duration.

...

Note: These are per-partition metrics. Operators should be aware that registering metrics per partition increases cardinality , consistent with existing per-partition consumer metrics such as records-lag  and records-lead . Cardinality increases linearly with the number of assigned partitions. In environments with large partition counts, this , which may increase memory usage in the metrics registry and in downstream monitoring systems. The paused-partitions-count aggregate metric is available at INFO level for general monitoring, while the per-partition metrics are intended for detailed debugging when partition-level visibility is needed.

Proposed Changes

Track Pause Timestamp

...