大型API网关（六）—— 监控和预警

为什么监控和预警对网关如此重要？

因为网关的流量太大了
对上百万QPS的系统来说，即使故障只持续1分钟，其造成的影响也是巨大的，网关一旦发生故障，都是大事件。所以，必须有完善的监控，才能第一时间发现并处理问题，将损失降到最低。
网关是问题排查的起点
网关是最接近用户的系统，当用户有问题需要排查时，网关是第一个要查的。而且，网关作为流量入口，后面是各个业务线的接口，毫不夸张的说，网关的研发，至少有三分之一的时间被用户和后端服务催着查问题。所以，有一个完善的监控，会大大提高问题排查的效率。
好奇心
没开玩笑，我一直认为，好奇心是作为一个程序员唯二最重要的品质（另一个是责任心），维护这么一个庞然大物，难道你不想知道有多少接口流经网关？峰值QPS是多少？接口延迟如何？反正我是很想知道的。

不止网关，其实监控对每一个在线系统来说都是很重要的，网关尤其明显而已。

监控场景分类

1. 系统监控

监控指标： 磁盘利用率、磁盘IO、网络流量、内存占用、cpu占用、GC情况、QPS、响应时间。
监控目的： 了解系统整体运行情况。
场景举例： 比如发现磁盘占用过大时，可以调整日志留存时间和清理频率。比如发现qps、cpu升高，响应时间变长时，就改考虑增加机器横向扩容了。

2. 业务监控

监控指标： 接口流量、接口rt、接口成功率、错误码、用户流量、用户错误码等。
监控目的： 了解业务层面的数据是否正常。
场景举例： 比如观察到某一接口响应时间变长，可以联系该接口对应的下游服务，看对方是否有变更动作引发问题。

3. 全链路监控

监控指标： 请求的完整链路各个阶段的日志、耗时。
监控目的： 便于排查链路耗时过长的问题。
场景举例： 某用户投诉接口耗时很长，这时就可以根据全链路的日志很方便的看出来问题出在哪里。

监控数据采集、计算、存储

1. 数据采集

监控数据的采集有一个原则：异步采集，不影响业务流程。大多是都是将要采集的数据写到日志中，然后运行一个新的进程（客户端）进行日志解析、上传。上传一般都是批量写入到一个消息队列中，比如kafka。
需要注意的是，这个数据采集客户端不要有很复杂的逻辑，比如复杂的正则表达式提取日志中的一些信息。客户端如果占用系统资源（cpu、内存）过大，会影响正常业务，而且通常这种问题很难排查。
我们之前就遇到过一次系统CPU突然升高，各种查业务代码，啥也查不出来，后来才发现是日志采集配置了新的解析规则，正则表达式比较复杂导致CPU突增。
所以，用户监控的日志尽量要打印的足够规范，且容易解析提取有用字段。
关于数据采集客户端的设计，需要在CPU和带宽之间做一个权衡，如果客户端做的工作很多（解析日志、压缩、本地计算），就会占用机器CPU，从而影响业务。监控系统本来是为了保证业务稳定性而存在的，如果反过来影响了业务的稳定性，那就本末倒置了。当然，如果啥都不做，原样把日志采集上去，就会都传输很多无用的信息，占用带宽。不过一般业务服务之间都是同机房调用，带宽占用的敏感程度远没有CPU那么高。

全链路日志采集

这里着重说一下全链路日志的采集。
全链路日志采集涉及到一个能把整条请求链路串联起来的traceId，这个traceId应该产生于请求发起的地方，通常是客户端，然后一路传递，经过的每个环节（包括中间件）都把这个traceId打印到监控数据中，知道最后返回到客户端。
一般各大公司的中间件都做过改造，以便方便的传递这个traceId，甚至可以做到业务无感知。
拿美团来说，美团所有的通信框架、中间件都做了改造，默认传递这个traceId。traceId产生于客户端的网络库，然后放到http的header里，通过http传递到服务端，服务端之间调用使用的是改造过的Thrift协议，在thrift的schema中第一序号为999的参数用来传递traceId，然后这个服务把traceId放到改造过的kafka的消息头中，通过mq传递到数据处理服务，然后数据处理服务有通过改造过的redis客户端访问了一把redis。一路经过的所有中间件都会把带有traceId的信息（rt、应用名、调用栈等）上传到Cat展示出来。Cat是大众点评开源的十分好用的一套监控系统。
于是乎，在业务程序员毫无感知的情况下，一整条链路已经串联起来了。
当然，我们也可以方便的从框架中取出traceId，自己加一些定制的信息到整个链路中。
忍不住再夸一次美团的基础设施，美团不允许重复造轮子，每种功能的中间件都只有一种，且维护的很好，技术支持响应很快，文档、交互界面都很好。相比而言，阿里就不忍直视了。。。
整个流程示意图如下：

2. 数据计算和存储

但凡数据计算都是有目的的。
同一份数据，可以有多种计算目的，每种目的对应的计算方式和存储方式也是不一样的。
数据查询方式决定了数据的存储结构。

Storing data is normally quite straightforward if you don’t have to worry about how it is going to be queried and accessed; many of the complexities of schema design, indexing, and storage engines are the result of wanting to support certain query and access patterns. For this reason, you gain a lot of flexibility by sepa‐ rating the form in which data is written from the form it is read, and by allowing sev‐ eral different read views. This idea is sometimes known as command query responsibility segregation (CQRS)

关于CQRS可以看这一篇：https://blog.csdn.net/xinzhongtianxia/article/details/86545592
接着说数据计算。
API网关的数据跟交易系统有很大不同，主要有以下几个特点：

API网关的数据通常都是流量数据，且数据之间没有关联关系，一次请求就是一条数据。
数据量巨大，但是数据格式相近，比如同一个接口的不同请求，除了参数值外，其实差别不大。
数据是源源不断产生的，没有尽头。
数据的产生时间很重要，通常需要对一段时间内的数据进行计算。

基于以上特点，可以说API网关的监控数据是流式计算和时序数据库的典型应用场景。
关于流式计算和时序数据库，网上有很多优秀的讲解，Flink、Kafka、Hbase等官网的文档、相关论文等也都十分美好、赏心悦目（hbase不是时序数据库，但可以是时序数据库的底座。。），这里就不啰嗦了。
如果有兴趣，建议还是好好看看Google的BigTable论文和LSM Tree的思想。
数据计算和存储的大致示意图如下：

预警

对在线服务来说，发现故障远比修复故障要重要的多。
对在线服务来说，发现故障远比修复故障要重要的多。
对在线服务来说，发现故障远比修复故障要重要的多。
只有监控是远远不够的，监控更多是对系统当前状态的一种展示，而且通常是在系统发生问题之后才会有人去查看监控，所以，得有一种手段，能及时感知到系统的异常，通知运维、研发人员。毕竟不会有人24小时盯着监控大屏。
系统产生异常的原因各不相同，单一的预警手段是不够用的，必须多种预警手段并存，才能保证系统问题能及时发现。
下面分别举例说明一些必不可少的预警场景。

流量同比、环比

对在线服务来说，同比+环比的监控，是一种比较有效的监控手段。
比如发现流量突然下跌，得赶紧看一下下跌原因，是不是系统出问题了。
比如发现流量突然增长，得看一下系统资源是否够用，需不需要扩容加机器，是不是被人攻击了，是不是有运营活动等等。
同环比通常是具有规律性的，比如对出行业务来说，高峰是每天的早晨7点和晚上6点左右。对基金交易业务来说，高峰就变成下午3点了。
周末、节假日和工作日也有很大不同。
对于整体流量和单个接口的流量来说，周期规律还是很明显且稳定的，同环比比较有效。
但是，对于单个用户的流量来说，同环比没啥用了。因为单个用户的行为是不可预测的，比如发现某用户的流量突然下跌了，这时候是报警还是不报警？
报警吧，多半是因为用户自己的问题，比如用户改用别人家的接口了，或者用户网线被挖掘机挖了等等，多数会误报。
不报警吧，万一是因为网关的bug或者管理员操作失误造成对用户的影响呢？自己发现总比用户投诉过来好一万倍吧。
对单个用户的流量怎样预警，一直是个难题。
一种行之有效的办法是，同时满足以下三个条件才报警：

用户流量大于一定的值，小流量用户监控意义不大，比如是学生注册了账号来学习或者做实验。
正确流量持续下跌超过一定值。
正确流量下跌的同时，错误流量有所增加。

同时触发以上三个条件的场景基本只有下面两种：

用户自身出bug了
网关管理员操作了用户的配置、策略。

对于第一种，可以反馈给用户，也许我们比用户先发现用户自身的问题。
对于第二种，赶紧采取挽救措施。

系统层面的预警

cpu、硬盘、内存、响应时长、FGC、SQL慢查询等，这些所有服务都不可少，不展开了。

接口不间断健康检查

线上接口，可以找一些测试用例，定时触发，看返回结果是否正确。
这种接口请求级别的监控时很有必要且容易被忽略的。
通过这种监控预警，可以发现一些系统的bug，比如某查询接口的返回值和之前不一样了，需要检查数据源是否有问题，接口逻辑是否有问题。通常这种对系统来说，属于”正常“返回，不在预警范围内。毕竟请求正确返回了，没有错误码。
此类错误，如果没有此种监控手段，就只能等用户反馈了才能发现，那发现的就太晚了。

预警通知

最后说一下预警通知。
一般预警系统可选多种通知方式：短信、钉钉、邮件、电话。
对于研发、运维人员来说，短信、钉钉、邮件是轮询，时效性不够高。我们也许十几分钟甚至几小时才会看一下手机。
电话报警是回调，报警了立马就能知道。
但是，电话报警也要慎用，因为报警的有效率是不可能达到100%的。半夜三点睡得正香，一通电话打来，发现是误报，那感觉真是。。。。

那么，接到报警之后，该怎么办呢？且看下一篇：《大型API网关（七）—— 紧急预案》