LLM 应用日志与监控：出了事怎么定位是哪个环节的锅

王王老师2026/07/05232 阅读

LLM 应用的排查比传统应用难：一个请求要经过检索 → 拼 prompt → 调模型 → 后处理好几个环节，出了问题不好定位是检索错了还是模型答错了还是代码 bug。没有监控，只能靠猜。这篇讲我的可观测性方案。

请求级日志（最关键）。

每个请求记录完整链路：

JSON

{
  "request_id": "req_xxx",
  "user_id": "u_123",
  "timestamp": "2026-08-12T10:00:00Z",
  "retrieval": {"hits": 5, "scores": [0.92, 0.88, ...], "latency_ms": 120},
  "prompt_tokens": 3200,
  "completion_tokens": 450,
  "total_latency_ms": 3200,
  "model": "deepseek-chat",
  "error": null
}

关键是分环节记录耗时：检索多少毫秒、模型生成多少毫秒。这样用户说"好慢"，你能直接看出慢在哪。

结构化日志别用 print。用 JSON logger，方便后面接日志平台查询。生产环境日志量很大，别全打 INFO，检索和模型的详细参数走 DEBUG。

指标：

QPS 和并发：总量 + 按模型拆分
延迟 p50/p95/p99：总延迟 + 分环节延迟。p95 是用户体验，p99 是性能上限
错误率：按错误类型（429、5xx、超时、内容安全）
Token 消耗：按模型、按租户、按场景。这就是钱，必须监控
缓存命中率：语义缓存命中多少，直接关系成本

追踪（tracing）：

请求跨多个服务（网关 → 检索 → 模型）时，用 trace ID 串联。每个环节打上 request_id，出问题按 ID 查全链路。轻量方案：自己维护一个 request_id 上下文，用日志聚合平台按 ID 查。

告警：

错误率 > 5% 告警
p95 延迟超过阈值告警
模型服务不可用（连续失败）告警并自动切备用
每日 token 消耗异常突增告警

坑：

日志别记敏感数据。用户输入、prompt 内容可能含隐私，脱敏后再记。只记 token 数和长度。
请求 ID 要透传。前端生成的 request_id 要一路透传到后端每个环节，不然没法关联。
监控别过度。指标多了看不过来，先保证核心几个，再逐步加。

总结：LLM 应用监控的核心是"分环节耗时 + 结构化日志 + request_id 串联"，把这三样做扎实，90% 的问题都能快速定位。

还没有评论，来抢沙发～

评论0