本文为您介绍如何将消息队列RocketMQ版可观测性功能应用于消息队列RocketMQ版的故障管理场景中,为您的日常运维和故障处理提供实践方案。

设计思路

核心问题

运维场景下,故障处理的核心问题如下:
  • 服务出现异常如何预警并上报
  • 出现异常问题如何快速定位

解决方案

消息队列RocketMQ版定义的Metrics、Tracing指标覆盖消息收发各阶段的状态信息、消息队列RocketMQ版服务端及资源的吞吐量等数据。具体使用时可将这些指标大致分为以下三类:
  • 一级指标:建议将没有歧义的、可衡量业务正常运行的指标作为一级指标,这些指标出现异常则一定是业务链路出现问题,一般可用做监控报警项。

    例如,消息收发TPS超过规格限制可触发实例流控,您可以将实例消息收发TPS指标作为监控项并创建报警规则,可以有效避免实例被流控处理,影响消息收发。

  • 二级指标:建议将能够明确反映问题所在位置的指标作为二级指标。

    例如,消息堆积量可明确反映消息消费阶段出现问题;消息发送失败次数则可以明确反映消息发送阶段出现问题。

  • 三级指标:三级指标可作为对二级指标的进一步分析,通过三级指标能够高效定位二级指标波动的具体原因。

消费异常场景实践方案

消费异常
  1. 使用消息处理滞后时间(rocketmq_consumer_lag_time_milliseconds)作为监控指标项并创建报警规则。具体操作,请参见监控报警
    该指标可明确反映消费链路的健康情况,并直接关联业务影响程度,比消息堆积量更加准确且没有歧义。
    • 消息量少时,使用消息堆积量作为告警监控项,不容易触发告警阈值。
    • 消息量大时,使用消息堆积量作为告警监控项,容易频繁产生误报。
    • 消息量波动较大时,无法准确设置消息堆积量告警阈值。
  2. 查看消息处理耗时(rocketmq_process_time)和消费失败次数(rocketmq_process_failure_total)等指标是否异常,初步定位是否是消费者客户端的问题。查询方式,请参见仪表盘
  3. 根据业务逻辑或指标的变化趋势定位具体原因,例如消息处理耗时变长,则可以查看消费者服务的内存、CPU等是否过载;或查看消费逻辑依赖的下游业务逻辑的运行状态进行进一步分析。

生产异常场景实践方案

生产异常
  1. 使用消息发送失败次数( rocketmq_send_failure_total)作为监控指标项并创建报警规则。具体操作,请参见监控报警
    该指标项可直接反映消息发送链路是否异常。
  2. 查看生产者连接数(rocketmq_producer_connections)是否正常。查询方式,请参见仪表盘
  3. 根据经验检查网络是否正常,或检查是否是服务端重启造成的短期发送失败。