10 篇博文 含有标签「opentelemetry」

第一个注意到你推理模型回退的人，几乎永远不会是工程团队的成员。而是财务分析师，在周二下午联系你的经理，因为上个月的 Anthropic 账单比前一个月高了 2.4 倍，而且“我们并没有发布任何会导致这种结果的东西”。你打开仪表板，查看请求量——平稳。p99 延迟——平稳。每个响应的输出标记——平稳。错误率——平稳。你六个月前配置的每一个面板都显示系统运行健康。财务人员看的是另一个数字，而且他们是对的。

他们看的数字是推理标记（reasoning tokens），而大多数可观测性栈是在这个领域出现之前构建的。

凌晨 02:14，报警器响了：客户反馈助手在回答长问题时“话说到一半就卡住了”。你打开追踪（trace）。LLM 调用的 span 显示为 8.4 秒 —— 绿色，在 SLO 范围内，没有错误属性，结束原因（finish reason）为 stop。仪表板上该端点的 p95 延迟聚合组件显示为 9.1s，与过去一个月的情况完全一致。根据 APM 显示的所有信号，该请求都成功了。

用户看到前 200 毫秒表现完美，接下来的四秒钟生成了一个连贯的段落，然后眼睁睁看着同样的三句话片段在剩下的四秒钟里不断重复，直到连接结束。这种卡住的内容循环（stuck content loop）是真实的故障，但追踪系统对此一无所知 —— 因为追踪系统是为“返回即结束”的系统设计的，而不是为了这种行为表现为生成过程中产生的中间状态之墙的系统。

用户报告说助手在上午 9:47 给了他们一个错误答案。你打开 Trace。这里有 340 个 Span。它们几乎都被命名为 agent.run、llm.invoke 或 tool.call。有些有父节点，有些是兄弟节点。其中三个进行了重试，一个重试后被取消了。没有一个能告诉你错误的输出是来自 Planner、Worker、Critic、Reflection 过程，还是在 Critic 标记后 Worker 的第二次重试。

在接下来的一个小时里，你根据截图中的 UUID 前缀搜索日志行，比对 Slack 通知的时间戳，并根据 Trace 查看器中的缩进模式在脑海中重建 Agent 拓扑。最终，你猜想第三次 Worker 调用使用的模型别名在昨晚被静默切换到了另一个快照。但你无法仅凭 Trace 证明这一点。

Agent 正常运行，Trace 完整无缺。杂乱无章的 Trace 团（Hairball）本身就是 Bug。

账单在 3 月份寄达。仅追踪（traces）一项就花费了 8.1 万美元，而 11 月时这一数字仅为 1.2 万美元。团队在 10 月份启用了全量 Agent 追踪，理由是可见性越高越好。到了第一季度，可观测性成本的增速已经超过了推理成本——而当生产环境真正出现性能回归（regression）时，包含故障的追踪记录却被淹没在两千万个无人问津的成功 span 中。

错误并不在于决定进行埋点。错误在于将请求追踪（request-tracing）的心智模型引入了一个行为完全不像传统请求的工作负载中。

一个典型的 Web 请求会生成一个包含少量子节点的 span 树：处理器、数据库调用、缓存查找、下游服务。而一个 Agent 请求生成的树包含 5 个 LLM 调用、3 个工具调用、2 个向量查找、中间草稿（scratchpads），以及一个重新审视其中 3 个步骤的规划器。同样适用于 API 网关的采样策略——头部采样（head-sample）1%，保持其余部分的代表性——在 Agent 场景下会产生一个追踪存储库，其中中位数追踪是拥有 200 个 span 的怪物，长尾效应才是唯一关键的部分，而你发现故障的频率与你花钱的频率完全无关。

凌晨 3 点让财务部门收到告警的成本飙升其实并不是真正的成本飙升。那只是一个 Span 重命名。Agent 平台团队的某个人觉得 llm.completion.synthesis 应该改为 llm.generate.answer，因为这样读起来更自然。他们提交了一个小的 PR，运行了测试，然后发布了。三天后，财务的月度 Token 消耗仪表盘显示下降了 60%。没有人削减支出。聚合规则仍然按旧名称分组，而新的 Span 流向了一个仪表盘甚至没有渲染的 “其他” 桶中。账单没有变。仪表盘变了。

这是我一直看到团队在重复经历的一类事故。Span 名称和属性键并不是为了让人在追踪 UI 中阅读而存在的标签。它们是一个未公开 API 的公开 Schema，其消费者是生产团队从未谋面的——过滤它们的评估流水线、按它们分组的成本仪表盘、根据其持续时间触发的 SLO 告警、汇总其 Token 属性的 FinOps 报告。一个团队内部 “无害的重命名”，对于另外四个从未看过该 PR 的团队来说，就是一个网络协议破坏。

你的 LLM 调用耗时 2,340 毫秒。你的 APM Span 是这么记录的。这个数字是你可观测性堆栈中最昂贵的谎言，因为四种完全不同的故障模式都被渲染成了同一个不透明的紫色条块。长提示词下的 Prefill（预填充）浪涌。一个一小时没访问的租户导致的冷 KV 缓存。提供商连续批处理（continuous batching）中的“吵闹邻居”。一次无声的路由变更将你的流量导向了不同的区域。同样的 Span。同样的耗时。同样的 p99 告警。却是四个截然不同的复盘分析。

适用于微服务的分布式追踪准则 —— 每个网络跳数一个 Span、一个时长、几个标签 —— 在面对托管推理时失效了。LLM 调用并非单一实体。它是一个由多个阶段组成的流水线，每个阶段都有截然不同的扩展特性，运行在行为取决于队列中其他人的共享硬件上。将其视为一个单一且不透明的 Span，会导致你花费三天时间去调试“模型变慢了”，而实际上模型根本没变。

大多数分布式追踪方案在引入 Agent 之前都运作良好。一旦系统中出现 Agent A 跨微服务边界调用 Agent B——Agent B 调用工具服务器、工具服务器再查询向量数据库——原本连贯的端到端视图就会碎片化为互不相连的片段。追踪后端展示的是一个个孤立的操作，而你失去的是因果链：为什么某件事发生了，哪个用户请求触发了它，以及那 800 毫秒究竟消耗在了哪里。

这不是监控配置问题，而是上下文传播架构问题。它有着特定的技术形态，大多数团队都是在付出代价后才意识到这一点。

你的 Datadog 仪表盘一片绿色。Jaeger 链路看起来干净整洁。P99 延迟符合 SLA。而你的 Agent 流水线正在悄无声息地因重试死循环每天烧掉 4000 美元，却没有触发任何一条报错。

传统 APM 工具是为微服务设计的——确定性路径、有界载荷、可预测的扇出。Agent 流水线打破了所有这些假设。执行路径在运行时才能确定。工具调用深度变化剧烈。一次"请求"可能跨数分钟产生数十次 LLM 调用。而当出了问题，失败模式通常不是异常——而是一个悄然膨胀成本和延迟、却返回看似正常输出的静默重试级联。

结果是一代工程师在盲目飞行，信任着那些衡量错误事物的仪表盘。

你的链路追踪仪表盘显示 Agent 为了响应用户请求发起了 8 次调用。但实际上，它发起了 47 次。你的头部采样器（Head-based sampler）静默地丢弃了其中的大部分。你保留下来的那些调用在技术上是正确的，但在因果关系上毫无用处——它们是从被父级采样器丢弃的根节点中孤立出来的子 Span。

这并不是可视化层面的 Bug。它是将专为 10 个 Span 的 HTTP 扇出设计的分布式链路追踪基础设施，强行套用到每轮对话生成数百个 Span 的系统上的必然结果。默认的 OpenTelemetry 配置系统性地低估了 Agent 的工作量，而运行这些 Agent 的团队通常直到客户抱怨链路追踪视图中显示“不存在”的延迟时，才会察觉到问题。

你的 Agent 正在返回 HTTP 200 状态码。延迟在 SLA 范围内。错误率平稳。仪表板上的一切都显示为绿色 —— 但你的用户却得到了言之凿凿的错误答案。

这是 AI 系统中核心的可观测性差距：传统上标志系统健康状况的指标，与你的 Agent 是否真正胜任工作几乎完全无关。一个 Agent 可以流利地产生幻觉、跳过必需的工具、使用陈旧的检索结果，或者陷入逻辑自相矛盾 —— 而此时你的监控却显示零异常。服务可观测性的标准手册并不适用于 Agent 系统，不理解这一差距的团队会发布他们无法信任、调试或改进的 Agent。