apm 请求“异常”分析

---

theme: cyanosis

# 前言

在上一篇博主写了关于apm的规划， 二谈apm规划，里面提到异常分析，我们当前apm只是做了最基本的日志查询功能，还没将价值最大化。

异常分析的作用，比如说项目通宵上完线，开发下班之后第二天，一堆异常、接口很慢，用户一直在投诉，这时压力给到了运维同学、产研同学，但是它们都不知道哪个地方出现问题，所以快速定位问题是比较重要的；再如一个新手接了一个很多问题的项目，线上出现问题了，某个app用户说卡顿，我们从哪里入手呢？不可能让客户复制个curl吧，这时可能需要客户端的用户埋点分析，再结合服务端请求“异常”分析定位到问题。

今天我们要讲的是请求“异常”分析，为什么带引号，因为它不是真正的业务异常、系统异常，而是接口变慢了。

# 请求“异常”

我们来想想它有哪些情况导致接口变慢呢？

1、大量的请求，一下子把节点的资源打满了

2、某个关键地方共用了，阻塞了

3、数据库慢查询、某个中间件的网络波动

4、垃圾代码对吧，明明可以批量更新，非要一个一个处理

里面涉及到几个，外部情况、代码情况、中间件情况，我们都需要对它进行埋点分析。

# 思路

思路：先找到异常的服务请求时间节点，然后通过链路日志进行分析，它不可能只分析它本身的日志，它不是孤零零一个节点没有依赖的对吧，所以需要通过链路日志来分析，然后对链路日志进行分组统计，比如说这是http请求，feign请求、mysql、redis、mq、外部请求，这属于细化，找到具体卡顿的地方。

我们可以看到粒度从应用到代码、接口、中间件的定位思路，我们再从这些点来细聊。

请求异常时间点

在apm里面会记录每次请求点时间对吧，我们需要进行统计，可以是一分钟统计一次按照 服务 为粒度的平均请求时间，因为在线上出问题的时候，都是一瞬间的事，所以这个粒度比较小的，然后对这些统计的平均请求时间点进行分析出异常的节点。

一开始，我是采用数组里面最大/最小，如果超过3倍就意味异常点，这可能存在有时流量刚好到那些请求时间短点接口，这是比较有误差的，后来我改为线性回归的算法，也就是预测下一个请求时间点，如果下一次请求比这个预测值大3倍，那么它不是在我们预测区域内对吧。

为啥定这个3倍的节点？

正常来讲，接口请求的波动还是有的，一旦有大的异常、问题，整个请求时间会直线上升，所以那些才是我们需要注意的点，这个是异常时间点的定位

思考的点🤔

1、如果服务刚刚起来那瞬间，也会出现异常点对吧，我们需要进行降噪，避免跟真正的异常点混淆

2、晚上一般定时器比较多的，也会导致服务比较慢，接口慢点原因，它的影响因素占到比例是怎样的，才能让人更清晰的知道情况

分析链路日志

有了这个异常时间点，比如说中午12:00，那么我们需要分析整体的链路日志，比如说网关，它后面很多应用了，究竟是哪个垃圾拉胯了整体对吧哈哈，揪出来。

我的想法是在这个异常节点，前后5分钟的日志搂出来分析，因为有些接口请求那么几次，如果时间跨度不大很难分析出什么问题，这就意味着我们需要等到下一次扫描的时候，到这个后5分钟再去分析这个链路日志。

怎么分析法？同样还是统计，比如http请求、mysql请求，然后按组去分析它的平均请求时间是不是变慢了，这个粒度需要掂量的，http请求是哪个第三方请求变慢啦？还是说哪个代码变慢了？看具体的要求进行链路日志的提前埋点。

统计页面

我们通过环境、服务、时间来展现，然后通过平均请求时间看出异常，下面会带上应用相关的拓扑图，让我们更好的理解究竟他们的依赖关系，最后是给出可能引发接口慢点因素，具体细化到哪个层次，这个具体再琢磨。

当然这里面的细化还需要加上比例，比如上面讲的定时器的问题，本身定时器就比正常请求慢，如果它的比例比较大，那么我们认为慢是正常的，所以加上导致因素的比例会更好。

# 应用

比如说一个运维同学接到线上异常情况，点开环境、服务，大概瞄一眼，比如说mysql变慢了，也可能是网络波动，这还需要加上中间件的埋点，即使他啥都不知道里面的细节，也可以快速的定位问题。

比如一个新手接手项目，如果优化项目呢，这些可能导致项目慢的地方就是很好的优化的地方了