监控容器的状态的规则书写 监控形状_接口超时后程序还会继续执行嘛


这张图片是真的帅气,好像跟我这篇介绍没太大关系,哈哈。这是搭建前端监控系统的第七章,主要是介绍如何监控前端接口的性能。

本文由 www.webfunny.cn 前端监控提供;只需要简单几步就可以搭建一套属于自己的前端监控系统,快来试试吧 ^ _ ^。


监控容器的状态的规则书写 监控形状_接口超时后程序还会继续执行嘛_02

图6-1 接口性能概览


众所周知,接口的性能一直都是由后端的小伙伴来监测的,关前端鸟事啊。曾经单纯的我也是这么认为的,随着前端业务日益复杂,前端开始承受着前所未有的重要职责(请允许我往前端脸上贴点金)。因为前端业务变得复杂,所以我们必须开始让前后端分离,前后端小伙伴各司其职,同时也带来了大量的异步接口请求。所以,原本由后端小伙伴监控接口的一部分职责,便落到了我们前端小伙伴的肩膀上了。

为什么这么说呢,请往下看。


监控容器的状态的规则书写 监控形状_前端图片做成其他不规则性质_03

图6-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所示,出现这种鹤立鸡群的柱子的时候,你就知道接口肯定是出了问题。


监控容器的状态的规则书写 监控形状_接口超时后程序还会继续执行嘛_04

图6-3 不同耗时分段接口数量分析

每个耗时分段,每天发生的数量都一目了然,你就可以做到心中有数。如果出现大面积的异常接口,这个柱子会变得非常明显。每个分段的占比也需要计算出来,可以按照自定的规则发送报警信息。

二、单个接口分析

很多时候,出现接口问题的肯定某一个接口出现异常,如果是大面积异常,你的电话肯定被老板打爆了,也不需要监控了,哈哈。

那么针对单个接口我们应该分析哪些指标呢?

超时接口数量、单个接口的平均耗时、影响用户数量、发生页面个数、可以准确定位到某个小时和某一分钟发生的情况。


监控容器的状态的规则书写 监控形状_监控系统_05


三、分析报警

分析报警可以分为多个指标:

超时接口数量、超时接口占比(百分比),影响用户数量。

结语:随着工作的不断深入,前端小伙伴应该走出舒适圈,关注更多维度的指标,不能再局限在狭义的前端后端了。