← 返回概念解读

Concept Fable精修版

OpenTelemetry

OpenTelemetry, OTel · Observability standard

先读故事。这里不急着给定义,先让问题自己长出来。

寓言故事

各家钟表终于用同一种刻度

银钟镇有许多作坊,各自记录时间。药铺用香燃了几寸,码头用潮汐刻线,工坊用沙漏。平时够用,事故复盘时却对不上。一次跨城订单失败,客服说回复慢,仓库说工具正常,机关铺说延迟不高。每家都有记录,但格式、时间和名字都不一致。镇长先让大家把记录簿都发给账房。账房收到一堆纸,仍然无法串起来:同一个请求在不同整套装置里有不同编号。

后来,修钟匠提出统一刻度。每个步骤都带同一个追踪编号,每段工作写成 span,关键数值变成 metrics,事件和记录簿按共同语义记录。

这套刻度不属于某一家作坊。今天接甲家的看板,明天换乙家的存储,记录方式仍能延续。商队不用被单个工具绑死。

接入后,跨整套装置排障快了很多。一个 帮手 请求从前端到检索、机关、工具、总账柜的路径可以被串成一条线。

工匠也给 长信匠 场景补充语义:机关名、字粒数量、prompt 版本、检索数量、工具名称、错误码。标准刻度要能覆盖新型工作。

银钟镇最后明白,观测数据的价值不只在采集,更在能跨团队、跨供应商、跨整套装置对齐。

修钟匠还规定,谁也不能把自己的暗号当全城规矩。药铺想保留药名,码头想保留船号,都可以,但共同刻度必须让别人知道它们指向同一趟订单。

第一次真正派上用场,是一批药材迟到。大家顺着同一个编号从前台、仓库、车队查到外城驿站,才发现慢在第三次转运。镇长说,记录能说同一种话,复盘才不再变成互相辩解。没有共同刻度,越多记录只会制造越多争吵;有了刻度,慢、错、断才各有位置。

揭示

这个故事讲的是:OpenTelemetry

OpenTelemetry, OTel 是厂商中立的观测标准,用于采集 traces、metrics 和 logs。LLM/Agent 应用可以用 OTel 把前端请求、检索、模型调用、工具执行和数据库操作串成统一链路,并减少对单一观测平台的锁定。落地时通常需要加入 LLM 语义字段,如模型、token、prompt 版本、工具名和成本。

它重要的地方在于:它不只是一个术语,而是在真实 AI / Agent 系统里会反复出现的结构性问题。理解它,才能判断什么时候该加模型,什么时候该改流程,什么时候该补治理。

隐喻映射

  • 各家时间记录:不同系统的私有日志格式
  • 统一追踪编号:trace id
  • 每段工作写成 span:OpenTelemetry span
  • 关键数值:metrics
  • 厂商中立刻度:OTel 的可移植性
  • LLM 语义字段:面向 Agent 的观测扩展

Soloharness 判断

这个概念的实战价值,是帮你把“看起来聪明的 AI 功能”拆成可交付、可验收、可治理的工作单元。

tracesspansmetricslogsobservabilityLangfusePhoenix