数据沉睡十年？分布式追踪唤醒服务器智能开发

　　去年五月，我蹲在IDC机房第三排冷通道，手电照着42U机柜第七层——那台标着“trace-prod-07”的老Dell R730风扇响得像拖拉机，但监控面板上trace_id吞吐量是零。

　　运维小张蹲我旁边，啃着冷掉的肉包子，忽然说：“查了八次，全链路埋点都没漏，就是不往Jaeger里吐。”他说话时鼻尖沾了点芝麻粒，我伸手想蹭掉，又缩回去了——反正芝麻粒和trace_id一样，都卡在某个看不见的地方不动弹。

　　我原以为是Kafka Topic配错了分区数，结果改完重启collector，第八次跑压测，span还是飘在内存里不肯落地。后来翻出半年前的部署日志，发现一次半夜的Ansible脚本执行失败被自动跳过（那行log缩在三千行里，只带个yellow warning）；再往前翻，去年一月，trace-prod-07其实就从OpenTracing切到了OpenTelemetry，但有个Java Agent的启动参数--otel.propagators没同步更新，它默认还在用B3，而我们后端Service Mesh里Envoy用的是W3C——两个传播协议撞上了，trace_id进了集群就像进迷宫，连头都找不到。

文章配图，仅供参考

　　小张突然说：“你信不信？这机器上还跑着2014年上线的老订单同步服务，JDK1.6，连-XX:+UseCompressedOops都不认。”他拍了下机箱，震下点灰，掉在我鞋面上——那灰有点泛黄，像旧胶片显影液留下的渍。

　　后来查到真凶：TraceID生成逻辑里调用了System.nanoTime()，而那台R730的CMOS电池早瘪了，每次断电重启，系统时间倒跳二十一分钟；Java进程起来时，nanoTime基线乱跳，OTel SDK直接判定该span时间戳非法，静默丢弃。不是bug，是设计里写死的防护阈值：超过±15分钟拒收。

　　（隔壁工位李工正用指甲刮键盘缝里的饼干渣，刮了三分钟，刮出半粒巧克力豆）

　　我把CMOS电池换掉，time sync ntpdate pool.ntp.org跑通，再发请求——span全出来了，连带着十年前那个老订单服务埋的、从来没人见过的trace_tag: legacy_v1_2014，也一块浮上来，在Jaeger UI里闪了两下，灰蓝色，像刚苏醒的萤火虫。小张凑近看，嘀咕：“它记得自己是谁啊？”

　　我盯着那个tag愣了会儿。数据没沉睡，只是我们十年没往它耳朵里喊过名字。

　　有谁碰到过这个吗？

（编辑：航空爱好网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!