Jaeger的经典BUG原创

前端,笔者在使用Jaeger进行Trace监控的时候,当数据量增大到一定数量级时,出现了一次CPU暴增导致节点服务器挂了的经典案例,这里对案例进行一个简单的抽象,供大家参考:

首先通过pprof对耗时的函数进行定位:

Jaeger的经典BUG原创_第1张图片

发现是在Trace初始化的调用了HostIP方法特别耗时

然后看了下函数的实现:

Jaeger的经典BUG原创_第2张图片

找到了问题的疑似点:net.InterFaces

这个方式会调用底层的系统函数获取本机的IP,会打开一个socket,会不会因为大量打开socket,把CPU占满了呢?

做个实验:

把这个方法抽离出来,在服务器上做个高频调用!

Jaeger的经典BUG原创_第3张图片

日志如下:

cpu如下:

Jaeger的经典BUG原创_第4张图片

果然是它!确实在hostIP这里耗时

那看实锤了,就是因为每次数据上报都会一个协程来出来,协程中会新建一个jaeger trace来跟踪,jaeger每次都找一下本机IP,然后打开了很多的socket,然后机器CPU飙升,出现了Node的问题

那看看jaeger为啥会有这个问题

跟踪一下git上的提交记录:

啊,原来jaeger在某个版本已经修复了!把之前获取的IP放在内存里,下次就不再重复获取了!

Jaeger的经典BUG原创_第5张图片

难道有项目遇到了这个问题了?

看看commit

Jaeger的经典BUG原创_第6张图片

是在修复401问题,看下401问题是啥?

Jaeger的经典BUG原创_第7张图片

原来是另一个问题,这个HostIP其实有一个scoreAddr方法,当一个服务器有两个ip,比如内网ip和外网ip,按照这个方法的逻辑,会优先外网ip,但一个集群内,可能只有一个入口有外网ip,其他都是内网ip,这个时候入口机的ip和内网ip就适配了,jaeger信息也会异常,所以提出了这个问题,并进行修复

Jaeger的经典BUG原创_第8张图片

我们看看jaeger开发者这么说

Jaeger的经典BUG原创_第9张图片

Jaeger的经典BUG原创_第10张图片

原来开发者一直也是这个理念,而且在java的客户端已经实现了,但golang一直没有更新

额,原来大家都有拖延症!

搞定!

你可能感兴趣的:(后端)