我们使用消息队列的时候，是不是也遇到过这样的问题：

1、消息发出去了，却不知道消费成功没？

2、系统异常了，却不知道是哪一环节出了问题？

3、不知道是生产者发送异常、还是消费异常？

4、消息发送的量（TPS）有多少？是否有消息挤压也不清楚？

很多开发者以为 RocketMQ 只是发消息、收消息，实则不然。RocketMQ 官方还给我们提供了用于监控消息的控制台，RocketMQ 控制台（RocketMQ Console），它不仅能实时查看 Topic 消费状态、监控 Broker TPS、追踪消息轨迹，还是我们排查线上问题的直接工具。

本文我根据我的使用经验，分享从零上手 RocketMQ 控制台：从部署到操作，从功能到场景，把那些你忽略的细节讲透。看完这篇，控制台你也能使用的很熟练，建议初学者收藏！

---

RocketMQ 控制台是单独的服务（https://github.com/apache/rocketmq-dashboard），类似于控制面板有 Web 访问页面，管理消费者、生产者、消息、Topic、Broker 等，方便运维和排查问题。下面讲一下如何安装控制台和如何使用。

安装方法

前提条件：本机已安装 java 、maven 环境，同时已经启动了 nameserver 和 broker；

 1# 下载二进制报
 2wget https://github.com/apache/rocketmq-dashboard/archive/refs/tags/rocketmq-dashboard-2.0.0.tar.gz
 3# #解压后进入
 4tar -zxvf rocketmq-dashboard-2.0.0.tar.gz
 5cd ./rocketmq-dashboard-rocketmq-dashboard-2.0.0
 6# 构建jar包
 7mvn clean package -Dmaven.test.skip=true
 8# 启动jar
 9nohup java -jar rocketmq-dashboard-2.0.0.jar \
10--server.port=19095 \
11--rocketmq.config.namesrvAddr=127.0.0.1:9876 > dashboard.log 2>&1 &
12# 查看日志和进程
13tail -fn 10 dashboard.log
14ps -aux|grep rocketmq-dashboard
15
16# 关闭进程
17kill -15 676546
18
19#访问页面 确保端口可以访问
20http://localhost:19095

安装完毕后就可以进入页面查看了。

使用面板

进入面板之后首先切换为简体中文

 

驾驶舱

主要统计实时消息数量：包括 Broker 、Topic 信息。

集群

查看当前集群中所有的分片节点。关键信息：生产消息TPS 、消费消息的TPS，用于查询当前消息吞吐量。百万条消息TPS 15 左右。

 

主题

查询当前集群中所有的主题，可以根据主题类型进行筛选。关键功能：发送消息、重置消费点、跳过堆积。

发送消息用于测试消费者是否能正常消费；重置消费点用于重新消费消息；跳过堆积用于快速消费消息，跳过不重要的消息内容。

 

消费者

查询当前集群中所有的消费者，筛选消费者组。关键信息：消费者服务吞吐量、 delay 堆积未消费的消息、消费者终端IP

 

点击终端可以查询当前消费者组有多少消费者：

 

需要注意：客户端ID 格式为：客户端主机IP@BrokerIP:PROT@unitName，客户端ID必须要求唯一，因为NameServer 服务是K-V方式存储信息，每个消费者客户端会注册给命名服务器，如果客户端ID重复，那么NameServer服务就无法根据客户端 ID 找到正确的消费者客户端，导致消息路由异常，会阻塞（也可能能找对，找对了就能消费）。

构建客户端ID的源码如下 ：

 1public String buildMQClientId() {
 2    StringBuilder sb = new StringBuilder();
 3    sb.append(this.getClientIP());
 4
 5    sb.append("@");
 6    sb.append(this.getInstanceName());
 7    if (!UtilAll.isBlank(this.unitName)) {
 8        sb.append("@");
 9        sb.append(this.unitName);
10    }
11
12    return sb.toString();
13}

Docker 部署程序存在的问题：

如果使用 Docker 部署程序，由于 Docker 内是一个相对隔离的环境，并且 Docker 容器内大多数仅仅启动一个进程，而 Docker 启动第一个进程的进程 ID 都是 1，因此 PID 是相同的，由于 Docker 内部网络环境也是相对独立的，造成获取的客户端IP也是相同的。这时如果没有设置 unitName，就会造成多个消费者客户端客户端ID相同。

但是呢，为了防止客户端 ID 冲突，RocketMQ 在未手动配置 unitName 时，可能会自动生成一个类似 9848357816678676 的值，通常是 JVM 进程启动时间戳，用于确保 Client ID 唯一性。所以客户端ID 冲突的问题一般不用在意，了解下就可以了。

消息

查询每条消息的具体内容，这个功能非常实用：查看消息内容、消费时间、消费状态等消息，还可以重发消息；筛选消息的条件有：messageId ，messageKey、 topic；

 

 

每条消息都有消费详情，排查消息被哪个消费者消费了。其中 trackType 有一下几种：

NOT_ONLINE 代表该Consumer没有运行

CONSUMED 代表该消息已经被消费

NOT_CONSUME_YET 还没被消费

UNKNOW_EXCEPTION 报错

CONSUMED_BUT_FILTERED 消费了，但是被过滤了，一般是被 tag 过滤了，例如同一个主题，不同的 tag 会被过滤。

死信消息

当消费者消费失败后并且超过重试次数后，消息将会被投递到死信队列。如果消费者修复后重新上线，支持将死信消息批量重新投递。

RocketMQ 控制台不仅是一个可视化工具，更是一个开发者运维工具。如果你还在频繁查消息队列日志定位问题，不妨试着学会用用这款控制台工具，它能为你节省 80% 的排查时间，后面我还会更新更多实战技巧，记得关注～