RocketMQ Promethus Exporter
介绍
Rocketmq-exporter 是用于监控 RocketMQ broker 端和客户端所有相关指标的系统,通过 mqAdmin 从 broker 端获取指标值后封装成 87 个 cache。
警告
过去版本曾是 87 个 concurrentHashMap,由于 Map 不会删除过期指标,所以一旦有 label 变动就会生成一个新的指标,旧的无用指标无法自动删除,久而久之造成内存溢出。而使用 Cache 结构可可以实现过期删除,且过期时间可配置。
Rocketmq-expoter 获取监控指标的流程如下图所示,Expoter 通过 MQAdminExt 向 MQ 集群请求数据,请求到的数据通过 MetricService 规范化成 Prometheus 需要的格式,然后通过 /metics 接口暴露给 Promethus。

Metric 结构
Metric 类位于 org.apache.rocketmq.expoter.model.metrics 包下,实质上是一些实体类,每个实体类代表一类指标, 总共 14 个 Metric 类。这些类作为 87 个 Cache 的 key, 用不同的 label 值进行区分。
实体类中包含了 LABEL 的三个维度:BROKER、CONSUMER、PRODUCER
-
broker 相关 metric 类有: BrokerRuntimeMetric、BrokerMetric、DLQTopicOffsetMetric、TopicPutNumMetric
-
消费者相关类有: ConsumerRuntimeConsumeFailedMsgsMetric 、ConsumerRuntimeConsumeFailedTPSMetric 、ConsumerRuntimeConsumeOKTPSMetric、ConsumerRuntimeConsumeRTMetric、ConsumerRuntimePullRTMetric、ConsumerRuntimePullTPSMetric、ConsumerCountMetric、ConsumerMetric、ConsumerTopicDiffMetric
-
生产者相关 metric 类有: ProducerMetric
Prometheus 拉取 metrics 的过程
RocketMQ-exporter 项目和 Prometheus 相当于服务器和客户端的关系,RocketMQ-exporter 项目引入了 Prometheus 的 client 包,该包中规定了需要获取的信息的类型即项目中的 MetricFamilySamples 类,Prometheus 向 expoter 请求 metrics,expoter 将信息封装成相应的类型之后返回给 Prometheus。
rocketmq-expoter 项目启动后,会获取 rocketmq 的各项 metrics 收集到 mfs 对象中,当浏览器或 Prometheus 访问相应的接口时,会通过 service 将 mfs 对象中的 samples 生成 Prometheus 所支持的格式化数据。主要包含以下步骤:
浏览器通过访问 ip:5557/metrics,会调用 RMQMetricsController 类下的 metrics 方法,其中 ip 为 rocketmq-expoter 项目运行的主机 ip
private void metrics(HttpServletResponse response) throws IOException {StringWriter writer = new StringWriter();metricsService.metrics(writer);response.setHeader("Content-Type", "text/plain; version=0.0.4; charset=utf-8");response.getOutputStream().print(writer.toString());
}
通过新建 StringWriter 对象用于收集 metrics 指标,调用 MetricsService 类中的方法 metrics 将 expoter 中提取到的指标收集到 writer 对象中,最后将收集到的指标输出到网页上。
收集到的指标格式为:
<metric name>{<label name>=<label value>, ...} <metric value>
如:
rocketmq_group_diff{group="rmq_group_test_20220114",topic="fusion_console_tst",countOfOnlineConsumers="0",msgModel="1",} 23.0
MetricCollectTask 类中的 5 个定时任务
MetricCollectTask 类中有 5 个定时任务,分别为 collectTopicOffset、collectConsumerOffset、collectBrokerStatsTopic、collectBrokerStats 和 collectBrokerRuntimeStats。用于收集消费位点信息以及 Broker 状态信息等。其 cron 表达式为:cron: 15 0/1 * * * ?,表示每分钟会收集一次。其核心功能是通过 mqAdminExt 对象从集群中获取 broker 中的信息,然后将其添加到对应的 87 个监控指标中,以 collectTopicOffset 为例:
- 首先初始化TopicList对象,通过mqAdminExt.fetchAllTopicList()方法获取到集群的所有topic信息。
TopicList topicList = null;try { topicList = mqAdminExt.fetchAllTopicList();
} catch (Exception ex) {log.error(String.format("collectTopicOffset-exception comes getting topic list from namesrv, address is %s",JSON.toJSONString(mqAdminExt.getNameServerAddressList())));return;}
- 将 topic 加入到 topicSet 中,循环遍历每一个 topic,通过 mqAdminExt.examineTopicStats(topic)函数来检查 topic 状态。
Set < String > topicSet = topicList != null ? topicList.getTopicList() : null;for (String topic: topicSet) {TopicStatsTable topicStats = null;try {topicStats = mqAdminExt.examineTopicStats(topic);} catch (Exception ex) {log.error(String.format("collectTopicOffset-getting topic(%s) stats error. the namesrv address is %s",topic,JSON.toJSONString(mqAdminExt.getNameServerAddressList())));continue;}
- 初始化 topic 状态 set,用于用于按 broker 划分的 topic 信息位点的 hash 表 brokerOffsetMap,以及一个用于按 broker 名字为 key 的用于存储更新时间戳的 hash 表 brokerUpdateTimestampMap。
Set<Map.Entry<MessageQueue, TopicOffset>> topicStatusEntries = topicStats.getOffsetTable().entrySet();HashMap<String, Long> brokerOffsetMap = new HashMap<>();HashMap<String, Long> brokerUpdateTimestampMap = new HashMap<>();for (Map.Entry<MessageQueue, TopicOffset> topicStatusEntry : topicStatusEntries) {MessageQueue q = topicStatusEntry.getKey();TopicOffset offset = topicStatusEntry.getValue();if (brokerOffsetMap.containsKey(q.getBrokerName())) {brokerOffsetMap.put(q.getBrokerName(), brokerOffsetMap.get(q.getBrokerName()) + offset.getMaxOffset());} else {brokerOffsetMap.put(q.getBrokerName(), offset.getMaxOffset());}if (brokerUpdateTimestampMap.containsKey(q.getBrokerName())) {if (offset.getLastUpdateTimestamp() > brokerUpdateTimestampMap.get(q.getBrokerName())) {brokerUpdateTimestampMap.put(q.getBrokerName(), offset.getLastUpdateTimestamp());}} else {brokerUpdateTimestampMap.put(q.getBrokerName(),offset.getLastUpdateTimestamp());}}
- 最后通过遍历 brokerOffsetMap 中的每一项,通过调用 metricsService 获取到 metricCollector 对象,调用 RMQMetricsCollector 类中的 addTopicOffsetMetric 方法,将相应的值添加到 RMQMetricsCollector 类中 87 个指标对应的其中一个指标的 cache 中。
Set<Map.Entry<String, Long>> brokerOffsetEntries = brokerOffsetMap.entrySet();for (Map.Entry<String, Long> brokerOffsetEntry : brokerOffsetEntries) {metricsService.getCollector().addTopicOffsetMetric(clusterName, brokerOffsetEntry.getKey(), topic,brokerUpdateTimestampMap.get(brokerOffsetEntry.getKey()), brokerOffsetEntry.getValue());}}log.info("topic offset collection task finished...." + (System.currentTimeMillis() - start));
}
Rocketmq-exporter 收集指标流程图

快速开始
配置 application.yml
application.yml 中重要的配置主要有:
-
server.port 设置 promethus 监听 rocketmq-exporter 的端口, 默认为 5557
-
rocketmq.config.webTelemetryPath 配置 promethus 获取指标的路径,默认为 /metrics ,使用默认值即可.
-
rocketmq.config.enableACL 如果 RocketMQ 集群开启了 ACL 验证,需要配置为 true, 并在 accessKey 和 secretKey 中配置相应的 ak, sk.
-
rocketmq.config.outOfTimeSeconds 用于配置存储指标和相应的值的过期时间,若超过该时间,cache 中的 key 对应的节点没有发生写更改,则会进行删除.一般配置为 60s 即可(根据 promethus 获取指标的时间间隔进行合理配置,只要保证过期时间大于等于 promethus 收集指标的时间间隔即可)
-
task..cron 配置 exporter 从 broker 拉取指标的定时任务的时间间隔,默认值为"15 0/1 * * ?" 每分钟的 15s 拉取一次指标.
启动 exporter 项目
按照 promethus 官网配置启动
配置 promethus 的 static_config: -targets 为 exporter 的启动 IP 和端口,如: localhost:5557
访问 promethus 页面
本地启动默认为: localhost:9090 ,则可对收集到的指标值进行查看,如下图所示:

提示
为了达到更好的可视化效果,观察指标值变化趋势, promethus 搭配 grafana 效果更佳哦!
可观测性指标
可观测性指标主要包括两个大类: 服务端指标和客户端指标, 服务端指标由服务端直接生成, 客户端指标在客户端产生, 由服务端通过 rpc 请求客户端获取到. 客户端指标又可细分为生产端指标和消费端指标.所有 87 个可观测性指标及其主要含义如下:
服务端指标
服务端指标
| 指标名称 | 含义 | 对应Broker指标名 |
|---|---|---|
| rocketmq_broker_tps | Broker级别的生产TPS | |
| rocketmq_broker_qps | Broker级别的消费QPS | |
| rocketmq_broker_commitlog_diff | Broker组从节点同步落后消息size | |
| rocketmq_brokeruntime_pmdt_0ms | 服务端开始处理写请求到完成写入的耗时(0ms) | putMessageDistributeTime |
| rocketmq_brokeruntime_pmdt_0to10ms | 服务端开始处理写请求到完成写入的耗时(0~10ms) | |
| rocketmq_brokeruntime_pmdt_10to50ms | 服务端开始处理写请求到完成写入的耗时(10~50ms) | |
| rocketmq_brokeruntime_pmdt_50to100ms | 服务端开始处理写请求到完成写入的耗时(50~100ms) | |
| rocketmq_brokeruntime_pmdt_100to200ms | 服务端开始处理写请求到完成写入的耗时(100~200ms) | |
| rocketmq_brokeruntime_pmdt_200to500ms | 服务端开始处理写请求到完成写入的耗时(200~500ms) | |
| rocketmq_brokeruntime_pmdt_500to1s | 服务端开始处理写请求到完成写入的耗时(500~1000ms) | |
| rocketmq_brokeruntime_pmdt_1to2s | 服务端开始处理写请求到完成写入的耗时(1~2s) | |
| rocketmq_brokeruntime_pmdt_2to3s | 服务端开始处理写请求到完成写入的耗时(2~3s) | |
| rocketmq_brokeruntime_pmdt_3to4s | 服务端开始处理写请求到完成写入的耗时(3~4s) | |
| rocketmq_brokeruntime_pmdt_4to5s | 服务端开始处理写请求到完成写入的耗时(4~5s) | |
| rocketmq_brokeruntime_pmdt_5to10s | 服务端开始处理写请求到完成写入的耗时(5~10s) | |
| rocketmq_brokeruntime_pmdt_10stomore | 服务端开始处理写请求到完成写入的耗时(> 10s) | |
| rocketmq_brokeruntime_dispatch_behind_bytes | 到现在为止,未被分发(构建索引之类的操作)的消息bytes | dispatchBehindBytes |
| rocketmq_brokeruntime_put_message_size_total | broker写入消息size的总和 | putMessageSizeTotal |
| rocketmq_brokeruntime_put_message_average_size | broker写入消息的平均大小 | putMessageAverageSize |
| rocketmq_brokeruntime_remain_transientstore_buffer_numbs | TransientStorePool 中队列的容量 | remainTransientStoreBufferNumbs |
| rocketmq_brokeruntime_earliest_message_timestamp | broker存储的消息最早的时间戳 | earliestMessageTimeStamp |
| rocketmq_brokeruntime_putmessage_entire_time_max | broker自运行以来,写入消息耗时的最大值 | putMessageEntireTimeMax |
| rocketmq_brokeruntime_start_accept_sendrequest_time | 开始接受发送请求的时间 | startAcceptSendRequestTimeStamp |
| rocketmq_brokeruntime_putmessage_times_total | broker写入消息的总次数 | putMessageTimesTotal |
| rocketmq_brokeruntime_getmessage_entire_time_max | broker自启动以来,处理消息拉取的最大耗时 | getMessageEntireTimeMax |
| rocketmq_brokeruntime_pagecache_lock_time_mills | pageCacheLockTimeMills | |
| rocketmq_brokeruntime_commitlog_disk_ratio | commitLog所在磁盘的使用比例 | commitLogDiskRatio |
| rocketmq_brokeruntime_dispatch_maxbuffer | broker没有计算,一直为0 | dispatchMaxBuffer |
| rocketmq_brokeruntime_pull_threadpoolqueue_capacity | 处理拉取请求线程池队列的容量 | pullThreadPoolQueueCapacity |
| rocketmq_brokeruntime_send_threadpoolqueue_capacity | 处理发送请求线程池队列的容量 | sendThreadPoolQueueCapacity |
| rocketmq_brokeruntime_query_threadpool_queue_capacity | 处理查询请求线程池队列的容量 | queryThreadPoolQueueCapacity |
| rocketmq_brokeruntime_pull_threadpoolqueue_size | 处理拉取请求线程池队列的实际size | pullThreadPoolQueueSize |
| rocketmq_brokeruntime_query_threadpoolqueue_size | 处理查询请求线程池队列的实际size | queryThreadPoolQueueSize |
| rocketmq_brokeruntime_send_threadpool_queue_size | 处理send请求线程池队列的实际size | sendThreadPoolQueueSize |
| rocketmq_brokeruntime_pull_threadpoolqueue_headwait_timemills | 处理拉取请求线程池队列的队头任务等待时间 | pullThreadPoolQueueHeadWaitTimeMills |
| rocketmq_brokeruntime_query_threadpoolqueue_headwait_timemills | 处理查询请求线程池队列的队头任务等待时间 | queryThreadPoolQueueHeadWaitTimeMills |
| rocketmq_brokeruntime_send_threadpoolqueue_headwait_timemills | 处理发送请求线程池队列的队头任务等待时间 | sendThreadPoolQueueHeadWaitTimeMills |
| rocketmq_brokeruntime_msg_gettotal_yesterdaymorning | 到昨晚12点为止,读取消息的总次数 | msgGetTotalYesterdayMorning |
| rocketmq_brokeruntime_msg_puttotal_yesterdaymorning | 到昨晚12点为止,写入消息的总次数 | msgPutTotalYesterdayMorning |
| rocketmq_brokeruntime_msg_gettotal_todaymorning | 到今晚12点为止,读取消息的总次数 | msgGetTotalTodayMorning |
| rocketmq_brokeruntime_msg_puttotal_todaymorning | 到昨晚12点为止,写入消息的总次数 | putMessageTimesTotal |
| rocketmq_brokeruntime_msg_put_total_today_now | 每个broker到现在为止,写入的消息次数 | msgPutTotalTodayNow |
| rocketmq_brokeruntime_msg_gettotal_today_now | 每个broker到现在为止,读取的消息次数 | msgGetTotalTodayNow |
| rocketmq_brokeruntime_commitlogdir_capacity_free | commitLog所在目录的可用空间 | commitLogDirCapacity |
| rocketmq_brokeruntime_commitlogdir_capacity_total | commitLog所在目录的总空间 | |
| rocketmq_brokeruntime_commitlog_maxoffset | commitLog的最大offset | commitLogMaxOffset |
| rocketmq_brokeruntime_commitlog_minoffset | commitLog的最小offset | commitLogMinOffset |
| rocketmq_brokeruntime_remain_howmanydata_toflush | remainHowManyDataToFlush | |
| rocketmq_brokeruntime_getfound_tps600 | 600s内getMessage时get到消息的平均TPS | getFoundTps |
| rocketmq_brokeruntime_getfound_tps60 | 60s内getMessage时get到消息的平均TPS | |
| rocketmq_brokeruntime_getfound_tps10 | 10s内getMessage时get到消息的平均TPS | |
| rocketmq_brokeruntime_gettotal_tps600 | 600s内getMessage次数的平均TPS | getTotalTps |
| rocketmq_brokeruntime_gettotal_tps60 | 60s内getMessage次数的平均TPS | |
| rocketmq_brokeruntime_gettotal_tps10 | 10s内getMessage次数的平均TPS | |
| rocketmq_brokeruntime_gettransfered_tps600 | getTransferedTps | |
| rocketmq_brokeruntime_gettransfered_tps60 | ||
| rocketmq_brokeruntime_gettransfered_tps10 | ||
| rocketmq_brokeruntime_getmiss_tps600 | 600s内getMessage时没有get到消息的平均TPS | getMissTps |
| rocketmq_brokeruntime_getmiss_tps60 | 60s内getMessage时没有get到消息的平均TPS | |
| rocketmq_brokeruntime_getmiss_tps10 | 10s内getMessage时没有get到消息的平均TPS | |
| rocketmq_brokeruntime_put_tps600 | 600s内写入消息次数的平均TPS | putTps |
| rocketmq_brokeruntime_put_tps60 | 60s内写入消息次数的平均TPS | |
| rocketmq_brokeruntime_put_tps10 | 10s内写入消息次数的平均TPS |
生产端指标
生产端指标
| 指标名称 | 含义 |
|---|---|
| rocketmq_producer_offset | topic当前时间的最大offset |
| rocketmq_topic_retry_offset | 重试Topic当前时间的最大offset |
| rocketmq_topic_dlq_offset | 死信Topic当前时间的最大offset |
| rocketmq_producer_tps | Topic在一个Broker组上的生产TPS |
| rocketmq_producer_message_size | Topic在一个Broker组上的生产消息大小的TPS |
| rocketmq_queue_producer_tps | 队列级别生产TPS |
| rocketmq_queue_producer_message_size | 队列级别生产消息大小的TPS |
消费端指标### 消费端指标
| 指标名称 | 含义 |
|---|---|
| rocketmq_group_diff | 消费组消息堆积消息数 |
| rocketmq_group_retrydiff | 消费组重试队列堆积消息数 |
| rocketmq_group_dlqdiff | 消费组死信队列堆积消息数 |
| rocketmq_group_count | 消费组内消费者个数 |
| rocketmq_client_consume_fail_msg_count | 过去1h消费者消费失败的次数 |
| rocketmq_client_consume_fail_msg_tps | 消费者消费失败的TPS |
| rocketmq_client_consume_ok_msg_tps | 消费者消费成功的TPS |
| rocketmq_client_consume_rt | 消息从拉取到被消费的时间 |
| rocketmq_client_consumer_pull_rt | 客户端拉取消息的时间 |
| rocketmq_client_consumer_pull_tps | 客户端拉取消息的TPS |
| rocketmq_consumer_tps | 每个Broker组上订阅组的消费TPS |
| rocketmq_group_consume_tps | 订阅组当前消费TPS(对rocketmq_consumer_tps按broker聚合) |
| rocketmq_consumer_offset | 订阅组在一个broker组上当前的消费Offset |
| rocketmq_group_consume_total_offset | 订阅组当前消费的Offset(对rocketmq_consumer_offset按broker聚合) |
| rocketmq_consumer_message_size | 订阅组在一个broker组上消费消息大小的TPS |
| rocketmq_send_back_nums | 订阅组在一个broker组上消费失败,写入重试消息的次数 |
| rocketmq_group_get_latency_by_storetime | 消费组消费延时,exporter get到消息后与当前时间相减 |
| 指标名称 | 含义 | 对应Broker指标名 |
|---|---|---|
| rocketmq_broker_tps | Broker级别的生产TPS | |
| rocketmq_broker_qps | Broker级别的消费QPS | |
| rocketmq_broker_commitlog_diff | Broker组从节点同步落后消息size | |
| rocketmq_brokeruntime_pmdt_0ms | 服务端开始处理写请求到完成写入的耗时(0ms) | putMessageDistributeTime |
| rocketmq_brokeruntime_pmdt_0to10ms | 服务端开始处理写请求到完成写入的耗时(0~10ms) | |
| rocketmq_brokeruntime_pmdt_10to50ms | 服务端开始处理写请求到完成写入的耗时(10~50ms) | |
| rocketmq_brokeruntime_pmdt_50to100ms | 服务端开始处理写请求到完成写入的耗时(50~100ms) | |
| rocketmq_brokeruntime_pmdt_100to200ms | 服务端开始处理写请求到完成写入的耗时(100~200ms) | |
| rocketmq_brokeruntime_pmdt_200to500ms | 服务端开始处理写请求到完成写入的耗时(200~500ms) | |
| rocketmq_brokeruntime_pmdt_500to1s | 服务端开始处理写请求到完成写入的耗时(500~1000ms) | |
| rocketmq_brokeruntime_pmdt_1to2s | 服务端开始处理写请求到完成写入的耗时(1~2s) | |
| rocketmq_brokeruntime_pmdt_2to3s | 服务端开始处理写请求到完成写入的耗时(2~3s) | |
| rocketmq_brokeruntime_pmdt_3to4s | 服务端开始处理写请求到完成写入的耗时(3~4s) | |
| rocketmq_brokeruntime_pmdt_4to5s | 服务端开始处理写请求到完成写入的耗时(4~5s) | |
| rocketmq_brokeruntime_pmdt_5to10s | 服务端开始处理写请求到完成写入的耗时(5~10s) | |
| rocketmq_brokeruntime_pmdt_10stomore | 服务端开始处理写请求到完成写入的耗时(> 10s) | |
| rocketmq_brokeruntime_dispatch_behind_bytes | 到现在为止,未被分发(构建索引之类的操作)的消息bytes | dispatchBehindBytes |
| rocketmq_brokeruntime_put_message_size_total | broker写入消息size的总和 | putMessageSizeTotal |
| rocketmq_brokeruntime_put_message_average_size | broker写入消息的平均大小 | putMessageAverageSize |
| rocketmq_brokeruntime_remain_transientstore_buffer_numbs | TransientStorePool 中队列的容量 | remainTransientStoreBufferNumbs |
| rocketmq_brokeruntime_earliest_message_timestamp | broker存储的消息最早的时间戳 | earliestMessageTimeStamp |
| rocketmq_brokeruntime_putmessage_entire_time_max | broker自运行以来,写入消息耗时的最大值 | putMessageEntireTimeMax |
| rocketmq_brokeruntime_start_accept_sendrequest_time | 开始接受发送请求的时间 | startAcceptSendRequestTimeStamp |
| rocketmq_brokeruntime_putmessage_times_total | broker写入消息的总次数 | putMessageTimesTotal |
| rocketmq_brokeruntime_getmessage_entire_time_max | broker自启动以来,处理消息拉取的最大耗时 | getMessageEntireTimeMax |
| rocketmq_brokeruntime_pagecache_lock_time_mills | pageCacheLockTimeMills | |
| rocketmq_brokeruntime_commitlog_disk_ratio | commitLog所在磁盘的使用比例 | commitLogDiskRatio |
| rocketmq_brokeruntime_dispatch_maxbuffer | broker没有计算,一直为0 | dispatchMaxBuffer |
| rocketmq_brokeruntime_pull_threadpoolqueue_capacity | 处理拉取请求线程池队列的容量 | pullThreadPoolQueueCapacity |
| rocketmq_brokeruntime_send_threadpoolqueue_capacity | 处理发送请求线程池队列的容量 | sendThreadPoolQueueCapacity |
| rocketmq_brokeruntime_query_threadpool_queue_capacity | 处理查询请求线程池队列的容量 | queryThreadPoolQueueCapacity |
| rocketmq_brokeruntime_pull_threadpoolqueue_size | 处理拉取请求线程池队列的实际size | pullThreadPoolQueueSize |
| rocketmq_brokeruntime_query_threadpoolqueue_size | 处理查询请求线程池队列的实际size | queryThreadPoolQueueSize |
| rocketmq_brokeruntime_send_threadpool_queue_size | 处理send请求线程池队列的实际size | sendThreadPoolQueueSize |
| rocketmq_brokeruntime_pull_threadpoolqueue_headwait_timemills | 处理拉取请求线程池队列的队头任务等待时间 | pullThreadPoolQueueHeadWaitTimeMills |
| rocketmq_brokeruntime_query_threadpoolqueue_headwait_timemills | 处理查询请求线程池队列的队头任务等待时间 | queryThreadPoolQueueHeadWaitTimeMills |
| rocketmq_brokeruntime_send_threadpoolqueue_headwait_timemills | 处理发送请求线程池队列的队头任务等待时间 | sendThreadPoolQueueHeadWaitTimeMills |
| rocketmq_brokeruntime_msg_gettotal_yesterdaymorning | 到昨晚12点为止,读取消息的总次数 | msgGetTotalYesterdayMorning |
| rocketmq_brokeruntime_msg_puttotal_yesterdaymorning | 到昨晚12点为止,写入消息的总次数 | msgPutTotalYesterdayMorning |
| rocketmq_brokeruntime_msg_gettotal_todaymorning | 到今晚12点为止,读取消息的总次数 | msgGetTotalTodayMorning |
| rocketmq_brokeruntime_msg_puttotal_todaymorning | 到昨晚12点为止,写入消息的总次数 | putMessageTimesTotal |
| rocketmq_brokeruntime_msg_put_total_today_now | 每个broker到现在为止,写入的消息次数 | msgPutTotalTodayNow |
| rocketmq_brokeruntime_msg_gettotal_today_now | 每个broker到现在为止,读取的消息次数 | msgGetTotalTodayNow |
| rocketmq_brokeruntime_commitlogdir_capacity_free | commitLog所在目录的可用空间 | commitLogDirCapacity |
| rocketmq_brokeruntime_commitlogdir_capacity_total | commitLog所在目录的总空间 | |
| rocketmq_brokeruntime_commitlog_maxoffset | commitLog的最大offset | commitLogMaxOffset |
| rocketmq_brokeruntime_commitlog_minoffset | commitLog的最小offset | commitLogMinOffset |
| rocketmq_brokeruntime_remain_howmanydata_toflush | remainHowManyDataToFlush | |
| rocketmq_brokeruntime_getfound_tps600 | 600s内getMessage时get到消息的平均TPS | getFoundTps |
| rocketmq_brokeruntime_getfound_tps60 | 60s内getMessage时get到消息的平均TPS | |
| rocketmq_brokeruntime_getfound_tps10 | 10s内getMessage时get到消息的平均TPS | |
| rocketmq_brokeruntime_gettotal_tps600 | 600s内getMessage次数的平均TPS | getTotalTps |
| rocketmq_brokeruntime_gettotal_tps60 | 60s内getMessage次数的平均TPS | |
| rocketmq_brokeruntime_gettotal_tps10 | 10s内getMessage次数的平均TPS | |
| rocketmq_brokeruntime_gettransfered_tps600 | getTransferedTps | |
| rocketmq_brokeruntime_gettransfered_tps60 | ||
| rocketmq_brokeruntime_gettransfered_tps10 | ||
| rocketmq_brokeruntime_getmiss_tps600 | 600s内getMessage时没有get到消息的平均TPS | getMissTps |
| rocketmq_brokeruntime_getmiss_tps60 | 60s内getMessage时没有get到消息的平均TPS | |
| rocketmq_brokeruntime_getmiss_tps10 | 10s内getMessage时没有get到消息的平均TPS | |
| rocketmq_brokeruntime_put_tps600 | 600s内写入消息次数的平均TPS | putTps |
| rocketmq_brokeruntime_put_tps60 | 60s内写入消息次数的平均TPS | |
| rocketmq_brokeruntime_put_tps10 | 10s内写入消息次数的平均TPS |
相关文章:
RocketMQ Promethus Exporter
介绍 Rocketmq-exporter 是用于监控 RocketMQ broker 端和客户端所有相关指标的系统,通过 mqAdmin 从 broker 端获取指标值后封装成 87 个 cache。 警告 过去版本曾是 87 个 concurrentHashMap,由于 Map 不会删除过期指标,所以一旦有 la…...
Kafka收发消息核心参数详解
文章目录 1、从基础的客户端说起1.1、消息发送者主流程1.2、消息消费者主流程 2、从客户端属性来梳理客户端工作机制2.1、消费者分组消费机制 1、从基础的客户端说起 Kafka提供了非常简单的客户端API。只需要引入一个Maven依赖即可: <dependency><groupId…...
Springboot中Aop的使用
Springboot中使用拦截器、过滤器、监听器-CSDN博客 相比较于拦截器,Spring 的aop则功能更强大,封装的更细致,需要单独引用 jar包。 <dependency><groupId>org.springframework.boot</groupId><artifactId>spring-b…...
创建vue3项目、链式调用、setup函数、ref函数、reactive函数、计算和监听属性、vue3的生命周期、torefs的使用、vue3的setup写法
1 创建vue3项目 # 两种方式- vue-cli:vue脚手架---》创建vue项目---》构建vue项目--》工具链跟之前一样- vite :https://cn.vitejs.dev/-npm create vuelatest // 或者-npm create vitelatest一路选择即可# 运行vue3项目-vue-cli跟之前一样-vite 创建的…...
搭建好自己的PyPi服务器后怎么使用
当您成功搭建好自己的 PyPI 服务器后,您可以使用以下步骤来发布和使用您的包: 打包您的代码: 首先,将您的 Python 项目打包成一个发布包。确保您已经在项目根目录下创建了 setup.py 文件,并按照正确的格式填写了项目信…...
Vue3 中使用provide和reject
1、provide 和reject 可以实现一条事件线上的 父传子,父传孙等;相比较 props emits 仅限与父子传参更方便,相较于pinia书写更简单,但是需要注意使用响应式,如果是非响应式的会导致页面更新不及时 父组件 <templat…...
大数据flink篇之一-基础知识
一、起源 2010至2014年间,由柏林工业大学、柏林洪堡大学和哈索普拉特纳研究所联合发起名Stratosphere的研究项目。2014年4月,项目贡献给Apache基金会,成为孵化项目。更名为Flink2014年12月,成为基金会顶级项目2015年9月ÿ…...
No140.精选前端面试题,享受每天的挑战和学习
🤍 前端开发工程师(主业)、技术博主(副业)、已过CET6 🍨 阿珊和她的猫_CSDN个人主页 🕠 牛客高级专题作者、在牛客打造高质量专栏《前端面试必备》 🍚 蓝桥云课签约作者、已在蓝桥云课上架的前后端实战课程《Vue.js 和 Egg.js 开发企业级健康管理项目》、《带你从入…...
Oracle 11g_FusionOS_安装文档
同事让安装数据库,查询服务器信息发现操作系统是超聚变根据华为openEuler操作系统更改的自研操作系统,安装过程中踩坑不少,最后在超聚变厂商的技术支持下安装成功,步骤可参数该文。 一、 安装环境准备 1.1 软件下载 下载地址:…...
Linux驱动实现IO模型
在Linux系统分为内核态和用户态,CPU会在这两个状态之间进行切换。当进行IO操作时,应用程序会使用系统调用进入内核态,内核操作系统会准备好数据,把IO设备的数据加载到内核缓冲区。 然后内核操作系统会把内核缓冲区的数据从内核空…...
wsl2 更新报错问题解决记录
1、问题 win10 中安装的 wsl2,启动 docker desktop 时提示 wsl2 有问题: 于是点击推荐的地址连接到微软,下载 wsl2 的更新文件。之后运行,又报错: 更新被卡住。 2、解决方法 WinR 输入 cmd 打开命令行窗口&#x…...
突破算法迷宫:精选50道-算法刷题指南
前言 在计算机科学和编程领域,算法和数据结构是基础的概念,无论你是一名初学者还是有经验的开发者,都需要掌握它们。本文将带你深入了解一系列常见的算法和数据结构问题,包括二分查找、滑动窗口、链表、二叉树、TopK、设计题、动…...
玩转Mysql系列 - 第26篇:聊聊mysql如何实现分布式锁?
这是Mysql系列第26篇。 本篇我们使用mysql实现一个分布式锁。 分布式锁的功能 分布式锁使用者位于不同的机器中,锁获取成功之后,才可以对共享资源进行操作 锁具有重入的功能:即一个使用者可以多次获取某个锁 获取锁有超时的功能ÿ…...
linux 解压缩命令tar
Tar tar 命令的选项有很多(用 man tar 可以查看到),但常用的就那么几个选项,下面来举例说明一下: tar -cf all.tar *.jpg 这条命令是将所有.jpg 的文件打成一个名为 all.tar 的包。-c 是表示产生新的包,-f 指 定包的文件名。 …...
OpenAI ChatGPT API 文档之 Embedding
译者注: Embedding 直接翻译为嵌入似乎不太恰当,于是问了一下 ChatGPT,它的回复如下: 在自然语言处理和机器学习领域,"embeddings" 是指将单词、短语或文本转换成连续向量空间的过程。这个向量空间通常被称…...
Java常用类(二)
好久不见,因工作原因,好久没发文了,OldWang 回来了,持续更新Java内容!⭐ 不可变和可变字符序列使用陷阱⭐ 时间处理相关类⭐ Date 时间类(java.util.Date)⭐ DateFormat 类和 SimpleDateFormat 类⭐ Calendar 日历类 ⭐…...
Java获取给定月份的前N个月份和前N个季度
描述: 在项目开发过程中,遇到这样一个需求,即:给定某一月份,得到该月份前面的几个月份以及前面的几个季度。例如:给定2023-09,获取该月份前面的前3个月,即2023-08、2023-07、2023-0…...
网页资源加载过程
网页资源加载是指在浏览器中访问一个网页时,浏览器如何获取和显示网页内容的过程。这个过程通常分为以下几个步骤: DNS 解析: 当用户在浏览器中输入一个网址(例如,https://www.example.com),浏览…...
使用git config --global设置用户名和邮件,以及git config的全局和局部配置
文章目录 1. 文章引言2. 全局配置2.1 命令方式2.2 配置文件方式 3. 局部配置3.1 命令方式3.2 配置文件方式 4. 总结 1. 文章引言 我们为什么要设置设置用户名和邮件? 我们在注册github,gitlab等时,一般使用用户名或邮箱: 这个用户…...
【C语言】21-指针-3
目录 1. 指针数组1.1 什么是指针数组1.2 如何定义指针数组1.3 如何使用指针数组2. 多重指针2.1 二重指针的定义2.2 二重指针的初始化与赋值2.3 二重指针的使用3. 指针常量、常量指针、指向常量的常指针3.1 概念3.2 const pointer3.3 pointer to a constant3.3.1 (pointer to a …...
C++初阶-list的底层
目录 1.std::list实现的所有代码 2.list的简单介绍 2.1实现list的类 2.2_list_iterator的实现 2.2.1_list_iterator实现的原因和好处 2.2.2_list_iterator实现 2.3_list_node的实现 2.3.1. 避免递归的模板依赖 2.3.2. 内存布局一致性 2.3.3. 类型安全的替代方案 2.3.…...
理解 MCP 工作流:使用 Ollama 和 LangChain 构建本地 MCP 客户端
🌟 什么是 MCP? 模型控制协议 (MCP) 是一种创新的协议,旨在无缝连接 AI 模型与应用程序。 MCP 是一个开源协议,它标准化了我们的 LLM 应用程序连接所需工具和数据源并与之协作的方式。 可以把它想象成你的 AI 模型 和想要使用它…...
MySQL 8.0 OCP 英文题库解析(十三)
Oracle 为庆祝 MySQL 30 周年,截止到 2025.07.31 之前。所有人均可以免费考取原价245美元的MySQL OCP 认证。 从今天开始,将英文题库免费公布出来,并进行解析,帮助大家在一个月之内轻松通过OCP认证。 本期公布试题111~120 试题1…...
select、poll、epoll 与 Reactor 模式
在高并发网络编程领域,高效处理大量连接和 I/O 事件是系统性能的关键。select、poll、epoll 作为 I/O 多路复用技术的代表,以及基于它们实现的 Reactor 模式,为开发者提供了强大的工具。本文将深入探讨这些技术的底层原理、优缺点。 一、I…...
Android 之 kotlin 语言学习笔记三(Kotlin-Java 互操作)
参考官方文档:https://developer.android.google.cn/kotlin/interop?hlzh-cn 一、Java(供 Kotlin 使用) 1、不得使用硬关键字 不要使用 Kotlin 的任何硬关键字作为方法的名称 或字段。允许使用 Kotlin 的软关键字、修饰符关键字和特殊标识…...
Xen Server服务器释放磁盘空间
disk.sh #!/bin/bashcd /run/sr-mount/e54f0646-ae11-0457-b64f-eba4673b824c # 全部虚拟机物理磁盘文件存储 a$(ls -l | awk {print $NF} | cut -d. -f1) # 使用中的虚拟机物理磁盘文件 b$(xe vm-disk-list --multiple | grep uuid | awk {print $NF})printf "%s\n"…...
【7色560页】职场可视化逻辑图高级数据分析PPT模版
7种色调职场工作汇报PPT,橙蓝、黑红、红蓝、蓝橙灰、浅蓝、浅绿、深蓝七种色调模版 【7色560页】职场可视化逻辑图高级数据分析PPT模版:职场可视化逻辑图分析PPT模版https://pan.quark.cn/s/78aeabbd92d1...
A2A JS SDK 完整教程:快速入门指南
目录 什么是 A2A JS SDK?A2A JS 安装与设置A2A JS 核心概念创建你的第一个 A2A JS 代理A2A JS 服务端开发A2A JS 客户端使用A2A JS 高级特性A2A JS 最佳实践A2A JS 故障排除 什么是 A2A JS SDK? A2A JS SDK 是一个专为 JavaScript/TypeScript 开发者设计的强大库ÿ…...
快刀集(1): 一刀斩断视频片头广告
一刀流:用一个简单脚本,秒杀视频片头广告,还你清爽观影体验。 1. 引子 作为一个爱生活、爱学习、爱收藏高清资源的老码农,平时写代码之余看看电影、补补片,是再正常不过的事。 电影嘛,要沉浸,…...
打手机检测算法AI智能分析网关V4守护公共/工业/医疗等多场景安全应用
一、方案背景 在现代生产与生活场景中,如工厂高危作业区、医院手术室、公共场景等,人员违规打手机的行为潜藏着巨大风险。传统依靠人工巡查的监管方式,存在效率低、覆盖面不足、判断主观性强等问题,难以满足对人员打手机行为精…...
