前言
被的运营小姐姐吐槽写了许多非技术内容，哈哈，今天正经一回梳理一下apm监控里边有多少细节，当聊起apm自研算很经典，一般公司都会去自研apm，它还是相对比较简单，但是里边蕴藏了蛮多细节，而往往这些细节决定着这个体系的功能、稳定性。
接下来一起梳理一下apm都有哪些细节吧~
apm结构图
容我偷个懒，基本架构就是如图所示。
出产日志进程：从左到右，apm面向对象是服务节点、网关、中心件。
收集日志进程：在每一步都需求做对应操作处理，比方说带上traceid、spanid、parentid、时间、来历、类型对吧，通过logback配置丢到中心的话是kafka，由于人家快呀，比方说咱们有多套环境，3套甚至更多套环境一个apm，那么这个日志量是惊人的，并且出产速度也是极快的，比方某些新手上路写了死循环一直打印日志，很简单把日志堆满对吧。
解析、储存、剖析日志进程：日志许多，那么它需求进行分类，然后储存起来，至于剖析能够用离线方式，比方服务反常状况、用户上报数据。
apm日志类型
- 运行日志
一般使用都会打印日志，比方恳求参数、呼应参数、反常仓库，意图是为了便利排查问题。
- 链路日志
意图是什么呢？让整个恳求链路明晰，比方说我想去广州珠江新城，从某某点动身，然后通过哪些地铁站，出了哪个口，坐了什么公交车，通过几分钟，到达意图地。这是第一步对链路明晰收集、展示，第二步，对链路优化，比方说整条链路合不合理？有时一个数据绕来绕去，是不是应该合并一下，或许最初规划不妥当；别的mysql执行比较慢优化一下，接口恳求慢，使用呼应正常的，是不是网络波动，假如没有链路无从下手～
- 发动日志
当然这个是附加的东西，比方说使用接口状况，哪些接口下线了，跟咱们自动化测验结合起来，接口下线需求重写，或许参数变了需求预警，也是流量录制根底，接口的数据类型、返回数据类型、参数个数等等。
- 恳求日志
这个是为了剖析接口的状况，当然了你能够用运行日志或许链路日志来代替，但是在我反复思考中，应该把它拆出来，功用愈加的明晰。
剖析什么呢，接口反常状况，当时节点qps、每天恳求数量、接口慢状况，使用全体状况，为后边的预警打好根底。
apm细节
1、行列操控中心件刺进速度，也是在维护对应中心件
在kafka->apm->es中心，加了一层缓存，用的是行列，由于kafka消费速度跟es刺进速度不是对等，需求再搞一层缓冲，一开始有的同学规划是运行日志放行列缓存，其他日志直接塞es，由于运行日志是一个占大头的日志类型。
我做了一层优化，讲4种日志悉数放在行列里边，由于假如许多地方调用es，那么你无法约束es刺进速率的对吧，所以咱们都过来行列里边，统一消费，我是怎样规划的呢？
参阅rpc、xxl-job相关规划，快慢行列，这个规划他们初衷是当接口快速呼应的时分，应该往快行列寄存，让机器功能给它，然后慢行列给少点资源，这样整个节点吞吐量、处理状况会比较好。
伪代码
两个堵塞行列，命名为快行列、慢行列，快行列存链路日志、运行日志，慢行列存那些用户数据上报、发动日志这些扩展性日志，取的时分按6:4，比方说es每次刺进数量量500，快行列拿300个，慢行列取出200个，这就是500个。
假如快行列只有200个，那么300-200=100，意味着慢行列取出200+100=300，给慢行列提个速。
2、监控
一谈到行列，就会有功能问题，比方说行列满了怎样办，丢掉吗，其实它需求一个监控来告知你我当时的规划合不合理，而不是自己yy，定期打印行列中心数据，反常状况进行预警。当然也能智能调理数据在合理的规模，引出下一点，比方说每次刺进500，这个值合不合理呢？
3、动态调整消费速率
我搞了一个滑动窗口相似的，计算日志出产速率，假如10秒里边出产速率进步了，那么我消费的速度也要加一加对吧，假如低了能够缓一缓。然后它能够无限进步吗，相同也会影响中心件功能，所以我给它定了200-800之间的滑动。
4、链路日志没有起到作用
我敏锐的发现咱们开发同学平时用运行日志占绝大多数，由于要扫除反常，链路日志如同就没没有卵用了。我一想问题在哪里呢？这就需求回到链路日志最初的规划初衷，链路明晰、功能优化。
咱们的apm目前只是完成了像http、rpc恳求的链路，大致上能够摸清，像mysql其实是另一个大头，包含慢查询的根据、代码优化都需求借助链路日志，所以我抽暇将mysql的链路日志：恳求的sql、参数、呼应的数据打印出来。
5、细节中细节
是不是什么东西照打到apm呢？当然不是，假如超过必定长度，需求截断，这是对中心件的维护，占用太多空间了欠好，并且许多数据都是没有什么用的，打印那么多干嘛对吧～
6、链路规划
这是后边补到一点，信任咱们对apm链路规划蛮了解的吧，
看下以下这幅图，懒得美化了徒手咔咔画出来了。
惯例规划左面这样对吧，跟咱们文章子目录相同，一个大点一个小点，这样比较明晰的，链路也是有两条1->2->2.1,2.1代表在2这个节点里边分操作，而不是跳到另一个服务，那么在咱们自研apm中不是这样规划的，一起也给我挖了个坑，由于前面提到我后边补了个mysql链路日志。
怎样规划的呢？右边这样，相当于每个操作都是一个新的节点，不管你是张三李四，来了咔咔给你一个新的标识，其实也能够整一个链路，1->2->3，然后带上对应的类型，比方说这是mysql操作，还有feign操作，链路还是能串联起来的，至于怎样看出是哪一层的？
只能这个节点往上找，假如是使用级别打印出来的，那就归属这一层的。
apm需求考虑什么
1、 功能
这个是不必讲的，kafka功能、es功能能否撑住这么大体量大的日志体系，这也需求压测，然后评价个2-3倍的量，kafka几个分区、几个顾客、apm服务几个节点。
2、内存
apm一天打满日志占多少g，由于许多中心件是买的，自己搭建很难有那个功能的，也耗费精力，那么买的时分要多少内存鸭？日志一直保存还是有过期机制对不对。
最后共享下最近的美景
希望我的文章对各位读者有所启示，谢谢观看～
