这条命令看什么
kafka-consumer-groups.sh 的 --describe 会逐分区打印消费组的当前位移、分区末尾位移与两者之差 LAG，并列出正在消费的成员。它是回答「积压有多少、积压在哪」的第一入口，比任何聚合报表都更快给出准确分布。
为什么不能只看总 lag
组级总 lag 只是一个求和值，会把结构问题抹平：一个分区落后一百万条，与十个分区各落后十万条，总数一样但处理方式完全不同。逐分区展开后才能区分是消费能力整体不足，还是个别分区热点或某个成员掉线。
基本信息
| 工具 | bin/kafka-consumer-groups.sh（新版发行版也提供 kafka-consumer-groups） |
|---|---|
| 必填参数 | --bootstrap-server、--describe、--group |
| 附加视图 | --members 看成员与分配；--state 看组状态 |
| 前提 | 组名必须与客户端 group.id 完全一致 |
| 权限要求 | 开启 ACL 时需要该组的 Describe 权限 |
典型使用场景
- 值班巡检：确认每个业务消费组的 lag 在阈值内，异常时抄下分区分布
- 排障第一步：区分整体积压与单分区热点，决定是扩容还是换分区键
- 新组首次上线：核对位移起点是否符合预期（从头重放还是只消费新数据）
- 停机窗口前：确认准备停用的消费组已经没有活跃成员
- 补数或位移重置后：校验位移是否推进到目标区间、lag 是否在收敛
常用三种视图
常用三种视图
# 逐分区位移与积压：排障最常用
kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
--describe --group order-consumer
# 成员与分区分配：看成员数、每个成员分到哪些分区
kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
--describe --group order-consumer --members --verbose
# 组状态：Stable 正常，PreparingRebalance / CompletingRebalance 说明正在再均衡
kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
--describe --group order-consumer --state输出逐列读法
| 列名 | 含义 | 正常/异常 |
|---|---|---|
| GROUP / TOPIC / PARTITION | 组名、主题名与分区号 | 组名与预期不一致说明查错了组 |
| CURRENT-OFFSET | 该分区下一条待消费的位置 | 小于 LOG-END-OFFSET 即为有积压 |
| LOG-END-OFFSET | 分区当前末尾位置（已写入条数） | 长期不增长说明生产侧已无新数据 |
| LAG | LEO 与已提交位移之差 | 持续上涨为异常；出现负值需先核对语义 |
| CONSUMER-ID | 当前消费该分区的成员标识 | 为空表示该分区当前无消费者 |
| HOST / CLIENT-ID | 成员所在主机与客户端标识 | 同一分区出现两个成员说明查询期间正在再均衡 |
汇总成一张积压清单
汇总成一张积压清单
# 只看每个分区的主题、分区与 LAG，便于贴进值班记录
kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
--describe --group order-consumer --members --verbose \
| awk 'NR==1 || $6+0>0 {print $1, $2, $3, $6}' # 过滤出有积压的分区行
# 按 lag 从大到小排序，一眼看出长尾分区
kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
--describe --group order-consumer | awk 'NR>1 {print $6, $0}' | sort -rn | headCONSUMER-ID 为空但组状态是 Stable，通常意味着该分区确实没有消费者（成员数少于分区数）；如果组状态在再均衡，则是分配尚未完成，稍等再看。
--members --verbose 会多打印 ASSIGNMENT 列，能看到每个成员持有的分区列表，是判断「分区是否分配均匀」的直接依据。
lag 阈值怎么定
阈值要按业务时效反推，而不是套一个统一数字：分钟级看板要求积压维持在几千以内，小时级报表允许几十万。把阈值写进监控并按分区维度告警，比只看组级总量更容易在业务侧感受到问题之前先发现苗头。
组名大小写与连接符写错时命令会返回「不存在该组」，很容易被误读成消费停止；核对组名时以客户端配置里的 group.id 为准，不要靠记忆拼写。
定时采样时把 CURRENT-OFFSET 与 LAG 一起记录下来，才能算出消费速率：只有消费速率持续低于生产速率，才说明消费能力真的不足，而不是短时堆积还没消化完。