RocketMQ之console监控平台使用详解(三)

jujusharp  •  May 9, 2019 7:01:23 PM

原文地址


以前看别人文章时,经常说文章写一半因为某某原因重新写。今天我也碰到了,上午写了三分之一,电脑锁屏,下午过来直接写文章的软件退出了。

简直日了狗。吸取教训。

现在网上“同质性”的技术文章太多了,本来想了解下rocketmq-console监控平台的文档使用,不知道是搜索姿势有问题还是没这需求,找到的全是rocketmq-console的部署安装。测试了很遍,结合理解,差不都搞懂了很多关于此监控平台的用法,分享记录一波。

1.OPS

这里很容易看清楚,双击标签可以修改NameSerIP+Port。这里我测试过修改端口,发现重新发送一样的消息,还是能消费。

其实也能理解,因为NameSer改变了,也只是使得Broker不能从本地获取最新的路由信息。但是本地还是缓存了路由信息,所以一样的Topic还是能获取到路由信息,可以获取到路由信息还是能发送到Brokder

所以这里我的测试是一次失败的对照测试,但是这个模块平时需求不大,就过了。

2.Dashboard

此图表较简单,其实是指所有Brokder处理消息的数量。比如从上图可以看出来,我只有一个Brokder,并且此Brokder处理了6条消息。

此图标可以筛选出某个Topic下5分钟的消息数量。但是可以切换时间,所以就相当于可以查看某个Topic下的消息数量趋势。

这条趋势曲线有时候貌似不准确,测试过几次有一次在那个时间点并没有变化。

3.Cluster

这里有点坑,Cluster翻译过来叫集群。这里并不是指消费模式中的集群消费,而是指Brokder的集群部署

但是我这里并没有使用Broker的集群部署,所以只有一条数据。如果有多个broker那这里应该有多行数据。

每一行中各项代表的意思如下

  • Broker --- Broker的名字
  • Address --- 地址
  • Today Produce Count --- 今天发送的消息数量
  • Today Consume Count ---- 今天消费的消息数量

4.Topic

Topic算是重点之一。

这里的ADD/UPDATE是有作用的,可以在这里添加一个Topic,经过测试,感觉在这里意义不大。这里涉及到**消息的发送消费与TopicBroker**的关系,下篇文章分析。

每一行的Topic分成如下几个操作按钮

mark

点击第一个[status]按钮。显示如下界面。可以从中获取的信息比较多。该消息队列的TopicBrokerNamequeueId

这里涉及到发送消息的原理。简单来说

通过一个Topic可以获取到对应的路由信息,路由信息里面维护了消息队列集合,而我们发送消息其实就是通过消息队列发送

消息队列集合是个集合,所以也是有集合的属性。其中每一项就是消息队列,就是如下图的每一行,每一行在集合中的位置就是queueId

mark

点击第二项是保存在NameSer的路由信息。

mark

这里可能要注意下。保存在NameServer的路由信息和本地缓存的不一样,本地缓存的属性内容更丰富更多。看看源码吧!

保存在NameSer的路由对象

public class TopicRouteData extends RemotingSerializable {
    private String orderTopicConf;
    private List<QueueData> queueDatas;
    private List<BrokerData> brokerDatas;
    private HashMap<String/* brokerAddr */, List<String>/* Filter Server */> filterServerTable;
 }
复制代码

发现没,其中包含的属性和如上图片类似。

queueDatasbrokerDatas,其中queueDatas包含消息队列的基本情况,读/写的最大数目,brokerDatas包含Broker的位置信息。

再看看本地的真正路由信息,如上对象是它的属性。

public class TopicPublishInfo {
    private boolean orderTopic = false;
    private boolean haveTopicRouterInfo = false;
    private List<MessageQueue> messageQueueList = new ArrayList<MessageQueue>();
    private volatile ThreadLocalIndex sendWhichQueue = new ThreadLocalIndex();
    private TopicRouteData topicRouteData;
 }
复制代码

这下很明白了。

第三项[Consumer Manage],看名字也知道啥意思,该Topic的消费管理。

第四项[Topic Config],修改Topic的属性,没啥作用,本来代码也可以控制。

第五项[Send Message],向该Topic发送消息。可以测试玩玩,将Consumer配置好,然后运行,不通过代码发送,在这里发送消息,Consumer也能接受到。

mark


mark

5.Consumer

mark

没太看懂这每一行代表啥意思。估计是一个Consumer对象。后面几个按钮点击后,可以看看该Consumer的具体配置信息,好像没啥东西。

6.Message

该模块很重要,信息量也很多。

mark

比较容易理解,根据如上三项对Message分组查询。一般第一项根据Topic查询比较多。因为据说根据key去查询有坑。建议idTopicid因为唯一最简单。

mark

这是该Topic下的所有消息,不管是否消费都在内。

Message ID 、Tag 、Key都是消息比较重要的属性。点击右方的按钮,可以看到该消息更加具体的情况。

mark

注意点都用箭头标出来了,其他可能比较容易理解,无非就那几个属性。最后的TrackType很重要,对于排查问题。该属性的值有好几个,现在看到的几个总结如下

  • CONSUMED 代表该消息已经被消费
  • NOT_CONSUME_YET 还没被消费
  • UNKNOW_EXCEPTION 报错了,可以看日志,一般报错内容会紧跟其后,具体很容易排查出来
  • NOT_ONLINE 代表该Consumer并没有运行

总共有如下几个

public enum TrackType {
    CONSUMED,
    CONSUMED_BUT_FILTERED,
    PULL,
    NOT_CONSUME_YET,
    NOT_ONLINE,
    UNKNOWN,
}
复制代码

ok!差不多总结完成,希望能帮到大家
原创不易,如果帮到你 请支持一波 老郭第一勺金

rocketMQ按key查询问题分析

rocketmq 控制台 NOT_CONSUME_YET

rocketMQ 消息查询(id,key) 运维命令以及java API的用法

0 回复
暂时没有回复,你也许会成为第一个哦