1. 项目背景"CTO 在周一早会上点名了——‘AI 客服上周五下午慢了 3 个小时，用户投诉爆了，你们运维团队居然最后一个知道？’"小陈羞愧地低下了头。他确实不知道——Dify 控制台的"日志"页只显示消息数量和 Token 消耗，没有任何性能指标。用户说慢，他只能靠感觉猜测：是 LLM 调用慢了？数据库满了？还是服务器 CPU 飙了？直到他搭了 Prometheus + Grafana，才发现真相：周五下午 2 点，知识库从 5 万条涨到了 50 万条（运营批量导入了产品文档），向量检索延迟从 50ms 暴涨到 800ms，拖慢了整个 Chat 响应链。如果他早就有 Grafana 上的"检索延迟"指标——他在 2:05 就能发现问题，而不是等用户骂了 3 个小时。这个教训教会了小陈一件事：没有监控的 AI 系统就是在裸奔。Dify 的基础设施层已经为可观测性做好了充分准备——集成了 OpenTelemetry 自动链路追踪，可以把 Trace 数据发送到 Langfuse；暴露了/health端点和 Prometheus 指标；支持 Sentry 异常追踪。但 Dify 本身不提供监控面板——意思是"数据都有，你得自己搭界面来看"。本章搭建一套三位一体的可观测性体系，解决三个核心问题：①系统整体健不健康？（Prometheus + Grafana 的 RED 指标——Rate/QPS、Errors/错误率、Duration/延迟）②具体哪个请求慢、慢在哪？（OpenTelemetry + Langfuse 的全链路 Trace）③哪里出 bug 了？（Sen
