前言
在上一篇博主写了关于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变慢了，也可能是网络波动，这还需要加上中间件的埋点，即使他啥都不知道里面的细节，也可以快速的定位问题。
比如一个新手接手项目，如果优化项目呢，这些可能导致项目慢的地方就是很好的优化的地方了
