前端，笔者在使用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一直没有更新
额，原来大家都有拖延症！
搞定！