Kafka作为分布式消息队列系统,其稳定运行依赖于对集群状态的实时监控，通过命令行工具可以高效获取 broker、topic、consumer 等核心组件的运行指标，及时发现潜在问题，以下从集群状态、Topic 管理、Consumer 监控、日志分析等维度详细介绍 Kafka 监控相关命令及使用方法。

集群状态监控

查看 Broker 列表及状态

使用 kafka-broker-api-versions.sh（或旧版 kafka-list.sh）可以查看集群中所有 Broker 的信息，包括主机名、端口、支持的 API 版本等。

# 格式：kafka-broker-api-versions.sh --bootstrap-server <broker_list>
./bin/kafka-broker-api-versions.sh --bootstrap-server 192.168.1.1:9092,192.168.1.2:9092

执行后会返回每个 Broker 的 ID、主机、端口、运行的版本号，以及支持的协议（如 Produce、Fetch、Metadata 等），若某个 Broker 连接失败或协议不兼容，会明确标记异常状态。

查看集群元数据

通过 kafka-metadata-quorum.sh（Kafka 2.8+）可以查看 Quorum 控制器的状态，包括当前控制器节点、集群成员列表、日志状态等，确保元数据服务正常。

./bin/kafka-metadata-quorum.sh --bootstrap-server 192.168.1.1:9092 describe

重点关注 Leader 节点是否正常、InSyncReplicas (ISR) 列表是否完整，若控制器频繁切换或 ISR 列表过短，可能存在网络分区或 Broker 性能问题。

监控 Broker 级指标

使用 kafka-topics.sh 结合 --describe 参数可查看 Topic 的分区副本分布，间接反映 Broker 的负载情况：

./bin/kafka-topics.sh --bootstrap-server 192.168.1.1:9092 --describe --topic test-topic

输出字段包括：

• Topic: 主题名称
• Partition: 分区 ID
• Leader: 负责该分区读写的 Broker ID
• Replicas: 副本所在的 Broker ID 列表
• Isr: 同步副本列表（与 Leader 保持同步的副本集合）

若某个 Broker 的 Leader 分区数远高于其他节点，说明负载不均；若 Isr 列表长度为 1（仅 Leader），表示副本同步存在风险，需检查副本 follower 的状态。

Topic 级监控

查看 Topic 列表及详细信息

# 列出所有 Topic
./bin/kafka-topics.sh --bootstrap-server 192.168.1.1:9092 --list
# 查看指定 Topic 详细信息（分区数、副本数、压缩方式等）
./bin/kafka-topics.sh --bootstrap-server 192.168.1.1:9092 --describe --topic test-topic

通过输出可判断 Topic 配置是否合理，例如副本数是否满足高可用要求（通常建议 ≥3），Isr 列表是否稳定。

监控 Topic 生产/消费流量

Kafka 自带 JMX 监控功能，可通过 jconsole 或 visualvm 连接 Broker 的 JMX 端口（默认 9999），获取实时流量指标，关键指标包括：

• kafka.server:type=BrokerTopicMetrics,name=MessagesInPerSec: 每秒接收消息数
• kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec: 每秒接收字节数
• kafka.server:type=BrokerTopicMetrics,name=BytesOutPerSec: 每秒发送字节数

通过 jconsole 连接后，在 MBean 层级依次展开 kafka.server → BrokerTopicMetrics，即可查看上述指标的实时值。

查看 Topic 消息堆积情况

消息堆积可通过 Consumer 消费速率与 Producer 生产速率对比判断，但更直接的方式是检查 Topic 的 Log End Offset (LEO) 和 High Watermark (HW)：

# 查看分区的 LEO 和 HW
./bin/kafka-run-class.sh kafka.tools.GetOffsetShell --broker-list 192.168.1.1:9092 --topic test-topic --time -1

--time -1 表示获取最新偏移量，输出格式为 Topic:Partition:Offset。LEO 是日志末端偏移量（最新消息位置），HW 是已提交消息的最大偏移量（Consumer 可消费的最大位置），若 LEO - HW 值持续增大，说明消息堆积严重，需检查 Consumer 消费能力或分区配置是否合理。

Consumer 监控

查看 Consumer Group 列表

# 列出所有 Consumer Group
./bin/kafka-consumer-groups.sh --bootstrap-server 192.168.1.1:9092 --list

查看 Consumer Group 详细状态

# 查看指定 Group 的消费进度、分区分配情况等
./bin/kafka-consumer-groups.sh --bootstrap-server 192.168.1.1:9092 --describe --group test-group

输出字段包括：

• GROUP: Consumer Group 名称
• TOPIC: 订阅的 Topic
• PARTITION: 分区 ID
• CURRENT-OFFSET: Consumer 已提交的消费偏移量
• LOG-END-OFFSET: 分区最新消息偏移量（LEO）
• LAG: 消息堆积量（LOG-END-OFFSET - CURRENT-OFFSET）
• CONSUMER-ID: 消费者实例 ID
• HOST: 消费者主机地址

重点关注 LAG 值：若某个分区的 LAG 持续增加，说明该分区消费滞后；若 CONSUMER-ID 为空，可能表示消费者实例已退出但 Group 未重新平衡。

重置 Consumer 偏移量（解决消费异常）

当 Consumer 消费异常（如消息丢失或重复消费）时，可通过重置偏移量恢复：

# 重置到指定时间点的偏移量（示例：重置到 1 天前）
./bin/kafka-consumer-groups.sh --bootstrap-server 192.168.1.1:9092 --group test-group --reset-offsets --to-datetime 2023-10-01T00:00:00 --execute --topic test-topic
# 重置到最早/最新偏移量
./bin/kafka-consumer-groups.sh --bootstrap-server 192.168.1.1:9092 --group test-group --reset-offsets --to-earliest --execute --topic test-topic

--execute 参数表示直接执行重置，建议先使用 --dry-run 预览重置结果。

日志与性能监控

查看 Broker 日志

Broker 日志默认存储在 logs/ 目录下，关键日志文件包括：

• server.log: Broker 主日志，记录启动、分区分配、请求处理等信息
• controller.log: 控制器日志，记录 Controller 选举、分区 Leader 选举等操作
• state-change.log: 副本状态变更日志，记录副本同步状态变化

通过 grep 过滤关键字可快速定位问题：

# 查看分区 Leader 选举日志
grep "Leader election" logs/server.log
# 查看 Controller 切换日志
grep "Controller" logs/controller.log

使用 kafka-producer-perf-test.sh 和 kafka-consumer-perf-test.sh 测试性能

生产环境性能测试可验证集群的吞吐量和延迟：

# 生产者性能测试（发送 100 万条消息，每条 1KB）
./bin/kafka-producer-perf-test.sh --topic test-topic --num-records 1000000 --record-size 1024 --throughput 1000 --broker-list 192.168.1.1:9092
# 消费者性能测试（消费指定偏移量范围的消息）
./bin/kafka-consumer-perf-test.sh --topic test-topic --messages 1000000 --broker-list 192.168.1.1:9092 --offset 0

测试结果会包含平均吞吐量（MB/s）、平均延迟（ms）、P99 延迟等指标，若吞吐量低于预期或延迟过高，需检查 Broker 配置（如 num.network.threads、num.io.threads）或硬件资源（CPU、磁盘 I/O）。

常见监控指标速查表

相关问答 FAQs

Q1：如何判断 Kafka 集群是否存在网络分区问题？
A：可通过以下步骤判断：

1. 检查 kafka-broker-api-versions.sh 是否能连接所有 Broker，若部分 Broker 无响应，可能存在网络分区；
2. 查看 kafka-topics.sh --describe 中各分区的 Isr 列表，若多个分区的 Isr 频繁减少或仅剩 Leader，说明副本同步异常；
3. 检查 Broker 日志中的 NetworkProcessor 相关错误，若出现大量 "Connection reset" 或 "Timeout" 日志，网络分区可能性高。

Q2：Consumer Group 出现 Rebalance 频繁如何处理？
A：Rebalance 频繁通常由消费者实例变动、分区分配策略不合理或会话超时时间过短导致，处理方法：

1. 检查消费者代码是否正确处理 rebalance 回调，避免在回调中执行耗时操作；
2. 调整 session.timeout.ms（默认 30s）和 heartbeat.interval.ms（默认 3s）参数，确保心跳稳定；
3. 若消费者实例数远多于分区数,可减少消费者实例或增加分区数，避免 "StickyAssignor" 策略下的频繁重分配；
4. 检查消费者是否因 GC 停顿导致心跳超时，可通过 -XX:+PrintGC 日志分析 GC 情况，优化 JVM 参数。