直接回答：传统后端监控看黄金信号（延迟、错误率、流量、饱和度），LLM 应用在此之上多出三层：质量维度（输出对不对，无法用状态码判断，需要评测与用户反馈）、成本维度（token 消耗按模型与链路分解，成本是核心 SLI）、行为维度（完整 trace：每步 prompt、工具调用、中间输出，用于归因与复现）。

展开解析：采集层建议用 OpenTelemetry 的 GenAI 语义约定（Langfuse、LangSmith 等也兼容）：每次 LLM 调用记录模型名、prompt 版本、输入输出 token 数、TTFT、总耗时、温度等参数；Agent 应用把整条 trace 串起来（span 树：规划→工具调用→生成）。指标看板至少包含：按功能拆分的 token 成本趋势、P50/P95 延迟、失败率（含超时、截断、schema 校验失败）、质量分（离线评测分 + 线上点赞率）。日志合规要注意：prompt 与输出可能含用户隐私，采集前脱敏或按租户隔离，采样存储控制成本。最后形成闭环：线上 bad case 一键回流到评测集，评测集驱动 prompt 与检索迭代——可观测性的终点是评测资产的积累。

追问方向：流式输出的延迟怎么统计？如何归因一次回答质量差是检索问题还是生成问题？

（约 470 字）