异步请求积压可视化｜如何 1 分钟内快速定位函数计算积压问题

异步请求积压可视化｜如何 1 分钟内快速定位函数计算积压问题

本文分为三个部分：概述中引入了积压问题，并介绍了函数计算异步调用基本链路；并在指标介绍部分详细介绍了指标查看方式，分类解读了不同的指标含义；最后以一个常见的异步请求积压场景为例，介绍如何在 1 分钟内快速定位积压问题。

为异步调用保驾护航

使用函数计算异步调用的开发者最关心的问题是：调用请求能否在预期的时间内被处理完成。若没能处理完成，那么在客户眼中就是异步调用请求积压了，然而基于之前函数计算异步调用指标体系，无论是定位积压，还是查看积压，过程都是十分繁琐的。针对以上问题，函数计算推出了一系列异步调用请求积压相关的指标，能够帮助用户快速定位请求积压，向用户展示积压量化值。本文将详细介绍如何通过这些监控指标快速定位到函数异步调用出现的积压问题，为各位开发者讲解升级后的异步调用指标体系。在开始之前，先简单介绍下函数计算异步调用。异步调用是函数计算调用函数的一种方式，通过异步调用你不仅可以确保函数会至少执行一次，还可以保存调用执行过程中的状态转换信息和执行结果，其调用链路如下所示：用户/事件源发起异步调用请求后会立刻返回本次请求 ID，随后函数计算系统将本次调用的相关信息转换为消息的格式，放入 MNS 消息队队列中供系统内下游模块消费，下游模块会基于解析出来的调用消息进行函数调用。调用完成后，如果函数配置了 Destination，则系统会基于调用结果以及 Destination 内容进行进一步处理，Destination 相关内容介绍请参考异步调用文档：_class="data-table" data-id="t7216feb-4MeZjC4D" data-transient-attributes="class" data-width="576px" style="width: 100%; outline: none; border-collapse: collapse;">

指标类型

指标名称

单位

纬度

异步调用处理情况

异步请求入队

次

服务; 函数

异步请求处理完成

次

服务; 函数

异步请求积压数

个

函数

异步消息处理延时

平均处理时延

毫秒

服务; 函数

下面我们将对上述指标进行详细解读。

指标查看

至此，我们已经学会了这些指标的查看途径。下面继续为各位开发者介绍解读上述异步链路相关指标。

指标解读

我们将根据不同的指标类型对监控指标进行分类解读。

异步调用处理情况

异步请求入队

异步调用中，到达函数计算的请求数，当入队请求数大于请求处理完成数时，表示有请求积压，函数处理异步请求的速度小于异步请求发起的速度。请调整函数弹性伸缩（含预留资源）上限，参考：_这些请求的数量为异步消息积压数，当这个值不为 0 时，表示异步调用请求是有积压的。该指标将异步调用请求积压量化，解决积压数不可见问题，极大提高了异步调用的可观测性，也是本次升级的重要内容之一。

异步请求处理延时

平均处理时延

函数异步调用请求从进入处理队列到开始处理的时延，按指定时间粒度统计求平均值。当该值高于预期时，表明函数异步调用请求可能存在积压。“异步请求入队”、“异步请求处理完成” 以及 “平均处理延时” 这三个指标被放置在监控大盘的概览图表中，旨在帮助用户快速定位到出现积压的函数，解决积压定位难的问题。

1 分钟定位积压问题

在之前的异步调用指标体系下，如果想要定位积压问题，首先需要找到积压函数，此时需要逐个函数查看其函数监控指标详情，定位成功后，也无法直观看到具体的积压量化值。升级后的异步调用指标体系能够很好地解决积压问题定位难以及积压量化的问题。下面将围绕积压问题的场景，描述如何使用上述指标快速定位积压问题。

业务场景

问题描述：

小张的业务涉及到三个函数，且都是异步调用，某天用户的业务出了问题，每个环节的异步处理时延都增大了。为了快速定位问题，用户想到了异步链路监控指标，进行了如下定位动作。

定位过程：​首先打开地域级别的监控大盘，选择目标时间段，查看该地域下各个服务的监控指标；​

​从请求积压数图中可以看到积压是从 15:07 时间开始的，当前该账号下未完成的异步调用请求数最大时大约有 7000 左右 ，同时异步调用请求处理平均时延在逐步升高，目前是 30 万毫秒左右。每分钟处理的异步调用请求数在 800 -- 900 之间。

注：由于小张目前使用的是账号级别共享队列，因此异步请求积压数显示的整个账号下的异步调用请求积压数，如因业务需要，函数需要独享队列，可以联系函数计算团队进行开通。

进一步发现，地域按量实例数图中实例数已经打满，因此定位到原因是因为 A-Function 的请求激增，账号级别的按量实例数限制打满了，使得其他函数的异步调用也受到了影响，导致业务每个环节都受到了影响。

问题解决：

定位到问题后，小张立刻联系了函数计算团队，基于业务量进行了地域按量实例限制调整。同时 A-Function 调用量最大，可能会对地域纬度的异步调用请求调度以及按量实例数产生一定的冲击，对其他函数的异步调用请求造成影响，因此函数计算团队建议为 A-Function 开启独享队列功能，同时设置弹性实例上限，这样将 A-Function 的异步调用请求进行隔离，避免对其他函数的影响。

总结

升级后的函数计算异步调用监控指标体系能够帮助用户解决积压问题定位难以及积压量化等问题，结合云监控报警的设置，极大提高了函数计算异步调用应用的稳定性。

同时，为了尽量避免请求积压情况的发生，我们目前正在对函数计算异步处理系统层面进行优化，包括队列回收机制、独享队列能力以及积压消息重定向策略等，从而提高函数计算系统处理异步调用请求的能力。这样，通过强大的异步调用请求处理系统以及全面的监控指标体系，为函数计算异步调用保驾护航。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。