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

为异步调用保驾护航

​

使用函数计算异步调用的开发者最关心的问题是：调用请求能否在预期的时间内被处理完成。若没能处理完成，那么在客户眼中就是异步调用请求积压了，然而基于之前函数计算异步调用指标体系，无论是定位积压，还是查看积压，过程都是十分繁琐的。​

针对以上问题，函数计算推出了一系列异步调用请求积压相关的指标，能够帮助用户快速定位请求积压，向用户展示积压量化值。本文将详细介绍如何通过这些监控指标快速定位到函数异步调用出现的积压问题，为各位开发者讲解升级后的异步调用指标体系。

在开始之前，先简单介绍下函数计算异步调用。​

异步调用是函数计算调用函数的一种方式，通过异步调用你不仅可以确保函数会至少执行一次，还可以保存调用执行过程中的状态转换信息和执行结果，其调用链路如下所示：

用户/事件源发起异步调用请求后会立刻返回本次请求 ID，随后函数计算系统将本次调用的相关信息转换为消息的格式，放入 MNS 消息队队列中供系统内下游模块消费，下游模块会基于解析出来的调用消息进行函数调用。​

调用完成后，如果函数配置了 Destination，则系统会基于调用结果以及 Destination 内容进行进一步处理，Destination 相关内容介绍请参考异步调用文档：https://help.aliyun.com/document_detail/181866.html

指标升级

​

升级后的函数计算异步调用链路监控指标主要新增了如下几类：​

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

指标查看

​

目前可以通过函数计算控制台或者 Serverless Devs 工具这两种方式查看函数的监控指标大盘，下面我们将以控制台为例，指导大家如何查看异步调用链路相关的监控指标，基于 Serverless Devs 的查看方式可以参考：https://github.com/devsapp/fc/blob/main/docs/zh/command/metrics.md​

下面介绍的步骤前提是已开通了函数计算服务；且成功创建了服务以及函数，如果还未进行这些操作，请参考使用控制台创建函数：https://help.aliyun.com/document_detail/51783.html​

首先打开函数计算控制台，点击左侧 监控大盘 标签，滑倒底部，可以查看到该地域所有服务的异步调用处理情况以及异步消息处理平均延时概览表格：​

此时我们点击任意一个服务名称，进入后，可以看到该服务下所有函数的异步调用处理情况；以及异步消息处理平均延时概览表格：​

接下来我们点击任意一个函数名称，进入后可以看到所有函数纬度的监控指标，并以图的形式展示：​

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

指标解读

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

异步调用处理情况

异步请求入队

异步调用中，到达函数计算的请求数，当入队请求数大于请求处理完成数时，表示有请求积压，函数处理异步请求的速度小于异步请求发起的速度。请调整函数弹性伸缩（含预留资源）上限，参考：https://help.aliyun.com/document_detail/185038.html#task-2538034或可钉钉搜索加入阿里函数计算官网客户群（11721331）联系我们进行处理。​

异步请求处理完成

异步调用中，函数计算处理完成的请求数，异步请求处理完成数量，应始终不大于异步请求入队的数量。​

异步请求积压数

已经到达函数计算的异步请求中，等待处理以及正在处理中的请求统一视为积压请求， 这些请求的数量为异步消息积压数，当这个值不为 0 时，表示异步调用请求是有积压的。​

该指标将异步调用请求积压量化，解决积压数不可见问题，极大提高了异步调用的可观测性，也是本次升级的重要内容之一。​

异步请求处理延时

​

平均处理时延

函数异步调用请求从进入处理队列到开始处理的时延，按指定时间粒度统计求平均值。当该值高于预期时，表明函数异步调用请求可能存在积压。​

“异步请求入队”、“异步请求处理完成” 以及 “平均处理延时” 这三个指标被放置在监控大盘的概览图表中，旨在帮助用户快速定位到出现积压的函数，解决积压定位难的问题。​

1 分钟定位积压问题

​

在之前的异步调用指标体系下，如果想要定位积压问题，首先需要找到积压函数，此时需要逐个函数查看其函数监控指标详情，定位成功后，也无法直观看到具体的积压量化值。

升级后的异步调用指标体系能够很好地解决积压问题定位难以及积压量化的问题。下面将围绕积压问题的场景，描述如何使用上述指标快速定位积压问题。

业务场景

​

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

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

发现多个服务的异步调用平均处理延时高于预期，同时其异步请求入队数均大于请求处理完成数，表示这些服务都有一定程度异步调用消息积压，且 A-Service 的异步请求入队数量和异步调用请求完成数差别最大，积压最严重，点击 A-Service 查看监控指标：​

可以看到该服务下的函数 A-Function 是积压源，点击 A-Function 查看函数纬度的监控指标：

​

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

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

​

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

问题解决：定位到问题后，小张立刻联系了函数计算团队，基于业务量进行了地域按量实例限制调整。

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

总结

​

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

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