为什么现有LLM可观测性看不见真正重要的东西

应用层日志告诉你某个服务做了什么，但它永远不会告诉你整个 AI 系统在做什么。

想象这样一个场景：你的模型提供商账单在一周内突然大涨，却没人能说出原因。每个应用都有自己的日志器、自己的仪表盘、自己的一块真相。它们没有一个能展示全貌，因为它们本来就不是为全局视角而构建的。

这就是当前 LLM 可观测性面临的真正问题。不是缺少工具，而是一个结构性的盲点。你试图通过逐个应用地查看，来理解一个多模型、多团队的系统。

为什么按应用日志记录不再有效

包装你的 OpenAI 或 Anthropic 客户端，然后将日志发送到 APM 工具，这是最自然的第一步。在一个应用对接一个模型的场景下效果不错。一旦系统变得复杂，就会因为三个具体原因而崩溃。

你只能看到自己的应用。要比较应用 A、应用 B 和应用 C 之间的 token 消耗或错误率，意味着要把好几个不同的日志系统拼接在一起，前提还是它们对同一指标的测量方式本身就是一致的。

你会错过应用发送请求之后发生的事情。客户端日志显示的是你发送的 prompt 和收到的响应，但如果使用了 fallback 路由，它不会显示实际是哪个模型处理了该请求，也不会显示在任何响应过滤运行之前提供商返回了什么。

它无法随着系统表面积扩展。每一个新应用都需要自己的一套埋点。每次更换模型意味着要在所有部署了埋点的地方更新。这和 API 网关多年前为 REST 流量解决的问题一样，只是大多数团队还没有把经验迁移到 LLM 流量上。

是什么让 LLM 真正难以观测

传统 APM 假设确定性行为。同样的输入，同样的输出，同样的延迟特征。LLM 在每个维度都打破了这个假设。同一个 prompt 可能返回不同的 token 数量，根据负载情况被路由到不同的模型，并且根据处理请求的提供商不同而产生不同的费用。将 LLM 调用强行嫁接到为确定性服务构建的通用 APM 配置上，从设计层面就会得到不完整的数据。

六个值得追踪的数字

如果你在为 LLM 流量埋点，应该在聚合层级追踪这些指标，而不是按应用逐个追踪。

请求延迟 p50、p95、p99。平均值会掩盖长尾延迟，而长尾延迟正是你那个最恼火的企业客户此刻正在经历的。

每个请求的 token 使用量，输入和输出分开计数。这是你的成本驱动因素，也是 prompt 或 agent 循环出现问题的最早信号。

每次调用的成本，按团队或应用归因。没有这个，你就无法准确回答"谁在烧预算"，只能靠猜。

错误率，按提供商追踪，这样你才能区分是提供商故障还是 prompt 模板坏了。

Fallback 率。如果有相当比例的流量进入了 fallback 链，说明你的主模型或提供商存在一个你尚未察觉的可靠性问题。

容量、成本或失败异常的告警。在这一层也能捕获 prompt 注入攻击或配置错误的 agent 卡在重试循环里的情况，最好在账单出来之前就发现。

单个应用的错误率本身几乎说明不了什么。同样的数字放在整个系统层面聚合，就能告诉你问题出在提供商、prompt 还是你自己的配置。

百分位数，而非平均值

一个请求大多数时候耗时 200ms，偶尔耗时数秒，它的平均值非常可观，但用户体验实际上糟糕透顶。p50 告诉你典型情况，p95 告诉你接近最坏的情况，p99 告诉你实际最坏的情况。追踪这三个数字，并按模型和团队分别拆解，因为"哪个模型慢"和"谁发送了慢查询"是两个不同的问题，需要两种不同的解决方案。

OpenTelemetry 的用武之地

你不需要为 AI 单独建立一套可观测性技术栈。OpenTelemetry 已经为你提供了跨基础设施的 traces、spans 和 metrics 统一格式，而且它现在有了专门针对生成式 AI 的语义约定：provider、model 和 token 计数的标准属性名，任何兼容 OTel 的后端都可以直接摄入 LLM traces，无需定制管道。需要注意的是，这些 GenAI 约定目前仍处于活跃开发中，因此随着规范逐步稳定，部分属性名可能会发生变化。

基于这一约定构建的 GenAI span 大致如下：

{
  "name": "chat gpt-4o",
  "attributes": {
    "gen_ai.operation.name": "chat",
    "gen_ai.provider.name": "openai",
    "gen_ai.request.model": "gpt-4o",
    "gen_ai.usage.input_tokens": 812,
    "gen_ai.usage.output_tokens": 194,
    "gen_ai.response.finish_reasons": ["stop"]
  }
}

如果你的埋点以这种格式发射 spans，LLM traces 就会和你的常规服务 traces 出现在同一个后端里，无需为 AI 单独维护工具链。

网关层的作用

在不触及每个应用代码库的情况下获取所有这些数据的最佳方式，是在应用和模型提供商之间部署一个 AI 网关。每个请求都经过同一层，因此该层可以自动捕获延迟、token 数量、路由决策和每次调用的成本。无需为每个应用单独埋点。这也是运行异常检测的天然场所，因为它是唯一一个同时看到所有应用和所有团队流量的组件。

TrustGate 是 NeuralTrust 对这一模式的开源实现，它位于请求路径上，为每次调用记录完整的 trace。关于这种网关级 LLM 可观测性的指标和架构的更深入分析，可以在原始文章中找到，值得一读，如果你想要比这里更详细的细节的话。

如果你同时在考虑这方面的安全问题——不仅仅是成本和延迟，还有 agent 工具访问被滥用或 prompt 注入攻击出现在你的流量中时会发生什么——Agent Security 有一个不错的威胁模式和缓解措施库，值得查看。

按应用日志记录从来就不可能给你系统层面的答案。如果你想知道你的 AI 栈实际上在做什么——跨越每个模型、每个应用和每个团队——观测点必须移动到它们所有人的上游。这是一个基础设施层面的决策，而不是日志库的决策。