文档

通过可观测性能力进行故障处理最佳实践

更新时间:
一键部署

通过仪表盘、监控报警等可观测功能,您可以对消息收发各阶段的重点指标和服务端状态进行监控和观测,并对重点指标设置告警规则以便及时上报异常。本文为您介绍如何将云消息队列 RocketMQ 版可观测性功能应用于云消息队列 RocketMQ 版的故障管理场景中,为您的日常运维和故障处理提供实践方案。

设计思路

核心问题

运维场景下,故障处理的核心问题如下:

  • 服务出现异常如何预警并上报

  • 出现异常问题如何快速定位

解决方案

云消息队列 RocketMQ 版定义的Metrics、Tracing指标覆盖消息收发各阶段的状态信息、云消息队列 RocketMQ 版服务端及资源的吞吐量等数据。具体使用时可将这些指标大致分为以下三类:

  • 一级指标:建议将没有歧义的、可衡量业务正常运行的指标作为一级指标,这些指标出现异常则一定是业务链路出现问题,一般可用做监控报警项。

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

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

    例如,消息堆积量可明确反映消息消费阶段出现问题;消息生产调用成功率则可以明确反映消息发送阶段是否正常。

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

消费异常场景实践方案

消费异常

  1. 使用消息处理延迟时间(ConsumerLagLatencyPerGidTopic)作为监控指标项并创建报警规则。具体操作,请参见监控报警

    该指标可明确反映消费链路的健康情况,并直接关联业务影响程度,比消息堆积量更加准确且没有歧义。

    • 消息量少时,使用消息堆积量作为告警监控项,不容易触发告警阈值。

    • 消息量大时,使用消息堆积量作为告警监控项,容易频繁产生误报。

    • 消息量波动较大时,无法准确设置消息堆积量告警阈值。

  2. 查看消息处理耗时(rocketmq_process_time)和消息处理成功率(rocketmq_process_time_count{invocation_status="success"/invocation_status="success|failure"} )等指标是否异常,初步定位是否是消费者客户端的问题。

    消息处理成功率=消息处理成功次数/消息处理失败次数+成功次数。

    查询方式,请查看仪表盘中,消费者指标下的统计面板。

  3. 根据业务逻辑或指标的变化趋势定位具体原因,例如消息处理耗时变长,则可以查看消费者服务的内存、CPU等是否过载;或查看消费逻辑依赖的下游业务逻辑的运行状态进行进一步分析。

生产异常场景实践方案

生产异常

  1. 查看消息发送成功率(rocketmq_send_cost_time_count{invocation_status="success"/invocation_status="success|failure"})是否正常,消息发送成功率=消息发送成功次数/消息发送失败次数+成功次数。

    查询方式,请查看仪表盘中,生产者指标下的统计面板。

  2. 根据经验检查网络是否正常,或检查是否是服务端重启造成的短期发送失败。

  • 本页导读 (1)
文档反馈