Prometheus 监测 RocketMQ 最佳实践-六虎

本文作者：郭雨杰，阿里云智能技能专家。

Prometheus 集成的 50 多款云产品中，RocketMQ 在可观测方面完成了十分完善的功用，是一个特别具有代表性的云产品。

RocketMQ 如何接入 Prometheus

RocketMQ 诞生于阿里内部的中心电商体系，是事务音讯的首选 MQ 渠道。上图是 RocketMQ 5.0 的体系全貌，在接入层、中心组件和底层运维方面做了十分大的改善，具有功用多样、高性能、高牢靠、可观测、易运维等许多优势。

Metrics、Tracing、Logging 是可观测才干的三大支柱。

Metrics：RocketMQ 以 Prometheus+Grafana 这种在开源范畴广泛运用的产品组合为用户供给了开箱即用的 Dashboard。目标涵盖了音讯量、堆积量、各阶段耗时等，该大盘结合 RocketMQ 团队在音讯范畴多年的研制和运维经历打磨的最佳实践模板，并供给了持续的迭代更新才干。
Tracing：RocketMQ 初次引进了 OpenTelemetry tracing 的开源规范，依照音讯的维度，从头安排了抽象的 span 拓扑。
Logging：Logging 方面首要进行了一些客户端日志的规范化处理，可以更简单方便地运用日志定位问题。

RocketMQ 的一切可观测性数据都是环绕一条音讯在出产端、服务端处理、消费阶段展开。从音讯的生命周期图上，可以看到一条音讯从 Producer 开端发送到 MQ server 接收到的耗时；假如是守时音讯依据 Ready time 可以知道守时的时刻；从 Consumer 的角度上看，可以知道音讯从开端拉取到抵达客户端的网络耗时；从抵达客户端的时刻到开端处理音讯的等候处理资源耗时；从开端处理音讯到最后回来的 ACK 的处理耗时。音讯在生命周期的任何一个阶段，都可以清晰地被定义而且被观测到，这就是 RocketMQ 可观测的中心理念。

RocketMQ 团队贡献的 RocketMQ exporter 已被 Prometheus 官方的开源 Exporter 生态所收录，供给了 Broker、Producer、Consumer 各个阶段丰富的监控目标。Exporter 根本逻辑是经过在内部发动多个守时任务周期性地从 MQ 的集群上拉取数据，然后将数据规范化后经过端点露出给Prometheus。MQAdminExt 类封装了 MQAdmin 露出的各种接口逻辑。从结构上看，RocketMQ 的 Exporter 是站在第三方视角的观察者人物，而一切的目标来自于 MQ 集群的内部。

Prometheus 在运用程序中露出监控目标的进程需求注意以下两点：

Exporter 布置形式的挑选分为将 Prometheus client 内嵌到运用程序的直接观测形式以及运用程序之外的独立 Exporter 形式。直接观测形式具有主流语言支撑、性能更优、免运维的优势，劣势为代码耦合。Exporter 形式具有解耦合、开源生态丰富的优势，最大的缺陷是需求单独的运维 Exporter 组件，在云原生微服务的运用架构形式下需求布置多个 Exporter 对运维带来不小的担负。关于布置形式的挑选没有好坏之分，一般建议对运用代码有掌控权限的条件下，挑选直接观测形式，对运用代码无掌控权限的条件下挑选 Exporter 形式。
尽量防止目标维度发散而引起的高基数问题。由于 Prometheus 的目标模型扩展维度只需求添加一个 label十分的方便，许多用户将需求的尽可能多的维度都添加到目标中，这就必然会引进一些不可枚举的维度，比方常见的 userid、url、email、ip 等。Prometheus总体的时刻线数量依照目标以及维度的组合乘积联系来核算，因而高基数问题不只带来了巨大的存储本钱，而且会由于瞬时回来的数据过多，对查询侧带来不小的性能应战，而且严峻的维度发散使得目标自身失去了计算上的意义。因而，在运用进程中，应尽量防止目标维度发散问题。

咱们在运用 Prometheus Client 时也会遇到高基数问题，尤其是 RocketMQ 的目标，供给了账号、实例、 topic、顾客 Group ID 等多个维度的组合使得全体的时刻线数量处于一个很高的量级。实践进程中咱们针对 Prometheus 原生的 Client 做了两点针对性的优化，目的是有效地操控 Exporter 的高基数问题带来的内存危险。

RocketMQ 的出产环境中，需求做到对售卖租户的客户级监控。每个客户的 RocketMQ 资源都依照租户进行严格阻隔。假如为每一个租户布置一套 Exporter ，则会对产品的架构、运维等方面都带来十分大的应战。因而在出产环境中，RocketMQ 挑选了另一种接入 Prometheus 的方法。

RocketMQ 5.0 的架构方面做出了较大的改善。多语言衰弱客户端底层一致运用了 gRPC 协议将数据发送到服务端，一起 MQ server 也拆分为了可拆可合的 CBroker（proxy）和 SBroker 两个人物。架构变更的一起，RocketMQ 5.0 在客户端和服务端一起引进了 OpenTelemetry tracing 规范埋点的规范。

全链路 Tracing

客户端嵌入了OpenTelemetry Exporter，将 Tracing 的数据批量发送到 proxy。
proxy 自身作为一个 collector 整合了客户端上报的以及自身的 tracing 数据。
tracing 的存储支撑用户自定义 collector，商业版托管存储，开源版本存储上报到自己的渠道。
针对音讯的生命周期，从头设计了 span 的拓扑模型。

精确多样的 Metrics

在服务端对收到的 tracing 数据进行二次聚合核算，得到的核算后的目标契合OpenMetrics 规范。
可以无缝地集成到 Prometheus 存储和 Grafana 的大盘展现。

RocketMQ span 拓扑模型。该拓扑模型针对 Prod、Recv、Await、Proc、ACK/Nack 阶段别离做了从头规范化的埋点处理，一起将 OpenTelemetry的 tracing 模型中的 attributes 部分规范提交到 OpenTelemetry specification 规范安排并得到收录。

以上的改善使得音讯轨道功用得到了极大的增强，不只可以依据音讯的根本信息查询相关轨道，还能对音讯的生命周期的各个阶段一望而知。点开 trace ID ，还可以看到具体的追踪信息，而且可以相关看到出产者、顾客以及相关资源，比方机器信息的展现。

RocketMQ 的目标数据为什么要接入到 Prometheus ？由于 Prometheus 天然契合了云原生的架构，在开源范畴 Prometheus 处于 metrics 事实规范地位。Prometheus 为云原生架构而生，与 Kubernetes 天然集成，具有自动发现、多层次收集的才干、强大的生态、通用的多模目标模型、以及强大的 PromQL 的查询语法等特色。

RocketMQ 是根据 trace 数据进行二次核算为 metric 来对接 Prometheus 的。前文讲到了 RocketMQ 5.0 引进了 OpenTelemetry tracing 埋点，咱们将客户端和服务端上报的 tracing 数据一致存储到阿里云日志体系中，根据 tracing 数据依据多个维度进行二次聚合，产生了契合 Prometheus 目标规范的时序数据。在 ARMS 团队内部，经过实时 ETL 工具将日志数据转化为目标按租户存储到 Prometheus 体系中。RocketMQ 操控台深度集成了 Grafana 的大盘和 Alarm 告警模块，用户只需求在 RocketMQ 的实例监控页面中开通 Prometheus 即可一键获取自己名下的大盘和告警信息。

ARMS Prometheus 集成了许多的云产品监控目标，针对云产品的多租需求供给了一套完整的解决方案。阿里云的云产品除了需求对产品自身的目标进行监控外，一起需求对产品售卖的租户目标进行监控。

云产品针对租户资源划分，首要分为租户独占资源形式和租户共享资源形式。租户独占资源形式具有租户单独占用布置资源，阻隔性好的特色，辨认目标的租户信息只需求打上租户目标即可；租户共享资源形式指租户之间会共享布置资源，辨认目标的租户信息需求云产品自行添加租户信息。

ARMS Prometheus 监控相关于开源的 Prometheus 采用了收集和存储分离的架构，收集端具有多租辨认和分发才干，存储端内置了多租才干，租户之间的资源彻底阻隔。

ARMS Prometheus 会为每个阿里云用户创立一个 Prometheus 云服务的实例，来存储用户对应的阿里云的云产品目标，真正地解决了以往监控体系数据涣散形成的数据孤岛问题，一起为每个云产品供给了深度定制、开箱即用的大盘和告警才干。

上图为 RocketMQ 默认集成的 Grafana 大盘示例。大盘供给 Overview 概览、Topic 音讯发送、Group ID 音讯消费等细粒度的监控数据支撑。相较于开源完成，该大盘供给了更多更精确的目标数据，一起结合了 RocketMQ 团队在音讯范畴的多年运维经历打磨的最佳实践模板，并供给了持续迭代更新的才干。

RocketMQ可观测最佳实践

单纯地重视音讯体系供给的可观测数据只能发现一部分的问题，在一个实在的微服务体系中，用户需求重视整个技能栈全局中的接入层、事务运用、中间件、容器、底层 IaaS的可观测数据才干精确地定位问题。上图是一个十分典型的音讯体系上下流的运用结构。上游订单体系发送音讯，下流库存体系、营销体系订阅音讯，完成上下流的解耦。如何在这样一个杂乱的事务体系中发现问题、解决问题，需求对整个体系的可观测性做全面整理。

首要需求对体系中的各个组成部分可观测数据进行收集，Metric、Trace、Log 的三大支柱必不可少。Metric 衡量了运用状态，经过目标告警可以快速地发现问题；Trace 数据可以做到恳求等级的全周期的跟踪途径，经过排查调用链路可以快速地定位问题；Log 数据具体记录了体系产生的事情，经过日志剖析可以快速地排查故障。

上图为 ARMS Kubernetes 监控沉积的诊断经历。经过在运用的技能栈端到端、自顶向下的全栈相关方法，为咱们在横向、纵向将可观测问题诊断定位供给了实践思路参考。关于跟事务相关的组件而言，需求更多地重视影响用户体会的 RED 目标，在资源层应该更多地重视资源饱和度相关的目标。一起需求横向地重视日志、事情、调用链相关，只有多方位、全视角的可观测才干够愈加清晰地排查定位问题。

上图为一个音讯堆积场景的例子。

首要需求理解音讯堆积的目标意义。一条音讯在 Producer 发送后，在音讯行列中的处理以及 Consumer 消费的三个阶段别离处于 Ready、inFlight、Acked 状态。需求重点重视两个目标，已安排妥当音讯量（Ready message）表明已安排妥当的音讯条数，该音讯量的巨细反映了还未被消费的音讯规划，在顾客反常的情况下，安排妥当音讯的数据量会变多；音讯排队时刻（Queue time）表明最早一条安排妥当音讯的安排妥当时刻和当时的时刻差，该时刻巨细反映了还未被处理音讯的时刻延迟情况，关于时刻灵敏的事务而言是一个十分重要的度量目标。

音讯堆积的原因首要有两点，消费端故障或消费才干不足导致，或者上游出产端音讯量过大，下流消费才干不足导致。

关于出产端更应该重视音讯的发送健康度，可以针对发送成功率进行告警。呈现告警时，需求重视 load、发送耗时、音讯量等目标，判别是否有音讯量的忽然改变；关于消费端应该重视消费是否及时的消费健康度，可针对安排妥当音讯的排队时刻进行告警。当呈现告警时，需求相关地重视音讯的处理耗时、消费的成功率、音讯量、load 等相关目标，判别音讯的音讯量、消费处理的耗时的改变，并查询是否有 ERROR 日志、trace 等相关信息。

用户可以运用阿里云 ARMS 产品，可以更方便快捷地处理以上排查进程。

收到告警信息之后，经过查询事务拓扑、反常标示以及事务目标的改变，一键地查看相关的调用链信息，在调用链上可以获得事务处理各个阶段的处理时长、是否存在反常等相关信息。调用链的每个 span 节点可以下钻实时查询调用仓库和耗时分占比，将问题定位到事务代码等级。假如用户接入的日志中依照 ARMS 规范相关到调用链的 traceID ，还可一键相关查看对应的日志概况，最终定位问题的根因。