Micrometer、OpenTelemetry、Langfuse和自建审计表怎么选？AI可观测性架构指南

文章摘要企业AI应用上线后需要同时回答四类问题系统是否稳定、一次请求经过了哪些步骤、模型输出质量如何、每个租户花了多少钱。Micrometer擅长指标OpenTelemetry擅长跨服务TraceLangfuse等LLM Observability平台擅长Prompt、Generation与评测自建审计表则负责业务责任链和长期留档。它们不是简单替代关系。本文从指标基数、数据敏感性、Tool/RAG轨迹、成本、评测和合规等维度给出选型与组合方案。一、为什么传统APM不足以覆盖AI应用普通Web系统关注QPS 延迟 错误率 数据库 CPU 内存AI应用还需要知道使用了哪个模型 Prompt版本是什么 输入输出Token多少 调用了哪些工具 检索了哪些文档 模型为什么拒答 回答是否有证据 一次任务经历了多少模型轮次因此AI可观测性至少分四层系统指标 分布式轨迹 LLM语义轨迹 业务审计用一个工具强行覆盖四层往往会出现明显短板。二、Micrometer负责什么Micrometer是Spring生态中的应用指标门面。适合记录调用次数当前并发P50/P95/P99延迟Token计数429与5xxTool耗时VectorStore耗时熔断与降级次数。优点Spring Boot原生 Prometheus兼容 低运行成本 适合告警和Dashboard缺点不适合保存完整Prompt 不适合高基数用户轨迹 不适合阅读一次Agent的完整决策过程Micrometer回答的是整体系统现在是否健康三、OpenTelemetry负责什么OpenTelemetry统一Trace、Metrics和Logs的上下文传播。适合串联浏览器请求 → API Gateway → Spring Boot → ChatClient → RAG → Vector DB → Tool Service → 模型Provider它可以回答哪个服务最慢Trace在哪一步断开Tool调用是否跨服务失败同一个请求产生了几次模型调用网络和Provider耗时分别多少。优点厂商中立 跨语言 跨服务 支持Collector和多种后端缺点Span属性不适合无限放大文本 Prompt可视化体验有限 LLM评测能力通常需要额外平台OpenTelemetry回答的是这一次请求具体经过了哪里四、Langfuse类平台负责什么LLM Observability平台通常提供Prompt管理Generation记录SessionAgent TraceToken和成本DatasetLLM-as-a-Judge人工评分Prompt版本对比用户反馈。它更接近AI研发与质量运营平台适合回答哪个Prompt版本效果更好为什么任务失败RAG引用是否正确模型升级后质量是否下降哪类用户反馈最差Tool轨迹是否合理。优点面向LLM语义 评测与Dataset能力强 Prompt和Generation查看方便缺点可能涉及敏感数据外发 高调用量下存储成本高 仍不能替代Prometheus告警 业务审计通常不够严格它回答的是模型和Agent为什么给出了这个结果五、自建审计表负责什么审计表不是普通日志。它用于长期、不可抵赖地记录谁 在什么时候 以什么权限 提交了什么任务 模型建议了什么动作 谁批准 执行了什么工具 业务结果是什么典型字段CREATETABLEai_audit_event(idBIGINTPRIMARYKEY,request_idVARCHAR(64)NOTNULL,tenant_idVARCHAR(64)NOTNULL,user_idVARCHAR(64)NOTNULL,event_typeVARCHAR(64)NOTNULL,modelVARCHAR(128),prompt_versionVARCHAR(64),tool_nameVARCHAR(128),approval_idVARCHAR(64),result_statusVARCHAR(32),data_hashVARCHAR(128),created_atTIMESTAMPNOTNULL);审计表适合合同生成退款权限变更数据删除正式邮件招投标方案高风险决策支持。它回答的是谁应为这次AI驱动的业务行为负责六、四种方案对比维度MicrometerOpenTelemetryLLM平台审计表聚合指标强中中弱跨服务Trace弱强中弱Prompt查看不适合有限强按需Agent轨迹有限中强关键事件在线告警强中中弱评测弱弱强自建长期合规弱中中强高基数数据不适合Trace可用支持但成本高支持数据敏感性低内容化可配置需重点评估自主管理七、推荐的生产组合大多数企业项目不应该四选一而是Micrometer OpenTelemetry AI质量平台 业务审计但每层保存不同粒度。Micrometer只保存低基数指标model_tier business_scene status providerOpenTelemetry保存调用关系和有限高基数属性request_id conversation_id prompt_versionLLM平台保存经过脱敏的Prompt Completion RAG证据 Tool轨迹 评分审计表保存业务责任链和哈希身份 授权 批准 动作 结果八、数据敏感时怎么设计不要默认把完整Prompt发给外部平台。可以采用三级数据策略。Level 1只记录元数据长度 Hash Token 模型 耗时Level 2脱敏内容替换姓名手机身份证邮箱客户编号合同金额。Level 3完整内容只在专用私有部署获得授权严格保留期高权限访问条件下保存。九、RAG系统必须额外记录什么query rewritten_query retrieval_strategy top_k chunk_id document_version retrieval_score rerank_score context_order citation faithfulness_scoreMicrometer只统计检索耗时 查询次数 失败率具体召回了哪些文档应放Trace或AI质量平台。十、Agent系统必须额外记录什么step_no model_decision tool_name tool_arguments_hash tool_result_hash approval_status retry_count termination_reason一次Agent任务可能持续几十步。只看最终答案无法判断是否重复调用是否目标漂移是否绕过审批是否在错误结果上继续执行。十一、成本应该在哪一层计算实时监控MicrometerToken Counter 按模型估算成本 预算使用率单请求追踪Trace或LLM平台每次Generation成本 工具循环累计成本 缓存命中财务结算业务数据库租户月账单 用户配额 项目成本中心 内部计费不要依赖Prometheus做最终财务结算因为指标可能因采样、重启和保留策略不适合审计计费。十二、采样策略怎么定指标100%记录Trace可以按场景采样错误请求100% 高风险请求100% 普通成功请求5%—20% 慢请求100%Prompt与Completion按数据等级和质量需要测试环境较高比例 生产普通请求低比例脱敏 投诉与低评分请求100% 高风险业务按审计规则十三、什么时候只用Micrometer就够了适合内部Demo单模型问答没有Tool没有RAG不处理敏感业务只关心稳定性。十四、什么时候必须增加LLM质量平台Prompt频繁迭代多模型A/BRAG效果治理Agent多步骤需要Dataset和回归评测大量用户反馈团队需要查看Generation。十五、什么时候必须自建审计AI会修改业务数据涉及资金和合同有人工审批有监管要求需要长期追责用户可以申请导出或删除数据。十六、推荐落地顺序第一阶段 MicrometerPrometheus 第二阶段 OpenTelemetryTrace Backend 第三阶段 LLM质量平台Dataset 第四阶段 高风险业务审计表不要一开始就采集所有全文数据却没有明确使用场景。总结四类工具的分工可以概括为Micrometer → 系统是否健康 OpenTelemetry → 请求经过哪里 LLM Observability → 模型为什么这样回答 业务审计表 → 谁对这次业务行为负责企业AI可观测性真正需要的是分层组合而不是寻找一个包办所有问题的平台。