apm监控得有多少细节啊🤔

2023年 7月 15日 23.5k 0

前言

image.png

被掘金的运营小姐姐吐槽写了很多非技术内容,哈哈,今天正经一回梳理一下apm监控里面有多少细节,当聊起apm自研算很经典,一般公司都会去自研apm,它还是相对比较简单,但是里面蕴藏了蛮多细节,而往往这些细节决定着这个系统的性能、稳定性。

接下来一起梳理一下apm都有哪些细节吧~

apm结构图

image.png

容我偷个懒,基本架构就是如图所示。

生产日志过程:从左到右,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呢?当然不是,如果超过一定长度,需要截断,这是对中间件的保护,占用太多空间了不好,而且很多数据都是没有什么用的,打印那么多干嘛对吧~

apm需要考虑什么

1、 性能

这个是不用讲的,kafka性能、es性能能否撑住这么大体量大的日志体系,这也需要压测,然后评估个2-3倍的量,kafka几个分区、几个消费者、apm服务几个节点。

2、内存

apm一天打满日志占多少g,因为很多中间件是买的,自己搭建很难有那个性能的,也耗费精力,那么买的时候要多少内存鸭?日志一直保存还是有过期机制对不对。

最后分享下最近的美景

image.png

希望我的文章对各位读者有所启发,谢谢观看~

相关文章

JavaScript2024新功能:Object.groupBy、正则表达式v标志
PHP trim 函数对多字节字符的使用和限制
新函数 json_validate() 、randomizer 类扩展…20 个PHP 8.3 新特性全面解析
使用HTMX为WordPress增效:如何在不使用复杂框架的情况下增强平台功能
为React 19做准备:WordPress 6.6用户指南
如何删除WordPress中的所有评论

发布评论