Langfuse、OpenTelemetry 与 Prometheus：分别监控什么？
码海寻道 · 大模型、智能体与 RAG 工程组件系列第 47 篇
三者都能出现在 AI 应用的监控架构里，但职责不同：Langfuse 更关注 LLM 调用和评估，OpenTelemetry 负责统一采集和传播遥测信号，Prometheus 擅长指标时序和告警。
一、先按观测对象区分
一次用户问答 ├── Langfuse：Prompt、模型、Token、评估分数 ├── OpenTelemetry：跨服务 Trace、Span、Logs、Metrics └── Prometheus：QPS、错误率、延迟、资源和告警指标它们可以互补，不是简单的三选一。
二、Langfuse 适合看什么？
适合 LLM 应用层的细节：
- 一次会话和一次运行；
- Prompt、模型、参数和输出；
- Embedding、检索、Reranker 和工具调用；
- 输入输出 Token 和成本；
- 用户反馈与评估分数；
- Prompt 版本和实验对比。
当用户说“答案不对”时，Langfuse 可以帮助查看该请求实际使用了哪个 Prompt、召回了哪些内容、调用了几次模型。
三、OpenTelemetry 适合看什么？
OpenTelemetry 提供统一的 Traces、Metrics 和 Logs 采集规范与 SDK/Collector 生态。它更关心请求如何穿过多个服务：
API Gateway → FastAPI → Redis → Milvus → Embedding Provider → LLM Provider通过trace_id和 Span，可以看到每一段耗时、错误和父子关系。它不限定你最终使用哪种后端存储。
四、Prometheus 适合看什么？
Prometheus 以时间序列保存指标，适合：
- 请求量和错误率；
- P50/P95/P99 延迟；
- 队列积压；
- CPU、内存、连接池；
- Redis、PostgreSQL、Milvus 状态；
- 告警规则和容量趋势。
例如：
http_requests_total{service="rag-api",status="500"} rag_request_duration_seconds{route="/chat"} rag_queue_depth{queue="embedding"}五、三者如何组合？
应用代码 ├── OpenTelemetry SDK → Collector → Trace/Logs/Metrics 后端 ├── Langfuse SDK → LLM 观测与评估平台 └── Prometheus endpoint → Prometheus → Alertmanager/Grafana可以把同一个trace_id写入业务日志和 Langfuse 观测，发生问题时从系统指标跳转到具体 LLM 调用。
建议统一一组低基数的业务字段，例如service_name、environment、model_name、route、status和tenant_tier；将run_id、文档版本、检索参数和错误详情放入 Trace 属性或日志。OpenTelemetry 负责跨服务传播上下文，Langfuse 记录模型调用细节，Prometheus 只保留适合聚合和告警的指标，三者不要各自生成一套无法关联的 ID。
六、不要把完整 Prompt 无控制地写入监控
Prompt 和输出可能包含个人信息、商业秘密和用户上传文档。应支持：
- 脱敏；
- 采样；
- 敏感字段屏蔽；
- 租户访问隔离；
- 保留周期；
- 调试环境和生产环境不同策略。
观测系统本身也是数据副本，需要遵守权限和合规要求。
生产环境应设置采样、保留和删除策略：成功请求可以低比例采样，错误、超时和高风险操作提高采样率；Prompt、文档片段、用户问题和模型输出按字段脱敏或哈希化。观测平台的访问权限应与业务数据隔离，排障人员不应因为能看 Trace 就自动获得原文下载权限。
七、指标命名和标签设计
指标标签要低基数，避免把user_id、query、完整document_id直接作为 Prometheus label：
推荐：service、route、status、model、environment 谨慎：tenant_id、document_id、trace_id 禁止：原始问题、完整 Prompt、长文本高基数数据应放在日志或 Trace 属性中，并控制采样。
八、建议的核心观测指标
业务层
- 问答成功率；
- 空结果率；
- 引用命中率；
- 用户点赞/点踩；
- 转人工率。
链路层
- Embedding、检索、Reranker、LLM 各阶段延迟；
- 工具调用错误率；
- 超时和取消率；
- Trace 缺失率。
基础设施层
- CPU、内存、磁盘和网络；
- 数据库连接池；
- 队列深度；
- Redis 命中率；
- Milvus 查询延迟。
九、告警要面向行动
好的告警应该回答：哪里坏了、影响谁、应该怎么处理。例如：
RAG 检索 P95 延迟连续 10 分钟超过 800ms，影响 production，检查 Query Node 和过滤条件。不要为每个瞬时抖动发送告警。设置持续时间、分级和维护窗口，避免告警疲劳。
每条告警要绑定 Runbook 或处理动作，例如“P95 检索延迟升高”对应检查向量库负载、索引版本和降级开关；“越权拦截率异常”对应冻结高风险工具、保留审计证据并启动安全排查。没有处理路径的指标不应直接升级成紧急告警。
结语
Langfuse 观察 LLM 应用细节，OpenTelemetry 连接跨服务可观测链路，Prometheus 管理指标和告警。三者组合后，既能知道系统是否变慢，也能追到某次回答为什么错误、花了多少 Token。
下一篇将具体拆解 RAG 的召回率、忠实度、相关性和答案准确率。
参考资料
- Langfuse 官方文档：Observability
- OpenTelemetry 官方文档：Semantic Conventions
- Prometheus 官方文档：Overview
本文为“码海寻道”原创技术文章。监控标签、采样和数据保留策略需要结合系统规模、隐私和成本要求设计。
