OpenTelemetry（常简称 OTel）是一套开源、厂商中立的可观测性（Observability）标准，用统一的 API、SDK 和传输协议采集 traces（链路追踪）、metrics（指标）、logs（日志），再发给任意后端平台存储与查询。
它到底解决什么问题
过去做监控，埋点常常和厂商绑定：用某一家的 APM（应用性能监控），就得装它的 agent、调它的 SDK；哪天换一家，几万行埋点代码要重写。OTel 相当于给观测数据定了一张“统一快递面单”：你只负责按标准格式打包——这次请求叫什么、耗时多少、谁调用了谁——至于包裹最后走哪家物流（各类开源后端或商业监控平台），换一家就行，业务代码不用动。
三类信号的分工大致是：
| 信号 | 回答的问题 | AI 场景的例子 |
|---|---|---|
| Traces | 这一次请求经历了什么 | 用户提问 → 检索 → 模型调用 → 工具调用，各段耗时 |
| Metrics | 整体趋势如何 | 每分钟请求数、P95 延迟、token 消耗总量 |
| Logs | 具体发生了什么 | 模型返回的原始报错、被截断的 prompt |
关键在于三者可以互相关联：OTel 让日志也能带上 trace_id，点开一条慢请求，就能跳到那次调用打印的日志。
跨模型调用的链路追踪
核心机制是上下文传播（Context Propagation）。请求进入系统时生成一个 trace_id，OTel 通过 W3C Trace Context 标准（HTTP 头里的 traceparent）把这个 ID 顺着调用链一路传下去，跨服务、跨语言、跨厂商都认。每个环节开一个 span，记录起止时间、耗时和属性，父子关系拼起来就是一棵调用树。
AI 应用尤其需要这个。一次 RAG 问答背后可能是：embedding 模型 → 向量库 → 大模型 → 工具调用 → 又一次大模型。这些环节常常分属不同供应商，出问题时最难回答的就是“到底慢在哪”。有了 trace，两秒钟花在向量检索还是模型首 token，就能直接看出来。
为了不让字段名各写各的，OTel 社区维护了一套语义约定（Semantic Conventions），其中面向生成式 AI 的部分规定了模型名、输入输出 token 数等属性该怎么命名；具体字段以官方文档为准。
另外常被忽略的是 Collector：一个独立的接收与转发进程，可以在数据出站前统一做批处理、采样和脱敏——比如把 prompt 里的手机号、身份证号抹掉再入库。
和相邻概念的区别
- 各类指标、链路后端负责“存和查”，OTel 是“采集层”，负责标准化地产生和搬运数据，两者是上下游关系。
- 商业监控产品开箱即用但容易锁定用户；OTel 的价值正是换后端不换埋点。
- 日志框架只管把日志写出来，OTel 负责把日志跟 trace、指标串成一条线。
对从业者的意义
对工程师：埋点一次，后端可换；成本归因也方便——按 trace 上的 token 属性，能把模型账单分摊到具体功能和团队。
对普通职场人：AI 功能变慢或答非所问时，团队能说清“是检索慢、模型慢，还是工具超时”，而不是一句“AI 又抽风了”。