乐趣区

关于阿里云:RocketMQ-监控告警生产环境如何快速通过监控预警发现堆积收发失败等问题

jiezi

作者：合伯

本文次要向大家介绍如何利用 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 指标和告警监控项。各监控项可分为运行水位、收发性能、异样谬误事件三类告警。依据大量生产环境实践经验，建议您依据以下准则配置如下告警

接下来重点通过音讯沉积和音讯收发失败这两个典型场景来论述基于可观测体系中的指标（Metrics），RocketMQ 如何通过云监控创立监控规定，将要害的 Metrics 指标作为告警项，帮忙您主动监控服务的运行状态，并主动发送报警告诉，便于您及时预警服务的异样信息，进步运维效率。

利用场景 1：音讯沉积问题

音讯沉积指标及监控配置

业界通用指标：应用音讯沉积量（ready + inflight）来度量生产衰弱度，示意未解决实现的音讯量；局部产品额定减少已就绪音讯量来度量音讯拉取的及时性；应用上述 2 个指标间接来配置报警有以下毛病：

  • 有误报或无奈触发报警的问题
  • 及时性的间接指标，不直观

RocketMQ 指标：额定反对延时工夫来度量生产衰弱度，涵盖了所有业务场景，依据业务容忍提早度间接配置工夫告警阈值。

  • 音讯解决延迟时间：示意业务解决实现及时度
  • 已就绪音讯排队工夫：示意拉取音讯及时度

倡议对音讯沉积敏感的用户，都在 RocketMQ 实例页的监控报警，增加如下报警指标，并设置合乎业务需要的阈值。

如何定位和解决沉积问题

如果收到沉积报警，确认音讯呈现沉积状况，可参考以下措施进行定位和解决。

  1. 判断音讯沉积在 RocketMQ 服务端还是客户端
  • 查看客户端本地日志文件 ons.log，搜寻是否呈现如下信息：the cached message count exceeds the threshold
  • 呈现相干日志信息，阐明客户端本地缓冲队列已满，音讯沉积在客户端，请执行步骤 2。
  • 若未呈现相干日志，阐明音讯沉积不在客户端，若呈现这种非凡状况，请间接提交工单分割阿里云技术支持。
  1. 确认音讯的生产耗时是否正当
  • 若查看到生产耗时较长，则须要查看客户端堆栈信息排查具体业务逻辑，请执行步骤 3。
  • 若查看到生产耗时失常，则有可能是因为生产并发度不够导致音讯沉积，须要逐渐调大生产线程或扩容节点来解决。

音讯的生产耗时能够通过以下形式查看：

查看消费者状态，在客户端连贯信息中查看业务解决工夫，获取生产耗时的平均值。

  1. 查看客户端堆栈信息。只须要关注线程名为 ConsumeMessageThread 的线程，这些都是业务生产音讯的逻辑。
  • 客户端堆栈信息能够通过以下形式获取：查看消费者状态，在客户端连贯信息中查看 Java 客户端堆栈信息
  • 应用 Jstack 工具打印堆栈信息。

常见的异样堆栈信息如下：

    • 示例一：
    • 生产逻辑有抢锁休眠期待等状况。
    • 生产线程阻塞在外部的一个睡眠期待上，导致生产迟缓。
    • 示例二：
    • 生产逻辑操作数据库等内部存储卡住。
    • 生产线程阻塞在内部的 HTTP 调用上，导致生产迟缓。
  1. 针对某些非凡业务场景，如果音讯沉积曾经影响到业务运行，且沉积的音讯自身能够跳过不生产，您能够通过重置生产位点跳过这些沉积的音讯从最新位点开始生产，疾速复原业务。

如何防止音讯沉积

为了防止在业务应用时呈现非预期的音讯沉积和提早问题，须要在后期设计阶段对整个业务逻辑进行欠缺的排查和梳理。整顿出失常业务运行场景下的性能基线，能力在故障场景下迅速定位到阻塞点。其中最重要的就是梳理音讯的生产耗时和音讯生产的并发度。

  • 梳理音讯的生产耗时通过压测获取音讯的生产耗时，并对耗时较高的操作的代码逻辑进行剖析。梳理音讯的生产耗时须要关注以下信息：
    • 音讯生产逻辑的计算复杂度是否过高，代码是否存在有限循环和递归等缺点。
    • 音讯生产逻辑中的 I/O 操作（如：内部调用、读写存储等）是否是必须的，是否用本地缓存等计划躲避。内部 I/O 操作通常包含如下业务逻辑：
    • 读写内部数据库，例如 MySQL 数据库读写。
    • 读写内部缓存等零碎，例如 Redis 读写。
    • 上游零碎调用，例如 Dubbo 调用或者上游 HTTP 接口调用。
    • 生产逻辑中的简单耗时的操作是否能够做异步化解决，如果能够是否会造成逻辑错乱（生产实现但异步操作未实现）。
  • 设置音讯的生产并发度
    • 逐渐调大线程的单个节点的线程数，并观测节点的零碎指标，失去单个节点最优的生产线程数和音讯吞吐量。
    • 失去单个节点的最优线程数和音讯吞吐量后，依据上下游链路的流量峰值计算出须要设置的节点数，节点数 = 流量峰值 / 单线程音讯吞吐量。

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

音讯收发的外围流程

从上图中能够看出音讯收发都要先从 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。

    1. 配置限流次数告警

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 版产品

退出移动版