🚀 RocketMQ 运维实践：日志分析

熟悉 Broker 和 NameServer 日志文件的位置与关键信息

在 RocketMQ 的日常运维中，日志是排查问题的第一手资料。
当出现消息发送失败、消费延迟、Broker 宕机等问题时，必须通过分析 Broker 和 NameServer 的日志 来定位根因。

本文将系统化介绍 RocketMQ 的日志目录结构、关键日志文件、日志级别、常见日志格式与典型问题排查方法，帮助你快速掌握日志分析技能。

---

一、日志文件默认位置

RocketMQ 的日志路径由启动时的 -Drocketmq.home.dir 或环境变量 ROCKETMQ_HOME 决定。

默认路径：

$ROCKETMQ_HOME/logs/rocketmqlogs/

✅ 可通过 JVM 参数自定义：

-Dlogging.config=classpath:logback_broker.xml
-Drocketmq.log.root=/data/rocketmq/logs

---

二、Broker 日志文件详解

Broker 是核心服务节点，其日志最为丰富。

1. broker.log —— 主日志（最重要）

• 路径：$ROCKETMQ_HOME/logs/rocketmqlogs/broker.log
• 内容：
  • Broker 启动/关闭
  • 消息收发记录
  • 主从同步状态
  • CommitLog 写入
  • 消费者拉取请求
  • Rebalance 事件
  • 错误与异常堆栈

📌 典型日志示例：

INFO  [main] BrokerController: Start naming service
INFO  [NettyServerCodecThread_1] SendMessageProcessor: Receive SendMessage request
INFO  [CommitLog] MappedFile: create mapped file success /store/commitlog/00000000000000000000
WARN  [PullRequestHoldService] PullRequestHoldService: pull request timeout
ERROR [StoreStatsService] StoreStatsService: dispatch behind commit log 1000000 bytes

✅ 关键排查点：

• SendMessageProcessor：发送失败
• PullRequestHoldService：长轮询超时
• dispatch behind：写入落后，可能积压

---

2. namesrv.log —— NameServer 通信日志

• 记录 Broker 向 NameServer 注册、心跳等信息
• 用于排查路由问题

INFO  [NettyEventExecutor] RegisterBrokerRequestProcessor: Register broker succeeded
WARN  [HouseKeepingService] HouseKeepingService: remove registered broker

⚠️ 若出现 remove registered broker，表示 Broker 心跳超时，可能网络问题或宕机。

---

3. gc.log —— GC 日志（性能调优关键）

• 路径：$ROCKETMQ_HOME/logs/rocketmqlogs/gc.log
• 记录 JVM 垃圾回收详情

🔍 关键指标：

• Pause Time：GC 停顿时间（应 < 100ms）
• Frequency：GC 频率（频繁 Full GC 需警惕）

2024-05-01T10:11:30.123+0800: 1234.567: [GC pause (G1 Evacuation Pause) 1.234 secs]

✅ 建议：使用 gceasy.io 或 GCViewer 分析 GC 日志。

---

4. storeerror.log —— 存储错误日志

• 记录 CommitLog、ConsumeQueue 写入失败等严重错误
• 必须重点关注

ERROR [CommitLog] MappedFileQueue: Last mapped file is null
ERROR [Store] CommitLog: Append message to MappedFile error

❌ 出现此类日志，可能磁盘损坏或满，需立即处理。

---

5. dispatch.log / flush.log —— 存储调度日志（可选开启）

• 记录消息分发（dispatch）和刷盘（flush）延迟
• 用于性能分析

# 在 logback_broker.xml 中开启
<logger name="Dispatch" level="INFO"/>
<logger name="Flush" level="INFO"/>

---

三、NameServer 日志文件详解

NameServer 日志相对简单。

1. namesrv.log —— 主日志

• 路径：$ROCKETMQ_HOME/logs/rocketmqlogs/namesrv.log
• 内容：
  • 启动信息
  • Broker 注册与心跳
  • 路由查询请求
  • 异常连接

📌 典型日志：

INFO  [main] NamesrvController: NamesrvService started
INFO  [NettyServerCodecThread_2] RegisterBrokerRequestProcessor: Register broker[broker-a, 192.168.0.10:10911]
WARN  [HouseKeepingService] HouseKeepingService: remove broker connection

⚠️ 若 remove broker connection 频繁出现，说明 Broker 网络不稳定或未正确关闭。

---

四、日志级别说明

级别	说明	是否建议开启
FATAL	致命错误，服务无法继续	✅ 必须记录
ERROR	错误，如写入失败、网络异常	✅ 必须记录
WARN	警告，如心跳丢失、Rebalance	✅ 建议开启
INFO	信息，如启动、注册、收发	✅ 建议开启
DEBUG	调试信息，日志量大	⚠️ 生产慎用
TRACE	跟踪信息，性能影响大	❌ 生产关闭

✅ 生产环境建议：INFO 级别，关键模块可开 DEBUG

---

五、常见问题与日志特征对照表

问题	日志特征	排查方向
Broker 未注册到 NameServer	Register broker failed	网络、namesrvAddr 配置
消息发送失败	SEND_FAILED, RemotingTimeoutException	网络、Broker 负载、线程池满
消费积压严重	dispatch behind commit log	消费者处理慢、线程不足
磁盘满导致写入失败	No space left on device, storeerror.log	磁盘空间、fileReservedTime
GC 停顿高	gc.log 中 Full GC 频繁	JVM 参数、堆大小
主从同步延迟	Slave 日志中 sync from master 延迟高	网络带宽、磁盘 I/O
Rebalance 频繁	RebalanceService 日志频繁触发	网络抖动、GC 停顿、消费者频繁启停
消费者收不到消息	PullRequestHoldService 超时	消费者未正确订阅、Tag 不匹配

---

六、日志分析最佳实践

实践	说明
✅ 集中收集日志	使用 ELK（Elasticsearch + Logstash + Kibana）或 Loki + Promtail + Grafana
✅ 设置日志轮转	避免单个文件过大
✅ 关键日志告警	监控 ERROR、WARN 关键词
✅ 保留足够时间	建议保留 7~30 天
✅ 使用 grep / awk 快速定位	如 grep "SEND_FAILED" broker.log
✅ 结合 mqadmin 命令验证	如 consumerProgress 验证积压
✅ 记录变更前后日志	便于对比分析

---

七、常用日志分析命令

# 查看实时日志
tail -f $ROCKETMQ_HOME/logs/rocketmqlogs/broker.log

# 搜索发送失败
grep "SEND_FAILED\|RemotingSendRequestException" broker.log

# 查看 GC 日志中的停顿
grep "Pause" gc.log | awk '{print $NF}'

# 统计错误日志数量
grep -c "ERROR" broker.log

# 查看最近 100 行错误
tail -100 broker.log | grep "ERROR"

# 查看主从同步状态
grep "master sync" broker.log

---

✅ 总结

日志文件	作用	必须监控
broker.log	主日志，记录核心事件	✅ 是
gc.log	GC 情况，影响性能	✅ 是
storeerror.log	存储错误，可能丢消息	✅ 是
namesrv.log	路由注册状态	✅ 是
dispatch.log	写入延迟分析	⚠️ 可选

🚀 一句话总结：
日志是 RocketMQ 的“黑匣子”，
掌握 broker.log 和 gc.log 的分析能力，
你就能在系统出问题时，快速定位根因，真正做到“问题可追溯、故障可恢复”。

建议：将日志监控纳入日常巡检流程，结合告警系统，实现主动运维。