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 …...
解决craco启动react项目卡死在Starting the development server的问题
现象: 原因:craco.config.ts配置文件有问题 经过排查发现Dev开发模式下不能有splitChunk的配置, 解决办法: 加一个生产模式的判断,开发模式不加载splitChunk的配置,仅在生产模式才加载 判断条件代码&#…...
常见的密码学算法都有哪些?
密码学算法是用于保护信息安全的数学方法和技术。它们可以分为多个类别,包括对称加密、非对称加密、哈希函数和数字签名等。以下是一些常见的密码学算法: 1、对称加密算法: AES(高级加密标准):一种广泛使…...
云安全【阿里云ECS攻防】
关于VPC的概念还请看:记录一下弹性计算云服务的一些词汇概念 - 火线 Zone-安全攻防社区 一、初始化访问 1、元数据 1.1、SSRF导致读取元数据 如果管理员给ECS配置了RAM角色,那么就可以获得临时凭证 如果配置RAM角色 在获取ram临时凭证的时候ÿ…...
TBSS数据分析
tbss分析基本流程: 步骤一,指标解算:求解出FA,MD,AD,RD指标 #!/bin/bash #基于体素的形态学分析VBA path/media/kui/Passport5T/DATA_help/TBSS/row_data mkdir ${path}/Results_DTI_tbss mkdir ${path}/R…...
【单调队列】 239. 滑动窗口最大值
239. 滑动窗口最大值 解题思路 计算每一个滑动窗口的最大值 关键在于借助单调队列实现窗口对于单调队列 尾部添加元素 头部删除元素添加元素操作:从尾部开始循环对比 删除比当前元素小的元素获取最大值元素 直接获取头部元素删除元素操作 直接删除头部元素 class…...
Spring实例化源码解析之ComponentScanAnnotationParser(四)
上一章我们分析了ConfigurationClassParser,配置类的解析源码分析。在ComponentScans和ComponentScan注解修饰的候选配置类的解析过程中,我们需要深入的了解一下ComponentScanAnnotationParser的parse执行流程,SpringBoot启动类为什么这么写&…...
MySQL - 外键(foreign key)约束的作用和使用
什么是外键约束? 外键:用来让两张表的数据之间建立连接,从而保证数据的一致性和完整性。 外键约束是用于建立两个表之间关系的一种约束,它定义了一个表中的列与另一个表中的列之间的关系。外键约束可以保证数据的完整性和一致性…...
前端开发之服务器的基本概念与初识Ajax
1,服务器的基本概念与初识Ajax 1.1 URL地址的组成部分 1.2 客户端与服务器的通信过程 1.3 网页中如何请求数据 1.4 $.get()函数 1.4.1 $.get()函数的语法 // jQuery 中 $.get() 函数的功能单一,专门用来发起 get 请求,从而将服务器上的资源…...
数据结构排序算法---八大排序复杂度及代码实现
文章目录 一、冒泡排序代码实现 二、直接插入排序代码实现 三、希尔排序代码实现 四、选择排序代码实现 五、堆排序代码实现 六、快速排序代码实现 七、归并排序代码实现 八、计数排序代码实现 稳定性:相同的数据排序后,相对位置是否发生改变 一、冒泡排…...
GMS之Launcher中去除默认Search或替换为Chrome Search
将Launcher中搜索框去除 将FeatureFlags.java文件中的QSB_ON_FIRST_SCREEN变量修改为false \system\vendor\mediatek\proprietary\packages\apps\Launcher3\src\com\android\launcher3\config\FeatureFlags.java/*** Defines a set of flags used to control various launche…...
网站开发怎么挣钱/网络营销收获与体会
1、两张表关联用的三种连接: left join 、right join 、inner join区别 (备注:两个表链接肯定是根据两个表(如A B)中的两个字段值(如A.bId和B.id),相等就行连接) left join就是只要…...
金华网站建设明细报价表/新网站友链
http://www.cnjm.net/tech/article2049.html 本文版权归原作者,中国JAVA手机网收录本文的目的是让更多人阅读到此文章。转载请注明出处为中国JAVA手机网<www.cnjm.net> 来自:http://www.cnjm.net/tech/article2049.html 由于无线设备所能支持的网络协议非常有…...
三原网站开发/产品推广的渠道有哪些
作者:老人羽海https://segmentfault.com/a/1190000022680541#item-4电商小程序中,用到瀑布流的地方非常多,每次都写一个瀑布流,重复一次逻辑,作为程序员,肯定是非常不愿意的。瀑布流的形式都是大同小异&…...
有中文网站 怎么做英文网站/百度推广话术全流程
1、项目的典型用户与场景 2、对其他组评价 强强联手队项目做得很好,不过如果能够把连网操作就更好了。 滑稽队项目的前台设计挺好,如果把包车的信息都放进数据库就更好了。 梦之翼队的项目做得不错,可以看出他们做得非常的认真,但…...
扶风做网站/无锡整站百度快照优化
故障原因 本来做一个服务器分页的功能,结果按照文档配置好了一直都请求不到数据,而且用ajax完全没问题,那就查呗,network一查,初看没啥问题 method:post, 发送的数据 后来和ajax反复比较发现了 Request Payload这…...
商城网站建站方案/石家庄新闻网头条新闻
一、调试前提 1. Hardware 720p的DSI接口屏hx8394d,MIPI接口相关原理图如下图 通过原理图获取的信息: 1)2.8V VDD供电脚 —— LDO17; 2)1.8V VDD供电脚 —— LDO6; 3)RESET脚 —— GPIO25; 4)TE脚(一般DSI CMD模式下才会使用)—— GPIO24; 5)背光使能脚 —— G…...