前端,笔者在使用Jaeger进行Trace监控的时候,当数据量增大到一定数量级时,出现了一次CPU暴增导致节点服务器挂了的经典案例,这里对案例进行一个简单的抽象,供大家参考:
首先通过pprof对耗时的函数进行定位:
发现是在Trace初始化的调用了HostIP方法特别耗时
然后看了下函数的实现:
找到了问题的疑似点:net.InterFaces
这个方式会调用底层的系统函数获取本机的IP,会打开一个socket,会不会因为大量打开socket,把CPU占满了呢?
做个实验:
把这个方法抽离出来,在服务器上做个高频调用!
日志如下:
cpu如下:
果然是它!确实在hostIP这里耗时
那看实锤了,就是因为每次数据上报都会一个协程来出来,协程中会新建一个jaeger trace来跟踪,jaeger每次都找一下本机IP,然后打开了很多的socket,然后机器CPU飙升,出现了Node的问题
那看看jaeger为啥会有这个问题
跟踪一下git上的提交记录:
啊,原来jaeger在某个版本已经修复了!把之前获取的IP放在内存里,下次就不再重复获取了!
难道有项目遇到了这个问题了?
看看commit
是在修复401问题,看下401问题是啥?
原来是另一个问题,这个HostIP其实有一个scoreAddr方法,当一个服务器有两个ip,比如内网ip和外网ip,按照这个方法的逻辑,会优先外网ip,但一个集群内,可能只有一个入口有外网ip,其他都是内网ip,这个时候入口机的ip和内网ip就适配了,jaeger信息也会异常,所以提出了这个问题,并进行修复
我们看看jaeger开发者这么说
原来开发者一直也是这个理念,而且在java的客户端已经实现了,但golang一直没有更新
额,原来大家都有拖延症!文章来源:https://www.toymoban.com/news/detail-687271.html
搞定!文章来源地址https://www.toymoban.com/news/detail-687271.html
到了这里,关于Jaeger的经典BUG的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!