作者：合伯

本文主要向大家介绍怎么运用 RocketMQ 可观测系统中的目标监控，对生产环境中典型场景：音讯堆积、音讯收发失利等场景装备合理的监控预警，快速发现问题，定位问题。

RocketMQ 可观测系统

作为一款典型的分布式中间件产品，RocketMQ 被广泛使用于事务中心链路中，每条音讯都相关着中心事务数据的改变。事务链路有其明显的杂乱性：

    • 生产者、顾客多对多：事务调用链路网状结构，上下流整理困难
    • 上下流解耦、异步链路：异步化调用，信息收集不完整
    • 音讯是状况数据：未消费成功、定时中等状况增加排查的杂乱度
    • 音讯链路耦合杂乱的事务处理逻辑：无法快速定位问题边界

鉴于音讯链路耦合事务系统，杂乱带状况，RocketMQ 经过强壮的可观测系统和经历支撑，及时发现问题、定位问题、处理问题有助于提升运维功率，对于事务运转是一项重要的保证能力。

RocketMQ 监控告警：生产环境如何快速通过监控预警发现堆积、收发失败等问题？

RocketMQ 的可观测系统主要由目标（Metrics）、轨道（Tracing）和日志（Logging）组成。

  • 目标

RocketMQ中定义了详细的Metrics目标，这些目标覆盖生产者、顾客、服务端及音讯收发要害接口和流程的统计数据，并支持从实例、Topic和Group等多个维度进行聚合展示，协助您实时监控音讯事务或RocketMQ服务的运转状况。和4.x版别相比，RocketMQ服务端5.x版别增加了音讯堆积场景相关目标、要害接口的耗时目标、过错分布目标、存储读写流量等目标，协助您更好地监控反常场景。

  • 音讯轨道

在分布式使用中，RocketMQ作为全链路中异步解耦的要害服务，供给的Tracing数据可有用将事务上下流信息串联起来，协助您更好地排查反常，定位问题。和4.x版别相比，RocketMQ服务端5.x版别支持OpenTelemetry开源标准，供给愈加丰富的轨道目标，针对消费场景、高档音讯类型场景等细化轨道内容，为问题定位供给更多要害信息。

  • 日志

RocketMQ为不同的反常状况定义唯一的过错码及过错信息，并划分不同的过错级别，您能够依据客户端回来的过错码信息快速获取反常原因。和4.x版别相比，RocketMQ服务端5.x版别统一了ErrorCode和ErrorMessage，反常日志中增加了RequestID、资源信息，细化了过错信息，保证日志内容清晰靠。

RocketMQ 监控告警介绍

RocketMQ 联合阿里云云监控供给了开箱即用且免费的监控报警服务，可协助您处理如下问题：

  • 实例标准水位监控预警

若您实际运用的目标值超越实例的标准约束，RocketMQ会进行强制限流。提早装备实例标准水位告警能够提早发现标准超限危险并及时升配，防止因限流导致的事务故障。

  • 事务逻辑过错监控预警

您在音讯收发时或许会收到反常报错，装备调用过错告警能够提早在事务反应前发现反常，协助您提早判断反常来源并及时修复。

  • 事务性能目标监控预警

假如您的音讯链路有相关性能目标要求，例如RT耗时、音讯推迟等，提早装备事务目标告警能够协助您提早治理事务危险。

RocketMQ 版供给了丰富的 Metric 目标和告警监控项。各监控项可分为运转水位、收发性能、反常过错事情三类告警。依据大量生产环境实践经历，主张您依据以下原则装备如下告警

RocketMQ 监控告警：生产环境如何快速通过监控预警发现堆积、收发失败等问题？

接下来重点经过音讯堆积和音讯收发失利这两个典型场景来论述基于可观测系统中的目标（Metrics），RocketMQ 怎么经过云监控创立监控规矩，将要害的 Metrics 目标作为告警项，协助您自动监控服务的运转状况，并自动发送报警告诉， 便于您及时预警服务的反常信息，提高运维功率。

使用场景1：音讯堆积问题

音讯堆积目标及监控装备

RocketMQ 监控告警：生产环境如何快速通过监控预警发现堆积、收发失败等问题？

业界通用目标：运用音讯堆积量（ready + inflight）来衡量消费健康度，表明未处理完结的音讯量；部分产品额定增加已安排妥当音讯量来衡量音讯拉取的及时性；运用上述 2 个目标直接来装备报警有以下缺陷：

  • 有误报或无法触发报警的问题

  • 及时性的直接目标，不直观

RocketMQ 监控告警：生产环境如何快速通过监控预警发现堆积、收发失败等问题？

RocketMQ 目标：额定支持延时时刻来衡量消费健康度，涵盖了一切事务场景，依据事务容忍推迟度直接装备时刻告警阈值。

  • 音讯处理推迟时刻：表明事务处理完结及时度

  • 已安排妥当音讯排队时刻：表明拉取音讯及时度

主张对音讯堆积灵敏的用户，都在 RocketMQ 实例页的监控报警，增加如下报警目标，并设置契合事务需求的阈值。

RocketMQ 监控告警：生产环境如何快速通过监控预警发现堆积、收发失败等问题？

RocketMQ 监控告警：生产环境如何快速通过监控预警发现堆积、收发失败等问题？

怎么定位和处理堆积问题

假如收到堆积报警，承认音讯呈现堆积状况，可参阅以下办法进行定位和处理。

  1. 判断音讯堆积在 RocketMQ 服务端仍是客户端
  • 查看客户端本地日志文件 ons.log，查找是否呈现如下信息：the cached message count exceeds the threshold
  • 呈现相关日志信息，阐明客户端本地缓冲行列已满，音讯堆积在客户端，请执行步骤2。
  • 若未呈现相关日志，阐明音讯堆积不在客户端，若呈现这种特殊状况，请直接提交工单联系阿里云技术支持。
  1. 承认音讯的消费耗时是否合理
  • 若查看到消费耗时较长，则需求查看客户端仓库信息排查详细事务逻辑，请执行步骤3。
  • 若查看到消费耗时正常，则有或许是因为消费并发度不够导致音讯堆积，需求逐步骤大消费线程或扩容节点来处理。

音讯的消费耗时能够经过以下方法查看：

查看顾客状况，在客户端衔接信息中查看事务处理时刻，获取消费耗时的平均值。

RocketMQ 监控告警：生产环境如何快速通过监控预警发现堆积、收发失败等问题？

  1. 查看客户端仓库信息。只需求关注线程名为 ConsumeMessageThread 的线程，这些都是事务消费音讯的逻辑。
  • 客户端仓库信息能够经过以下方法获取：查看顾客状况，在客户端衔接信息中查看 Java 客户端仓库信息

RocketMQ 监控告警：生产环境如何快速通过监控预警发现堆积、收发失败等问题？

RocketMQ 监控告警：生产环境如何快速通过监控预警发现堆积、收发失败等问题？

  • 运用 Jstack 工具打印仓库信息。

常见的反常仓库信息如下：

    • 示例一：
    • 消费逻辑有抢锁休眠等候等状况。
    • 消费线程阻塞在内部的一个睡觉等候上，导致消费缓慢。

RocketMQ 监控告警：生产环境如何快速通过监控预警发现堆积、收发失败等问题？

    • 示例二：
    • 消费逻辑操作数据库等外部存储卡住。
    • 消费线程阻塞在外部的 HTTP 调用上，导致消费缓慢。

RocketMQ 监控告警：生产环境如何快速通过监控预警发现堆积、收发失败等问题？

  1. 针对某些特殊事务场景，假如音讯堆积现已影响到事务运转，且堆积的音讯自身能够越过不消费，您能够经过重置消费位点越过这些堆积的音讯从最新位点开始消费，快速恢复事务。

怎么防止音讯堆积

为了防止在事务运用时呈现非预期的音讯堆积和推迟问题，需求在前期设计阶段对整个事务逻辑进行完善的排查和整理。整理出正常事务运转场景下的性能基线，才能在故障场景下迅速定位到阻塞点。其间最重要的就是整理音讯的消费耗时和音讯消费的并发度。

  • 整理音讯的消费耗时经过压测获取音讯的消费耗时，并对耗时较高的操作的代码逻辑进行分析。整理音讯的消费耗时需求关注以下信息：

    • 音讯消费逻辑的核算杂乱度是否过高，代码是否存在无限循环和递归等缺陷。
    • 音讯消费逻辑中的 I/O 操作（如：外部调用、读写存储等）是否是必须的，能否用本地缓存等方案规避。外部 I/O 操作一般包括如下事务逻辑：
    • 读写外部数据库，例如 MySQL 数据库读写。
    • 读写外部缓存等系统，例如 Redis 读写。
    • 下流系统调用，例如 Dubbo 调用或许下流 HTTP 接口调用。
    • 消费逻辑中的杂乱耗时的操作是否能够做异步化处理，假如能够是否会形成逻辑紊乱（消费完结但异步操作未完结）。

  • 设置音讯的消费并发度

    • 逐步骤大线程的单个节点的线程数，并观测节点的系统目标，得到单个节点最优的消费线程数和音讯吞吐量。
    • 得到单个节点的最优线程数和音讯吞吐量后，依据上下流链路的流量峰值核算出需求设置的节点数，节点数=流量峰值/单线程音讯吞吐量。

使用场景2：音讯收发失利问题

音讯收发的中心流程

RocketMQ 监控告警：生产环境如何快速通过监控预警发现堆积、收发失败等问题？

从上图中能够看出音讯收发都要先从 NameServer 回来路由，再经过 broker 的鉴权以及实例标准是否超限的判断，才能进行正常收发音讯。依据经历检音讯收发失利的原因有如下状况：

  • API 恳求频率是否超越实例标准约束
  • 查网络是否正常
  • 服务端是否是有重启形成的短期收发失利
  • 操作资源是否有权限

常见的音讯收发失利反常

在无论开发阶段仍是生产运转阶段，遇到收发失利问题，我们都能够从客户端日志出发进行排查。以下列举下常见的音讯收发失利反常场景：

  1. 在客户端日志中呈现ClusterName ** consumer groupId ** consumer topic ** messages flow control, flow limit threshold is ***, remainMs **反常信息

原因：RocketMQ 每个实例都清晰了音讯收发 API 调用 TPS，例如，标准版实例支持每秒 5000 次 API 调用，若实例音讯收发 API 调用频率超越标准约束，会导致实例被限流。实例被限流后，导致部分音讯收发恳求失利。

主张办法：

    1. 装备实例 API 调用频率监控告警

主张设置为标准上限的 70%。例如，您购买的实例音讯收发 TPS 上限为 10000，则告警阈值主张设置为 7000。

RocketMQ 监控告警：生产环境如何快速通过监控预警发现堆积、收发失败等问题？

    1. 装备限流次数告警

RocketMQ 支持将指定实例触发限流的事情作为监控项，经过对限流次数的监控，能够协助您了解当前事务的受损状况。

RocketMQ 监控告警：生产环境如何快速通过监控预警发现堆积、收发失败等问题？

  1. 在客户端日志中呈现RemotingConnectException: connect to <118.xx.xx.xx:80> failed 或许 RemotingTimeoutException 等反常信息。

或许有如下原因：

    • MQ 服务晋级过程中 , 会呈现短暂的网络闪断，查看官网公告看是否在服务晋级窗口
    • 查看使用服务器到broker的网络是否通畅，是否有网络推迟
    • 查看使用的网络带宽状况，是否被打满
    • 承认下使用是否呈现 FGC 现象，FGC 会形成一定的网络推迟
  1. 在客户端日志傍边呈现 system busy, start flow control for a while 或许 broker busy, start flow control for a while等反常信息。

或许原因：同享集群 broker（呈现网络，磁盘，IO 等颤动）压力大，形成音讯收发呈现排队现象；若是偶然短暂颤动，此类过错 SDK 会自动重试，但主张在自己的事务代码做好反常处理，当自动重试次数超限仍失利状况下，事务依据需求做好容灾。若长时刻持续呈现，能够提工单让技术人员跟进排查。

点击此处查看音讯行列 RocketMQ 版产品