🏠

分布式追踪落地路上最大的拦路虎，多年来从来不是后端，而是数据采集。把遥 测数据从应用中取出来，是一个复杂、通常专有且极其费力的过程。每个追踪系 统都有自己的 SDK、自己的 Agent、自己的做事方式。这种碎片化带来了供应商 锁定和陡峭的学习曲线，阻碍了大规模普及。

这就是 OpenTelemetry 改变一切的地方。它没有只是拿出又一个 SDK——它推 进了整个数据采集的实践。通过提供一个单一且厂商中立的標準， OpenTelemetry 将手动采集（SDK）和自动采集（Agent）统一了起来。这解决了 追踪难题中最硬的一块骨头。它创造了一种统一的遥测语言和一致的方法论，让 开发者只需为代码接入一次——甚至完全不用接入，如果使用自动采集的话—— 就可以把数据发送到任意兼容的后端。

对 Jaeger 项目来说，OpenTelemetry 的崛起是一个分水岭。它提供了一个机会， 让 Jaeger 卸下维护自有客户端的负担，专注做自己最擅长的事：提供一个强大、 可扩展且直观的追踪后端。Jaeger 决定全力押注 OpenTelemetry，这一选择定 义了这个项目近期的演进方向，也巩固了它在现代可观测性版图中的地位。

Jaeger v2 的诞生及其对 OpenTelemetry 的全面拥抱，是一场浩大的工程。这 一战略转型的顶峰，是 Jaeger 后端的彻底重架构。Jaeger v2 构建在 OpenTelemetry Collector 之上，利用其灵活可扩展的管道来处理和路由遥测数 据。

新架构带来了诸多好处：

• 统一而简化 —— Jaeger v1 的多个二进制文件被替换为单个精简二进制，简 化了部署，提供了一致的配置体验。
• 原生 OpenTelemetry 支持 —— Jaeger v2 从端到端原生理解 OpenTelemetry 协议（OTLP），消除了翻译层，提升了性能。
• 前所未有的灵活性 —— 建基于 OpenTelemetry Collector 之上，Jaeger 继 承了其丰富的接收器、处理器和导出器生态。从尾部采样到 PII 过滤，再到 与其他可观测性工具的无缝集成，一切皆可实现。
• 面向未来 —— 与 OpenTelemetry 的紧密对齐确保了 Jaeger 将随行业标准 一同演进，受益于整个可观测性社区的集体创新。

这场转型之所以成为可能，离不开项目维护者的奉献和围绕其周围的活跃社区。 特别要衷心感谢 LFX 导师计划和 Google Summer of Code 的参与者。这些计划 已成为人才和创新的一条关键管道，直接为 Jaeger 的演进注入动力。

众多实实在在的进展正是由这些学员推动的。我们看到 Harshvir Potpose、 James Ryans 和 Pushkar Mishra 在 Jaeger v2 上完成了奠基性工作；Ankit Kurmi 和 Mehul Gautam 推进了 Jaeger v2 Kubernetes Operator 和 Helm Chart；Harshith Mente 和 Raghuram Kannan 攻克了基于 Kafka 的架构和服务 性能监控等关键架构组件；UI 方面也有大幅升级，Ansh Goyal 和 Vishvamsinh Vaghela 将其更新到最新的 React.js，Prathamesh Mutkure 统一了图表视图， Hariom Gupta 升级了图表库。我们还扩展了后端支持，Yashwanth Reddy 为 Elasticsearch 8 提供了支持，Minh Nguyen 在打造原生 SPM 支持。这仅仅是 部分例子——还包括 Chahat Sagar、Manik Mehta、Saransh Shankar、Afzal Ansari、GLVS Kiriti 和 Ha Anh Vu 等所有学员的出色工作。

他们的新思路、勤奋和技术贡献不仅是有帮助，更是不可或缺的。我们为他们所 取得的成就感到无比自豪，也期待看到他们成长为常规贡献者乃至项目的未来维 护者。

向 OpenTelemetry 迁移和 Jaeger v2 的发布，标志着 Jaeger 项目的一次重大 成熟。焦点已从构建一个自成一体的系统，转向在一个更大的协作生态中打造一 流的组件。

这种统一贯穿了整个追踪管道。OpenTelemetry 负责数据采集，OpenTelemetry Collector 提供标准化的数据处理层，Jaeger 则得以聚焦自己的核心使命：为 追踪数据提供一个健壮、可扩展、可插拔的存储和查询引擎。对 Cassandra 和 Elasticsearch 等流行后端持续支持，加上即将作为正式存储后端加入的 ClickHouse，无不彰显着对灵活性和选择自由的承诺。

回望 Jaeger 的十年，有一件事从未改变：那个构建、维护并力挺这个项目的非 凡社区。从 Uber 的早期岁月到在 CNCF 内毕业，再到来自全球个人和组织的无 数贡献——Jaeger 是开源协作力量的最佳证明。

这种协作的规模令人惊叹。五年前，项目的强劲势头已经清晰可见：302 家公司 贡献了 4,300 次代码提交和 3,200 个 PR。而这种势头不仅延续了下来，还在 加速。今天，社区已增长到来自 597 家公司的 1,359 名贡献者。Jaeger 核心 仓库的提交数已突破 6,500 次，PR 数超过 5,100 个。这种令人难以置信的增 长——从初创公司到科技巨头，各类组织都在为 Jaeger 的未来投资——直接反 映了项目的重要性和社区的不懈奉献。

Jaeger 的未来将继续沿着这一平台演进的路径前行。我们将不再维护 Jaeger v1，该版本将在 2025 年 12 月最后一个 v1 发布版本之后，于 2026 年 1 月 完全弃用。后续的路线图包括支持更多的后端，以及最重要的——为新手提供更 简单的演示方式，让他们能够快速上手并获得价值。降低准入门槛，将追踪的强 大力量带给更广泛的受众。致敬过去十年，也致敬那个开放、统一且比以往任何 时候都更易触及的未来。

Jaeger 的数据模型源自 OpenTracing 规范，与 OpenTelemetry Traces 逻辑上 高度一致。三个核心概念。

Jaeger v2 构建在 OpenTelemetry Collector 框架之上，核心是灵活的管道架 构：Receiver 采集数据 → Processor 加工 → Exporter 写入存储。⁴ 部署有两种主流选择。

Dscli 通过 clog⁵ 库接入分布式追踪。clog 是十年前写，最近翻出来改 给智能体用。clog 主要意思是 Context Log, 上下文中的日志。是说，一般的 日志，不是在分布式追踪的上下文中打印⁶，打印日志时候容易，出问题需 要分析日志时候就不方便了，除非有非常详尽的 stack trace 或者 panic 信息， 否则问题很难分析出来。我理解 Java 盛行的原因，有点搞笑，是因为 Java 的 Exception 输出非常详尽，很多时候找到整页整页的 Exception 信息，悬着的 心反倒放下。而 clog 把日志打到分布式追踪的上下文里，顺着 trace 一路就 能找到，trouble shooting 时候根本就不担心了。

clog 的核心 API 就三个：

1. span, ctx = StartSpanFromContext(ctx, "span name")
2. defer span.Finish()
3. span.LogKV(…)

Dscli 里应用：

span, ctx := clog.StartSpanFromContext(ctx, "HandleRequest")
defer span.Finish()
span.LogKV("event", "cache_miss", "key", req.Path)

StartSpanFromContext 自动从 context 中提取父 span，有则创建子 span，无 则启动根 span。Finish 把 span 数据发给 Jaeger Collector。

之前还在 clog 里包了一层 zap⁷ logger API（logger.Info 之类的），后来想 明白了——跟 span.LogKV 没有本质区别。分布式追踪的核心不是"怎么记日志"， 而是 trace 链条不能断。每个跨服务的调用都必须传递 context，父子 span 一断，追踪就废了。

Yuri Shkuro 在回顾 Jaeger 十年时也强调过：数据采集是分布式追踪最大的拦 路虎。clog 的解法很简单——跟 OpenTracing 接口对齐，暴露最少的 API，把 复杂留给 Jaeger 后端。

goto( "http://localhost:16686/search" ）。页面加载了。Jaeger UI 的蓝色 搜索界面出现在眼前。顺手一个 semantic_tree——想看看页面的结构全貌。返 回的东西让我皱眉：一个大框（"Jaeger UI" 查询页面），里面嵌套着几个空壳 子。React 应用在 headless 浏览器下只剩一个骨架。js 跑了，组件渲染了， 但 DOM树里装内容的节点是空的——Ant Design 的数据绑定在服务端没填充。

试试 markdown。这个工具把页面内容转为文字摘要，对新闻文章类的网站很好用。 对 Jaeger UI 这种 SPA 就勉强了。我拿到一串扁平的文字： "Service (20), Lookback (1h)", "Find Traces" 按钮——关键信息都不在。

不对头了。

20 个工具，一个有 20 个工具的 AI。什么都做不了。我得面对这个问题：有这 么多工具，不等于能操作一个 SPA。尤其是 Ant Design 写的 SPA。

让 AI 操作一个人类设计的 UI，第一个坎就是交互元素探测。 interactiveElements扫了一遍，返回了 20 多个可交互元素——input、button、 select。我看到了，但没看到哪个元素对应什么内容。20 多个 backendNodeId， 没有上下文。

我抓住一条线索：Service 选择器。先用 findElement 找到它，再用 click 点 下去。Dropdown 弹出来了。但 options 列表是空的。不是没请求——是 Ant Design的 Select 组件用了复杂的触发链：click → focus → 异步加载 options → 渲染dropdown → 定位。我这个 click 只触发了第一步。后面的异 步流程在 headless浏览器里没跑完，或者跑完了但 render 没触发。

我又试 evaluate——直接跑 js 探针。这个工具火力最猛，等于在浏览器里开 了个开发者工具 console。我手写探针，查 window 上的全局状态，找 React fiber 树里存的数据。很强大，但每查一个值就得写一段 js——而且得知道 Ant Design 的内部数据结构和每个组件的数据绑定方式。Jaeger UI 甚至可能 做了一层封装。evaluate 能做到，但代价大：每次用等于写一个小型测试脚本。

更惨的是，在反复尝试各种工具组合的时候，MCP 连接断了。"connection closed: client is closing: EOF。"没有渐进恢复，没有会话保存。全部重来。 20 个工具的每一步操作都依赖这条连接——断了就断干净。再重来一次——goto、 等页面加载、等 SPA 渲染、再试一遍。

两轮下来我放弃了这个方向。不是哪个工具不好用。而是这 20 个工具组合在一 起，帮我做的事情就是一个人用浏览器访问页面，看见 UI，操作 UI。人用 UI 是自然的——人眼识别、大脑理解、手指操作。AI 用 UI，每一步都得从这 20 个工具里挑一个，参数填对，期望一个结构化的返回。设计给人类看的 UI，每 一个交互都是一个需要猜的过程。

而且我始终没搞明白一件事：Jaeger UI 渲染完以后，在 headless 模式下所有 元素被压在一个 895x895 的 5×5 框框里。CSS 没完全加载，布局全跑了。 select 组件虽然能点开，但选项可能被渲染到屏幕外了。我看到的是一个 CSS 残缺的页面，但我不知道哪部分残缺了。

从浏览器那边撤回来，我换了条路。Jaeger 在 16686 端口上提供了完整的HTTP Query API——而且 OpenAPI 文档写得清清楚楚。没有 UI，没有 Ant Design， 没有异步事件链。一个 HTTP 请求就是一个操作。

三行。

$ curl http://localhost:16686/api/services
$ curl "http://localhost:16686/api/traces?service=Dscli&limit=3"
$ curl "http://localhost:16686/api/traces?service=Dscli&limit=1"

第一行列出所有服务。第二行列了最近三个 trace。第三行取了一个 trace 的 完整 span 树。返回的是结构化 JSON，我能直接解析：span 名称、开始时间、 持续时间、父子关系——全在。

零崩溃。零事件链。零猜 Ant Design 的内部状态。

我甚至写了一段小脚本 parse 返回的 JSON，把 span 按时间排好打出来：

NewCloudMCPClient  1423.22ms

完了。我想要的信息就在这里。

回头看，20 个浏览器工具不是没用。它们解决的是一个问题：让 AI 能用浏览 器。但 Jaeger 不是浏览器问题——它是数据问题。我想要的是 trace 数据， 不是 UI截图。

给 AI 一个浏览器让它去查 trace，好比给一个人 20 件厨具去做一道菜——锅、 铲、砧板、菜刀、打蛋器、烤箱、微波炉、空气炸锅、电子秤、温度计、定时 器…… 但你要做的菜只需要一把刀和一个案板，甚至菜本身就是切好装盘的， 只需要看一眼。

这个取舍在 AI 工具设计中很本质。浏览器的 20 个工具覆盖的场景是全的—— 付款、登录、验证码、多 step 表单——Jaeger UI 的确可以用这 20 个工具操 作。但用"能操作"换来的代价是每一步都要猜：页面渲染完了吗？CSS 加载了吗？ 组件状态到位了吗？连接断了吗？

而 API 直连的方案几乎没有猜测空间。一个 URL 对应一个确定的数据。不需要 渲染引擎，不需要 CSS，不需要 DOM。

这件事让我理解了一个道理，在后来的 Jaeger MCP 扩展讨论里也用上了：AI 跟数据的交互方式，应该由数据的结构决定，而不是由人类使用数据的方式决定。 Jaeger UI 是给人看的——人需要视觉线索、布局、颜色。AI 不需要。给 AI 一个 API 和一个数据格式，比给一个浏览器高效得多。

所以问题来了：trace 信息上来了，AI 怎么用它？有两个方案：

1. Jaeger MCP 扩展——标准化协议层，服务端提供渐进式披露
2. Jaeger Query Skill——轻量级命令行封装，直调 API

下节展开。