前端，笔者在使用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一直没有更新

额，原来大家都有拖延症！

搞定！