共计 5273 个字符，预计需要花费 14 分钟才能阅读完成。
本文作者：郭雨杰，阿里云智能技术专家。
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，还可一键关联查看对应的日志详情，最终定位问题的根因。
当问题呈现时，除了方便快捷的问题定位过程，还须要针对告警提供绝对欠缺的告警解决和应急响应机制。ARMS 告警为用户提供了告警配置、告警排班、告警解决的全流程性能，不便客户建设应急解决、预先复盘和机制优化。
同时 ARMS 的智能告警平台反对 10+ 监控数据源的集成以及多渠道数据推送。基于钉钉的 CHARTOPS 让告警可合作、可追溯、可统计，并且可能提供异样查看、智能降噪等算法能力，无效缩小有效告警，并且能够在告警中基于利用的上下文失去告警的根因剖析。
阿里云 ARMS 监控从上到下云涵盖了用户的终端、利用、云服务 / 三方组件、容器、基础设施的全方位、立体化、对立监控和对立告警能力，是企业构建一站式可观测的最佳实际平台。
