这是搭建前端监控系统的第七章，主要是介绍如何监控前端接口的性能。
本文由；只需要简单几步就可以搭建一套属于自己的前端监控系统，快来试试吧^ _ ^。
图 7-1
众所周知，接口的性能一直都是由后端的小伙伴来监测的，关前端鸟事啊。曾经单纯的我也是这么认为的，随着前端业务日益复杂，前端开始承受着前所未有的重要职责（请允许我往前端脸上贴点金）。因为前端业务变得复杂，所以我们必须开始让前后端分离，前后端小伙伴各司其职，同时也带来了大量的异步接口请求。所以，原本由后端小伙伴监控接口的一部分职责，便落到了我们前端小伙伴的肩膀上了。
为什么这么说呢，请往下看。
图 7-2
后端小伙伴能够监控到的，也就是收到请求后（request）到得到处理结果即将返回（response）前的这一段时间，缺失了浏览器跟网关之间的耗时。而我们前端用户感受到的却是接口总耗时，如果你不做前端接口的监控，那么你将无法得知用户真正的使用体验。
图7-1是我随便找的一个项目截图的，我们可以看到，耗时5-10s的接口虽然只占了0.32%，但是也有1千多次呢，影响用户达到600+，这难道不是前端小伙伴应该关心的体验问题吗？
为什么前端小伙伴应该关心接口性能，我们讲完了，开始进入正题，我们该如何做接口性能的监控。
一、接口耗时分段分析
我将前端接口耗时划分为5个分段：<1秒、1-5秒、5-10秒、10-30秒、>30秒
10秒是用户可忍受等待时间的临界值，如果一个接口超过10秒还在loading，用户极有可能杀掉程序。所以一般情况下，大于10秒的接口都可以认为是超时接口（特殊情况例外）。即使真的有这种情况，也应该让后端小伙伴把这个接口做成异步接口，在10秒内给用户一个反馈。
为什么我要把耗时分段进行分析呢，因为大部分时候，我们最关心就是10-30秒这个段位，大部分超时的接口都会在这里发生。如图7-3所示，出现这种鹤立鸡群的柱子的时候，你就知道接口肯定是出了问题。
图 7-3
每个耗时分段，每天发生的数量都一目了然，你就可以做到心中有数。如果出现大面积的异常接口，这个柱子会变得非常明显。每个分段的占比也需要计算出来，可以按照自定的规则发送报警信息。
二、单个接口分析
很多时候，出现接口问题的肯定某一个接口出现异常，如果是大面积异常，你的电话肯定被老板打爆了，也不需要监控了，哈哈。
那么针对单个接口我们应该分析哪些指标呢？
超时接口数量、单个接口的平均耗时、影响用户数量、发生页面个数、可以准确定位到某个小时和某一分钟发生的情况。
三、分析报警
分析报警可以分为多个指标：
超时接口数量、超时接口占比（百分比），影响用户数量。
好了，关于接口耗时分析相关功能就分析到这里了。耗时分析相关代码可以参考 搭建前端监控系统（四）接口请求监控篇
