【API生命周期看护】API监控与运维

一、基本概念

当接口完成发布、上线后，就进入了正常的运行与维护状态。此时，对于API本身的监控与运维则变得尤为重要，这是保障服务功能可用、SLA达成的重要手段。

监控与运维本身是一个非常大的概念，从DevOps这一词汇中也能看出：Ops也即Operation（运维），各类方法也层出不穷。这里我们仅针对接口层面的需求，简单阐述一下笔者所了解的API监控与运维。

二、关于API监控与运维

首先需要说明的是，监控运维本质上是一体的，或者说监控属于运维的一个环节，二者确切的说并不是一个并列的关系。不过为了方便记录与理解，笔者这里就直接将一些常见的概念进行罗列阐述。

1、接口可用性

所谓接口可用性概念，其实就是字面意思：服务对外提供的接口是否可访问、是否能满足功能需求、是否能达成SLA（服务等级协议）。而这其中，我们又可以通过接口快速探测、调用成功率、TP99等手段来进行可用性检查与度量。

（1）快速探测

快速探测是一种简单直接但较为有效的判断，在各个云服务厂商中也都有提供这种类型的服务。通过配置相关访问地址的方法，快速、高频、定时地发起HTTP请求，并根据状态码的返回值来判断接口是否可用。

（2）调用成功率

接口调用成功率也是一个经常会使用到的指标概念。一般而言，我们会将接口访问返回状态码为5xx（500、502、504等）的情况认为失败的访问情况，并且这类失败是由服务端所引起的，而调用成功率指的就是调用成功的次数占总调用次数的比例。这部分调用失败的数据既可以从调用链来统计，也可以从网关调用日志来收集。
根据SLA的要求，我们一般会有所谓的“三个9、四个9”的说法，也即调用成功率需要达到99.99%的水平，具体要求则是根据SLA来判断的。

（3）TP99达标率

TP=Top Percentile，指在一个时间段内，统计该方法每次调用所消耗的时间，并将这些时间按从小到大的顺序进行排序，并取出结果为 ： 总次数 * 指标数 = 对应TP指标的值， 再取出排序好的对应位置时间。
TP99就是满足99%的网络请求所需要的最低耗时，假如TP99=3s，那么就意味着99%的请求耗时都在3s以内，服务达成该TP99要求的接口占比也即TP99达标率，用来衡量服务接口的性能水准。
同理，TP后面可以按照SLA标准带有各种数字：TP50、TP90、TP999等。

2、日志监控

在监控手段中，还可以使用日志记录与统计搜索的方法来实现接口的监控。
当前云服务厂商都有相关的云日志服务，以及基于类似ElasticSearch之类的海量数据快速查询手段。对于服务而言，可以利用一些规范化日志输出的方法，将服务对外访问请求，以及接收到的相关请求都输出、存储在日志流中。
而后，利用日志流服务的日志查询与关键字告警能相关能力，我们便能够实现基于特定关键字异常的接口监控与告警。

3、调用链监控

APM（Application Performance Management）监控，同样是各大云服务厂商对外提供的监控运维工具之一，服务通过安装Agent，自动完成服务间调用情况数据采集与分析。基于这些采集数据，我们可以有针对性的进行接口维度的监控告警。

（1）调用状态码监控

基于调用接口状态码的统计，我们能够针对5xx类型的类型进行有针对性地采集、监控，由于5xx类型的状态码反应了服务本身的不可用的问题状况，因此即时的状态码检查与告警能够快速发现现网故障。

（2）接口访问性能恶化监控

接口的访问性能恶化是一个较为复杂的问题：一方面，这种问题并不能用简单的接口响应时长阈值来判断，另一方面，接口的恶化速度是非常明显且快速的，很多时候很难快速去发现问题。

因此，针对这一问题，我们通过对接口响应时长的变化情况来判断：

• 当服务接口的响应时长持续增长并超过该接口平均响应时长某个百分比、或者接口响应时长增长速度超过某个限度时，我们会认定服务接口存在性能恶化问题，并进行相关告警；
• 同时，我们还会根据历史与周期性情况来做具体问题、具体分析，很多情况下服务接口由于业务需求（例如批量查询、定期更新等）接口会有一定程度的响应恶化，但这种情况下我们认为是正常的。只有未在预期情况下的接口响应时间突然变慢才会实际影响服务本身。

（3）慢SQL监控

慢SQL对应的是对数据库操作时耗费大量时间与性能开销的SQL语句，其在一定程度上也代表接口在接受访问进行数据库交互时的相关性能问题。

我们都明白，每当服务与数据库通过SQL进行交互时，都会与RDS建立连接，而连接池提供的连接数量本身也是有限的，因此慢SQL不经会在很大程度上耗费服务本身与RDS的相关性能，同时也会由于连接池占满而导致挤占其他正常业务的SQL交互。

而在识别这类问题时，虽然APM能够记录所有的SQL语句交互操作、以及对应的响应时间，但我们不能仅仅通过响应时长的阈值来做问题拦截，因为服务确实存在一些由于实际业务需要而响应较慢的SQL，这里我们需要结合连接池的具体情况来判断：

• 如果服务存在响应时长错过某个限定阈值的SQL、同时连接池出现占满异常，那么我们就可以认为此时服务出现了慢SQL并影响了服务，需要尽快关注该问题。

三、评估方法

在评估方面，各类监控项是非常多的，这里我们简单提及一些使用频率较高的：

1、拨测成功率

针对服务的对外暴露接口，以及基于接口进行撰写的相关测试用例，我们会通过定时任务的方法来进行相关测试，并计算具体某段时间内的拨测成功率，同时拨测的成功率在一定程度上也可以代表当前服务的SLI水平。

2、调用成功率

接口调用成功率正如前文说说，我们通过对5xx状态码的统计与占比计算，来衡量具体服务的接口调用成功率。
这里的接口调用我们一般使用现网用户实际使用的日志信息，用以衡量服务对外提供接口的质量水平。

3、TP99

同样的，如TP99是从性能的维度来衡量服务对外提供接口的水准。

4、Apdex

Apdex全称是Application Performance Index，是由Apdex联盟开发的用于评估应用性能的工业标准。Apdex标准从用户的角度出发，将对应用响应时间的表现，转为用户对于应用性能的可量化范围为0-1的满意度评价。

根据应用性能评估确定应用响应时间的最优门槛为Apdex阈值，然后根据应用实际响应时间结合Apdex阈值定义了三种不同的性能表现：

• Satisfied（满意）：应用响应时间低于或等于Apdex阈值。比如Apdex阈值为1.5s，则一个耗时1s的响应结果则可以认为是满意的。
• Tolerating（可容忍）：应用响应时间大于Apdex阈值，但同时小于或等于4倍的Apdex阈值。假设应用设定的Apdex阈值为1s，则4*1=4s为应用响应时间的容忍上限。
• Frustrated（烦躁期）：应用响应时间大于4倍的Apdex阈值。

APM中，Apdex阈值即自定义阈值中设置的阈值，应用响应时延即服务时延，Apdex取值范围为0～1，计算公式如下：

Apdex=（满意样本 * 1 + 可容忍样本 * 0.5 + 令人沮丧样本 * 0）/ 样本总数

其计算结果表示应用的不同性能状态，即用户对应用的体验结果，采用不同的颜色表示：

Apdex值	颜色	说明
0.75 ≤ Apdex ≤ 1	绿色	表示应用、实例或事务被调用时响应很快，用户体验较满意。
0.3 ≤ Apdex < 0.75	黄色	表示应用、实例或事务被调用时响应较慢，用户体验一般。
0 ≤ Apdex < 0.3	红色	表示应用、实例或事务被调用时响应极慢，用户体验较差。
–	黑色	表示没有调用应用、实例或者事务。

5、慢SQL个数

如上文说提到的满SQL监控，我们同样会对服务接口在被调用时、执行响应时长超过某个时间阈值的相关SQL进行检查、知会。

一般而言，我们不希望服务存在慢SQL。

四、小结

API作为对外暴露的能力出口，是一个服务、乃至整体产品的“门面”，对于其质量的把控是至关重要的，而这其中，监控与运维是我们提前发现、拦截问题并持续改进的重要手段。这其中手段还有非常多，是DevOps中的Ops的关键组成部分，后续会单独再做详细探讨。