LLM 服务可观测性——指标、追踪与告警设计

一　为什么传统 APM 不够用

LLM 服务的失败形态比传统微服务多了几个量级：延迟是分钟级且长尾严重（一次推理几十秒属正常）、失败可能"静默"（返回 200 但内容跑偏）、成本与质量是连续量而非布尔量。传统 APM 的"QPS / 错误率 / P99"三件套只能覆盖最外层，离"模型在干什么、花了多少钱、输出好不好"还有很远距离。LLM 可观测性（LLMOps/Observability）是在传统三件套之上补一层"模型语义"维度的度量。

二　三层信号模型

L3 是 LLM 特有的。L1/L2 沿用传统 APM 即可，L3 需要专门的埋点（trace 里记 prompt / completion / 工具调用 / token 数），是本节重点。

三　核心指标清单

关键设计原则：token 与成本必须按"可归因维度"打 tag（feature / user_tier / tenant / prompt_version / model）。没有这些 label 的成本数据是"一锅粥"，无法做预算与优化。

四　Tracing：把"一句话进、一段话出"拆成步骤链

LLM 请求的真实形态是"编排链"：检索 → 拼装 prompt → 模型调用（可能多轮）→ 工具调用 → 后处理。OpenTelemetry GenAI 社区规范（semantic conventions for gen_ai）定义了 span 的最小集：

• gen_ai 调用 span：记录 model / 输入 token / 输出 token / 停止原因 / 耗时，parent 为编排 span
• 工具调用 span：记录工具名 / 参数摘要 / 成功与否 / 耗时
• 检索 span：记录 query / 命中数 / 延迟
• 属性（attributes）：gen_ai.system / gen_ai.prompt / gen_ai.completion 是否记录默认采样，不是全量——全量记录成本与隐私都扛不住，默认采样 + 条件全量（失败 / 慢请求 / 被踩）是主流做法

tracing 的价值在三个场景：慢请求归因（10 秒的请求里 8 秒花在检索而非模型，一目了然）、级联失败定位（第 3 轮模型调用超时导致整链回滚）、成本上钻（哪个 feature 的哪条链最烧钱）。采样策略建议：基础指标全量，内容属性 1%-10% 采样，失败 / P99+ / 负反馈 100% 捕获。

五　日志：小采样、大价值

• 全量记"骨架"：request_id / user 匿名 / feature / model / prompt_version / tokens / cost / 延迟 / 结果状态。不带 prompt 正文——骨架日志是全量成本的核算依据。
• 采样记"内容"：按 1%-10% 记录 prompt / completion，用于离线质量复盘与评估集扩充；失败请求 100% 记录。
• 脱敏先行：prompt / completion 里可能含 PII，入库前过 PII 检测 + 掩码；采样比例与保留期写进数据合规策略。
• 版本化字段：prompt_version 是关键字段——任何 prompt 大版本迭代都必须带版本标，否则线上问题无法关联回"哪个 prompt"。

六　告警设计：不等 P1 才响

LLM 告警的特殊性："静默失败"——HTTP 200 但内容空 / 重复 / 乱码 / 跑题，传统错误率告警完全覆盖不到。必须加输出侧校验（长度分布、重复 n-gram 比例、结构 schema 校验）作为告警源，这是 LLM 可观测性与传统 APM 的最大差异点。

七　成本归因与单位经济

• 成本公式：单次成本 = (输入 token × 输入单价 + 输出 token × 输出单价)；批处理 / 缓存命中 / 特价渠道要单独记价（cached token 单价通常 1/10）。
• 归因维度：tenant / feature / user_tier / prompt_version 四个 label 是标配，缺一个就少一类优化抓手。
• 单位经济核算：把"每请求成本"折算到"每付费会话 / 每解决工单 / 每产出件"，才能回答"这个 feature 值不值得继续跑"。
• 成本看板：预算消耗图表（按天 / 按 feature），超预算 80% 提前预警，而不是月底对账单才发现。

八　离线评估：把"质量"从感觉变成曲线

• 黄金集（golden set）：人工标注的 50-500 条查询-期望对，每次 prompt / 模型变更后跑一遍，产出"通过率 + 逐条 diff"。这是 prompt 版本管理的核心评测手段。
• LLM-as-judge：用强模型做批量评估（rubric 明确的 5-10 分制），人工抽检 10% 校准 judge 的偏差；成本低，但要知道 judge 不是神，只适合监控趋势，不适合做绝对质量判定。
• 用户反馈闭环：赞踩 / 重新生成 / 编辑输出这三个行为是最真实的"隐式评估"，按 prompt_version 与 feature 聚合，喂回黄金集扩充。
• 质量基线：把"通过率 / 踩率 / 重新生成率"画成时间序列，与告警联动——离线评估是"体检"，线上指标是"监护仪"，两者缺一不可。

九　选型与落地清单

• 第一步：把 token / cost / 延迟按 feature × model × prompt_version 打 label——没有这个，后续所有优化都没抓手
• 第二步：接入 OTel GenAI 的 span 语义，把"每轮模型调用 + 每次工具调用"进 trace
• 第三步：加输出侧校验（结构 / 长度 / 重复），补"静默失败"告警
• 第四步：建 50 条黄金集，跑通 prompt 变更 → 自动评估 → 通过率门槛的流程
• 第五步：成本看板 + 预算阈值告警上线，月度复盘单位经济

成熟度判据：能回答"昨天哪个 feature 烧了多少钱、哪些请求变慢了、哪版 prompt 的质量掉了"——三个问题 5 分钟内用看板回答，可观测性才算建成。

十　一次完整事故的复盘示例

把前三章串起来看一个真实链路：09:01 调用 P95 延迟突破 30s 告警，Trace 显示慢段全在第一个 LLM 节点且伴随重试；09:02 模型节点的 provider 侧指标（状态码 429 计数飙升）定位到是供应商限流；09:10 网关熔断切到备用模型，P95 回落；全程处理时长与损失请求数从评估集和日志里都能复算。"延迟告警 → Trace 慢段 → provider 指标 → 熔断动作 → 事后复算"这条链走通，可观测性才算真正在业务工作。单看任何一环（只有延迟没有 Trace，只有 Trace 没有 provider 指标）都断在中间。

引用

• OpenTelemetry GenAI Semantic Conventions
• Langfuse：开源 LLM 可观测性平台
• LangSmith 文档（评估与追踪设计参考）
• Zheng et al.: Judging LLM-as-a-Judge（评估方法论）
• Anthropic: Building effective agents（编排链观测）