作者：玄珏

从音讯的生命周期看可观测才能

在进入主题之前先来看一下 RocketMQ 生产者、顾客和服务端交互的流程：

message produce and consume process

RocketMQ 的音讯是依照行列的方式分区有序储存的，这种行列模型使得生产者、顾客和读写行列都是多对多的映射关系，彼此之间能够无限水平扩展。比照传统的音讯行列如 RabbitMQ 是很大的优势，尤其是在流式处理场景下能够确保同一行列的音讯被相同的顾客处理，关于批量处理、聚合处理更友爱。

接下来咱们来看一下音讯的整个生命周期中需求重视的重要节点：

message life cycle

首先是音讯发送：发送耗时是指一条音讯从生产者开端发送到服务端接收到并储存在硬盘上的时刻。假如是守时音讯，需求到达指定的守时时刻才能被顾客可见。

服务端收到音讯后需求依据音讯类型进行处理，关于守时/事务音讯只要到了守时时刻/事务提交才对顾客可见。RocketMQ 供给了音讯堆积的特性，即音讯发送到服务端后并不一定立即被拉取，能够依照客户端的消费才能进行投递。

从顾客的角度上看，有三个需求重视的阶段：

• 拉取音讯：音讯从开端拉取到抵达客户端的网络和服务端处理耗时；
• 音讯排队：等候处理资源，即从音讯抵达客户端到开端处理音讯；
• 音讯消费：从开端处理音讯到最终提交位点/返回 ACK。

音讯在生命周期的任何一个阶段，都能够清晰地被定义并且被观测到，这便是 RocketMQ 可观测的核心理念。而本文要介绍的 Metrics 就践行了这种理念，供给掩盖音讯生命周期各个阶段的监控埋点。借助 Metrics 供给的原子才能咱们能够建立合适事务需求的监控系统：

• 日常巡检与监控预警；
• 微观趋势/集群容量剖析；
• 毛病问题确诊。

RocketMQ 4.x Metrics 完成 – Exporter

RocketMQ 团队奉献的 RocketMQ exporter 已被 Prometheus 官方的开源 Exporter 生态所录入，供给了 Broker、Producer、Consumer 各个阶段丰厚的监控目标。

exporter metrics spec

Exporter 原理解析

RocketMQ expoter 获取监控目标的流程如下图所示，Expoter 通过 MQAdminExt 向 RocketMQ 集群恳求数据。获取的数据转换成 Prometheus 需求的格式，然后通过 /metics 接口暴露出来。

rocketmq exporter

跟着 RocketMQ 的演进，exporter 形式逐渐暴露出一些缺点：

• 无法支撑 RocketMQ 5.x 中新加入的 Proxy 等模块的可观测需求；
• 目标定义不符合开源标准，难以和其他开源可观测组件搭配运用；
• 很多 RPC 调用给 Broker 带来额定的压力；
• 拓展性差，添加/修正目标需求先修正 Broker 的 admin 接口。

为解决以上问题，RocketMQ 社区决议拥抱社区标准，在 RocketMQ 5.x 中推出了根据 OpenTelemtry 的 Metrics 计划。

RocketMQ 5.x 原生 Metrics 完成

根据 OpenTelemtry 的 Metrics

OpenTelemetry 是 CNCF 的一个可观测性项目，旨在供给可观测性范畴的标准化计划，解决观测数据的数据模型、收集、处理、导出等的标准化问题，供给与三方 vendor 无关的服务。

在讨论新的 Metrics 计划时 RocketMQ 社区决议恪守 OpenTelemetry 标准，彻底重新规划新 metrics 的目标定义：数据类型选用兼容 Promethues 的 Counter、Guage、Histogram，并且遵从 Promethues 推荐的目标命名标准，不兼容旧有的 rocketmq-exporter 目标。新目标掩盖 broker、proxy、producer、consumer 等各个 module，对音讯生命周期的全阶段供给监控才能。

目标上报方式

咱们供给了三种目标上报的方式：

• Pull 形式：合适自运维 K8s 和 Promethues 集群的用户；
• Push 形式：合适希望对 metrics 数据做后处理或接入云厂商的可观测服务的用户；
• Exporter 兼容形式：合适已经在运用 Exporter 和有跨数据中心（或其他网络隔离环境）传输 metrics 数据需求的用户。

Pull

Pull 形式旨在与 Prometheus 兼容。在 K8s 布置环境中无需布置额定的组件，prometheus 能够通过社区供给的 K8s 服务发现机制（创立 PodMonitor、ServiceMonitor CDR）自动获取要拉取的 broker/proxy 列表，并从他们供给的 endpoint 中拉取 metrics 数据。

pull mode

Push

OpenTelemetry 推荐运用 Push 形式，这意味着它需求布置一个 collector 来传输目标数据。

push mode

OpenTelemetry 官方供给了 collector 的完成，支撑对目标做自定义操作如过滤、富化，能够利用社区供给的插件完成自己的 collector。并且云厂商供给的可观测服务（如 AWS CloudWatch、阿里云 SLS）大多已经拥抱了 OpenTelemetry 社区，能够直接将数据推送到它们供给的 collector 中，无需额定的组件进行桥接。

OpenTelemetry collector

兼容 RocketMQ Exporter

新的 Metrics 也供给对 RocketMQ Exporter 的兼容，现在运用 exporter 的用户无需变更布置架构即可接入新 Metrics。并且控制面使用（如 Promethues）和数据面使用（如 RocketMQ）有或许隔离布置。因而借助 Exporter 作为署理来获取新的 Metrics 数据也不失为一种好的挑选。

RocketMQ 社区在 Exporter 中嵌入了一个 OpenTelemetry collector 完成，Broker 将 Metrics 数据导出到 Exporter，Exporter 供给了一个新的 endpoint（下图中的 metrics-v2）供 Prometheus 拉取。

exporter mode

构建监控系统最佳实践

丰厚的目标掩盖与对社区标准的遵从使得能够垂手可得的借助 RocketMQ 的 Metrics 才能构建出合适事务需求的监控系统，这个章节主要以一个典型的流程介绍构建监控系统的最佳实践：

集群监控/巡检 -> 触发告警 -> 排查剖析。

集群状况监控与巡检

咱们将目标收集到 Promethues 后就能够根据这些目标装备监控，这里给出一些示例：

接口监控：

监控接口调用状况，能够据此快速抓出反常的恳求对症下药

下图给出一些相关示例：所有 RPC 的耗时（avg、pt90、pt99 等）、成功率、失利原因、接口调用与返回值散布状况等。

rpc metrics

客户端监控：

监控客户端的运用状况，发现非预期的客户端运用如超大音讯发送、客户端上下线、客户端版别治理等。

下图给出一些相关示例：客户端连接数、客户端言语/版别散布、发送的音讯巨细/类型散布。

client metrics

Broker 监控：

监控 Broker 的水位和服务质量，及时发现集群容量瓶颈。

下图给出一些相关示例：Dispatch 推迟、音讯保存时刻、线程池排队、音讯堆积状况。

broker metrics

以上的示例只是 Metrics 的冰山一角，需求依据事务需求灵敏组合不同的目标装备监控与巡检。

告警装备

有了完善的监控就能够对需求重视的目标装备告警，比方能够装备 Broker 监控中 Dispatch 推迟这个目标的告警：

broker alert

收到告警后能够联动监控查看详细原因，关联发送接口的失利率能够发现有 1.7% 的消费发送失利，对应的报错是没有创立订阅组：

promblem analysis

问题排查剖析

最终以音讯堆积这个场景为例来看一下如何根据 Metrics 剖析线上问题。

从音讯生命周期看堆积问题

正如本文开篇所述，排查 RocketMQ 的问题需求结合音讯的生命周期归纳剖析，假如片面的认定是服务端/客户端的毛病不免会误入歧途。

关于堆积问题，咱们主要重视音讯生命周期中的两个阶段：

• 安排妥当音讯：安排妥当音讯是可供消费但还未被拉取的音讯，即在服务端堆积的音讯；
• 处理中音讯：处理中的音讯是被客户端拉取但是还未被消费的音讯。

consume lag

多维度目标剖析堆积问题

关于堆积问题，RocketMQ 供给了消费推迟相关目标 rocketmq_consumer_lag_latency 能够根据这个目标装备告警。告警的阈值需求依据当时事务对消费推迟的容忍程度灵敏指定。

触发告警后就需求对音讯堆积在仍是安排妥当音讯和处理中音讯进行剖析，RocketMQ 供给了 rocketmq_consumer_ready_messages 和 rocketmq_consumer_inflight_messages 这两个目标，结合其他消费相关目标与客户端装备归纳剖析即可判别出音讯堆积的根因：

• case 1：安排妥当音讯继续上涨，处理中音讯达到客户端堆积上限

这是最常见的堆积场景，客户端处理中的音讯量 rocketmq_consumer_inflight_messages 达到了客户端装备的阈值，即顾客的消费才能低于音讯发送量。假如事务要求尽或许实时的消费音讯就需求添加顾客机器数量，假如事务对音讯推迟不是很灵敏能够等候事务顶峰曩昔后再消化堆积的音讯。

• case 2：安排妥当音讯简直为 0，处理中音讯继续上涨

这个 case 多出现在运用 RocketMQ 4.x 客户端的场景，此刻消费位点是顺序提交的，假如某条音讯的消费卡住会导致位点无法提交。看起来的现象是音讯在客户端很多堆积，即处理中音讯继续上涨。能够结合消费轨迹和 rocketmq_process_time 这个目标抓出消费慢的音讯剖析上下游链路，找到根因优化消费逻辑。

• case 3: 安排妥当音讯继续上涨，处理中音讯简直为 0

此种场景说明客户端没有拉取到音讯，一般有如下几种状况：

• 鉴权问题：查看 ACL 装备，假如运用公有云产品请查看 AK、SK 装备；

• 顾客 hang 住：尝试打印线程堆栈或 gc 信息判别是否是进程卡死；

• 服务端响应慢：结合 RPC 相关目标查看拉取音讯接口调用量与耗时、硬盘读写推迟。查看是否为服务端问题，如硬盘 IOPS 被打满了等等。