标准回答
记什么：结构化日志
每次调用落一条结构化日志：trace_id、用户/会话 id、模型与参数、输入 prompt、输出内容、输入/输出 token 数、延迟、错误码、是否命中缓存。RAG/Agent 场景还要记检索片段、工具调用链，用同一个 trace_id 把多步串成一条链路（trace），方便定位是哪一步出问题。
看什么：核心指标
做仪表盘盯 P95/P99 延迟（均值会掩盖长尾）、错误率、按模型/功能拆的 token 成本、缓存命中率。质量侧可抽样跑 LLM-as-judge 或人工标注打质量分，监控幻觉/拒答比例。
怎么报警
对错误率、延迟、成本设阈值，突增时实时告警到群/值班。把触发告警和用户反馈差评的 case 自动归集成 badcase 集，定期复盘改 prompt 或调模型。
别忘脱敏
日志里常含用户隐私（PII），要按字段脱敏或掩码、敏感数据加密，控制留存周期，满足合规并控制存储成本。可直接用 LangSmith、Phoenix 等 LLM 可观测平台省去自建。
常见误区
⚠️ 常见踩坑
只监控均值延迟和系统存活，忽略 P95 长尾和输出质量——模型「能返回但答得很差」是不会触发系统告警的；另一个坑是原样记录用户输入导致 PII 泄露。
追问
追问 1：大模型应用的监控和传统后端监控有什么不一样？
传统后端关心 QPS、延迟、错误率即可；大模型多了三类特有维度：token 成本（直接花钱，要按功能拆账）、输出质量（能返回但答错，需抽样评测而非看状态码）、以及多步链路（RAG 检索、Agent 工具调用要串成 trace 才能定位是哪一步坏的）。
追问 2：怎么离线复盘线上 badcase？
把告警和用户差评的请求按 trace_id 还原完整输入/检索/输出，归集成 badcase 数据集，人工或 LLM 标注问题类型（幻觉、格式错、检索没命中等），针对性改 prompt、补知识库或调参，再用这个集合做回归，验证修复没有引入新问题。
延伸学习
与本题相关的知识库文章、术语、工具与行业资讯。
🛠️ AI 工具
- Phoenix
AI 可观测性与评估平台，9750 stars。提供 LLM 应用的可观测性、评估和调试能力，帮助监控 AI 系统性能