我会按 Topic/partition 看 lag 和消费速率，而不是只看总数。若 lag 集中一个分区，检查 key 倾斜和该分区当前 owner；所有分区都慢，再拆消费耗时：poll、反序列化、数据库、RPC、提交位点分别多久。CPU 低往往说明线程在等连接、锁或下游。

还会查 rebalance 次数、max.poll.interval、消费错误和重试。某条毒消息无限重试会让一个分区完全不前进；数据库连接池满时扩消费者只会增加等待。

恢复时先保护依赖：暂停非核心消费，修复或隔离毒消息，扩容前确认分区数和下游余量；能批量写库就提高批次，暂时关闭昂贵的非核心步骤。按“当前净消化速度”估算清空时间。

积压追平后再恢复正常限额，持续看生产速率、消费速率和 lag 斜率。一次性开很大并发容易把积压事故升级成数据库事故。