Cluster 界面的Today Produce Count、 Today Consume Count数量不对？

[sdoqwer1poiu]

场景一（单机）： 第一步：打开Cluster界面 第二步：假如此时向单机发送12条消息，Today Produce Count与Today Consume Count都是12，此时是正确的。（下面这张图片不一致时因为我执行了场景一的步骤，可以往下看为什么回这样） 第三步：如果此时我去Message界面搜索一下消息是否发送成功，或查看消息长什么样子 第四步：我再切换到Cluster界面（没变的话点一下刷新），就可以看见Today Consume Count数量噌噌噌变化，数量越多拜变化的越吓人，如果你再去Message界面多搜索几次消息。Cluster界面的这个值还会猛增。我觉得Message界面的搜索操作应该不得影响Cluster界面的Today Consume Count值吧？！。

场景二（集群：双主）（这个就不附图片了，文字描述）： 第一步：打开Cluster界面 第二步：假如此时向集群发送12条消息，按理说broker1和broker2的Today Produce Count加起来是12，结果broker1和broker2的Today Produce Count加起来是36。相当于我程序每生产一条消息，web界面却显示我生产3条，而且这三条是随机的，但是去Message界面查询却真的只有12条消息，只是Today Produce Count的数量不正确。（同理，去Message界面界面进行查询操作后，Cluster界面的Today Consume Count数量跟【场景一】相同，也会猛增）

这两个场景都会导致不想知道rockerMQ每天到底真实生成多少，消费多少消息。相当于Cluster界面完全就没起到一个统计作用

[sdoqwer1poiu]

希望大佬些尽管解决一下，谢谢了！如果需要场景2的浮现，我再复现一下，项目忙，只能紧急来提个issues

[lizhanhui]

看了下代码，这是个broker服务端统计问题。 broker侧在发送消息、消费消息的路径上做了内存metrics计数。查询消息也走了那个路径。

broker侧入口需要增加一个context，包含请求的来源， 让计数准确一下。

另外一点，这个计数都是内存态的，节点重启也会影响。

[wang-sheng-pu1002]

我也发现了这个问题，仪表板啥会更新呀！

[sdoqwer1poiu]

感觉不得更新了，都一年多了

[mubaili126]

我的更离谱，这个数据增加太快了 也不知道是统计出错，还是rocketmq 本身被触发了什么BUG