简介：本文分为三个局部：概述中引入了积压问题，并介绍了函数计算异步调用根本链路；并在指标介绍局部具体介绍了指标查看形式，分类解读了不同的指标含意；最初以一个常见的异步申请积压场景为例，介绍如何在 1 分钟内疾速定位积压问题。
作者 | 千风
本文分为三个局部：概述中引入了积压问题，并介绍了函数计算异步调用根本链路；并在指标介绍局部具体介绍了指标查看形式，分类解读了不同的指标含意；最初以一个常见的异步申请积压场景为例，介绍如何在 1 分钟内疾速定位积压问题。
为异步调用保驾护航
应用函数计算异步调用的开发者最关怀的问题是：调用申请是否在预期的工夫内被解决实现。若没能解决实现，那么在客户眼中就是异步调用申请积压了，然而基于之前函数计算异步调用指标体系，无论是定位积压，还是查看积压，过程都是非常繁琐的。
针对以上问题，函数计算推出了一系列异步调用申请积压相干的指标，可能帮忙用户疾速定位申请积压，向用户展现积压量化值。本文将具体介绍如何通过这些监控指标疾速定位到函数异步调用呈现的积压问题，为各位开发者解说降级后的异步调用指标体系。
在开始之前，先简略介绍下函数计算异步调用。
异步调用是函数计算调用函数的一种形式，通过异步调用你不仅能够确保函数会至多执行一次，还能够保留调用执行过程中的状态转换信息和执行后果，其调用链路如下所示：
用户 / 事件源发动异步调用申请后会立即返回本次申请 ID，随后函数计算零碎将本次调用的相干信息转换为音讯的格局，放入 MNS 音讯队队列中供零碎内上游模块生产，上游模块会基于解析进去的调用音讯进行函数调用。
调用实现后，如果函数配置了 Destination，则零碎会基于调用后果以及 Destination 内容进行进一步解决，Destination 相干内容介绍请参考异步调用文档：
https://help.aliyun.com/docum…
指标降级
降级后的函数计算异步调用链路监控指标次要新增了如下几类：
上面咱们将对上述指标进行具体解读。1 指标查看
目前能够通过函数计算控制台或者 Serverless Devs 工具这两种形式查看函数的监控指标大盘，上面咱们将以控制台为例，领导大家如何查看异步调用链路相干的监控指标，基于 Serverless Devs 的查看形式能够参考：
https://github.com/devsapp/fc…
上面介绍的步骤前提是已开明了函数计算服务；且胜利创立了服务以及函数，如果还未进行这些操作，请参考应用控制台创立函数：
https://help.aliyun.com/docum…
首先关上函数计算控制台，点击左侧监控大盘标签，滑倒底部，能够查看到该地区所有服务的异步调用解决状况以及异步音讯解决均匀延时概览表格：
此时咱们点击任意一个服务名称，进入后，能够看到该服务下所有函数的异步调用解决状况；以及异步音讯解决均匀延时概览表格：
接下来咱们点击任意一个函数名称，进入后能够看到所有函数纬度的监控指标，并以图的模式展现：
至此，咱们曾经学会了这些指标的查看路径。上面持续为各位开发者介绍解读上述异步链路相干指标。
指标解读
咱们将依据不同的指标类型对监控指标进行分类解读。1 异步调用解决状况
- 异步申请入队
异步调用中，达到函数计算的申请数，当入队申请数大于申请解决实现数时，示意有申请积压，函数解决异步申请的速度小于异步申请发动的速度。请调整函数弹性伸缩（含预留资源）下限，参考：
https://help.aliyun.com/docum…
或可钉钉搜寻退出阿里函数计算官网客户群（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 的异步调用申请进行隔离，防止对其余函数的影响。
总结
降级后的函数计算异步调用监控指标体系可能帮忙用户解决积压问题定位难以及积压量化等问题，联合云监控报警的设置，极大进步了函数计算异步调用利用的稳定性。
同时，为了尽量避免申请积压状况的产生，咱们目前正在对函数计算异步解决零碎层面进行优化，包含队列回收机制、独享队列能力以及积压音讯重定向策略等，从而进步函数计算零碎解决异步调用申请的能力。这样，通过弱小的异步调用申请解决零碎以及全面的监控指标体系，为函数计算异步调用保驾护航。
原文链接
本文为阿里云原创内容，未经容许不得转载。