关于 API 监控的实践分析

前言

今天我们来浅聊一下 API 接口的运行监控。

在企业开发中经常会经历 SOA 架构及 ESB 集成，类似于这类较大的项目，在开发中实际会接触上千个接口，每天的接口调用量都很高，最高峰可以达到三四千万次。随项目的体量增大，开发过程中接口的运行监控、性能分析、报警预警、限流这一系列措施就变的相当重要。

在微服务框架里经常会用到 API 网关，可以把它理解成是一个轻量的 ESB 总线，其中涉及到的接口的统一监控、报警预警思路，实际上和传统的 ESB 总线是一样的。API 监控运行分析作为微服务治理里重要内容，在实际开发中是必不可少的，所以接下来我会从三个方面向大家讲解 API 接口的运行监控。

API 监控

实例监控

API 实例监控就是通过对接口调用产生的调用日志（即接口运行实例）进行完整监控。通过监控我们能了解到：

谁对 API 进行了调用
调用了什么业务系统
调用者客户端的 IP
调用时间和整体耗时
调用整体消息的输入报文及数据量

这些是接口日志监控的重要内容，每次接口运行都需要记录，方便后续在运行故障的时候进行相关的问题排查和操作。

异常监控

除了 API 实例日志，还有一类叫异常日志，任何接口在调用时都可能出现异常：

业务异常。当接口由于输入字段的业务校验无法通过时就可能会抛出相关的异常日志；
系统级别异常。比如说系统层抛出了一个 Exception，对于系统级异常，可分为两类：
接入到 API 网关的接口原始业务系统提供方出现了异常；
API 网关出现内存溢出或宕机，导致接口异常。

资源监控

在开发中需要对整个 API 网关或总线本身的中间件资源做监控。

对于大型企业，本身已具有 IT 运维系统和 IT 资源管理系统去做监控，不需要用到服务器的 CPU 内存。而一般我们指的监控，更多偏向中间件和关键性能指标,，类似于线程数和 JVM 内存的使用率。对于这些需要做重点的实时监控或者心跳监控。

举个简单的例子：当一个接口出现大报文调用时，如果调用时间较长，会导致 JVM 内存持续上升，最终引起内存溢出，使整个集群宕机。所以需要实时监控线程数，线程排队的情况，以及 JVM 内存利用率的情况。

API 运行的统计分析

记录接口的运行日志，就有对应的运行时间、运行次数、运行是否成功、调用报文量等，通过这些基准数据，我们就可以基于两个维度，去做统计分析。

时间周期维度

时间周期的维度就是按天按周按月去做统计：

组织业务系统维度

按照组织和业务系统的维度去分析：

当然也可以对任何指标本身进行分析，如接口调用的时长。

API 的监控告警和限流熔断

监控告警

接口告警预警他需要去监控 KPI 指标，通过统计确认单位时间是否触发设定的监控阀值，及时进行告警预警。假设设定的监控周期单位时间是 5 分钟，如果某个服务在单位的 5分钟里平均调用时间都超过了 10 秒，而平时只需要 2 秒，那么就需要做监控报警。

限流熔断

通过自动化操作与限流熔断结合，当触发了监控告警条件时，由系统自动将某消费方访问接口的权限熔断掉，使其无法响应；或当这个服务本身出现问题时，为了防止服务调用产生雪崩效应，直接把整个服务先熔断掉，避免损失。依靠系统自动化去处理就无需人为操作了。

两种监控方案

实时心跳： 监控告警和限流熔断的核心都是基于单位时间及核心 KPI 指标的统计计量。这类似于接口服务的实时心跳，基于滚动窗口的时间周期，针对最近的一分钟，监控服务调用并发量、平均时长、和报文数据量，检测是否超过预定阀值，判断是否告警和触发限流熔断。但这种方案无法及时产生接口日志，只能在最终落地到数据库后，通过 SQL 语句查数据库，然后再进行统计，达不到对应的时效指标。
流批一体： 由于实时心跳存有缺陷，可以考虑更好的方案。借鉴大数据采集和处理里经常谈到的概念「流批一体」，即当每次接口日志进到消息中间件后，在其后跟一个流处理组件，该组件按照预定的监控周期时间的计算规则，在内存里面对实例日志实时进行统计和分析，并在滚动计算完成后，检测是否达到实时监控和心跳监控要求并进一步朝下流动，最终把每个实例日志存储到数据库里。这样既能满足实时性能监控的要求，又能满足后续实例日志的统计分析。

实践经验

在接口的实际运行监控中，有些点是必须要注意的。根据我做项目的实践经验来说几个典型：

毛刺现象

统计分析一定要考虑一种情况——毛刺现象。

举个简单的例子，有 A 和 B 两个服务，它们的平均调用时长都是 30 秒，但服务 A 基本上是围绕 30 秒左右展开正态分布，所有的服务调用时间都很长；而服务 B 的 70% 或 80% 的服务调用时间其实只有 2 秒，因为个别服务的调用花费了 5 分钟或是更长时间完成导致整个平均时间也是 30 秒。但我后面去分析，这种情况一周或者一天就调用了那么几次，调用时长较长的原因可能是较长周期的大数据量查询，且多为晚上调用，对平台没什么影响。所以这两种情况是截然不同的，对应后续的处理手段要进行区分。

数据分布

监控到的不论是时长还是报文量，一定要做相应的数据分布统计。正常来说，调用量、调用平均时长及报文量，围绕平均值展开都应该是正态分布，但是实际上不一定符合，多少会偏向左右，甚至同时出现左右两个中心点。对于这些非理想状态都需要去做分析。我之前遇见过数据分布出来以后有两个中心点，排查是由于业务系统在调用时经常用到某条查询条件引起了长耗时和长数据量。只有分析到这个时候，才清楚需要针对这种特例情况，如何做进一步处理或控制。

写在最后

总而言之，接口的运行统计是很系统的工程，不仅涉及到接口本身的调用日志、实时的心跳资源监控统计分析，还包括异常情况的分析处理，甚至涉及自动化运维、限流熔断等情况，这些都需要根据实际项目去做对应分析，但都是为了保证整个 ESB 平台，或者是说 API 网关的健康运行。毕竟如果总线宕机了，所有接口服务的运行将全部都要受影响。所以一致原则都是通过 API 接口的运行监控，宁愿牺牲某一个服务，也要确保网关的正常。