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

文章摘要

企业AI应用上线后,需要同时回答四类问题:系统是否稳定、一次请求经过了哪些步骤、模型输出质量如何、每个租户花了多少钱。Micrometer擅长指标,OpenTelemetry擅长跨服务Trace,Langfuse等LLM Observability平台擅长Prompt、Generation与评测,自建审计表则负责业务责任链和长期留档。它们不是简单替代关系。本文从指标基数、数据敏感性、Tool/RAG轨迹、成本、评测和合规等维度给出选型与组合方案。

一、为什么传统APM不足以覆盖AI应用

普通Web系统关注:

QPS
延迟
错误率
数据库
CPU
内存

AI应用还需要知道:

使用了哪个模型
Prompt版本是什么
输入输出Token多少
调用了哪些工具
检索了哪些文档
模型为什么拒答
回答是否有证据
一次任务经历了多少模型轮次

因此,AI可观测性至少分四层:

系统指标
分布式轨迹
LLM语义轨迹
业务审计

用一个工具强行覆盖四层,往往会出现明显短板。

二、Micrometer负责什么

Micrometer是Spring生态中的应用指标门面。

适合记录:

  • 调用次数;
  • 当前并发;
  • P50/P95/P99延迟;
  • Token计数;
  • 429与5xx;
  • Tool耗时;
  • 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记录;
  • Session;
  • Agent Trace;
  • Token和成本;
  • Dataset;
  • LLM-as-a-Judge;
  • 人工评分;
  • Prompt版本对比;
  • 用户反馈。

它更接近:

AI研发与质量运营平台

适合回答:

  • 哪个Prompt版本效果更好;
  • 为什么任务失败;
  • RAG引用是否正确;
  • 模型升级后质量是否下降;
  • 哪类用户反馈最差;
  • Tool轨迹是否合理。

优点:

面向LLM语义
评测与Dataset能力强
Prompt和Generation查看方便

缺点:

可能涉及敏感数据外发
高调用量下存储成本高
仍不能替代Prometheus告警
业务审计通常不够严格

它回答的是:

模型和Agent为什么给出了这个结果?

五、自建审计表负责什么

审计表不是普通日志。

它用于长期、不可抵赖地记录:

谁
在什么时候
以什么权限
提交了什么任务
模型建议了什么动作
谁批准
执行了什么工具
业务结果是什么

典型字段:

CREATE TABLE ai_audit_event (
    id BIGINT PRIMARY KEY,
    request_id VARCHAR(64) NOT NULL,
    tenant_id VARCHAR(64) NOT NULL,
    user_id VARCHAR(64) NOT NULL,
    event_type VARCHAR(64) NOT NULL,
    model VARCHAR(128),
    prompt_version VARCHAR(64),
    tool_name VARCHAR(128),
    approval_id VARCHAR(64),
    result_status VARCHAR(32),
    data_hash VARCHAR(128),
    created_at TIMESTAMP NOT NULL
);

审计表适合:

  • 合同生成;
  • 退款;
  • 权限变更;
  • 数据删除;
  • 正式邮件;
  • 招投标方案;
  • 高风险决策支持。

它回答的是:

谁应为这次AI驱动的业务行为负责?

六、四种方案对比

维度 Micrometer OpenTelemetry LLM平台 审计表
聚合指标
跨服务Trace
Prompt查看 不适合 有限 按需
Agent轨迹 有限 关键事件
在线告警
评测 自建
长期合规
高基数数据 不适合 Trace可用 支持但成本高 支持
数据敏感性 低内容化 可配置 需重点评估 自主管理

七、推荐的生产组合

大多数企业项目不应该四选一,而是:

Micrometer
+OpenTelemetry
+AI质量平台
+业务审计

但每层保存不同粒度。

Micrometer

只保存低基数指标:

model_tier
business_scene
status
provider

OpenTelemetry

保存调用关系和有限高基数属性:

request_id
conversation_id
prompt_version

LLM平台

保存经过脱敏的:

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_score

Micrometer只统计:

检索耗时
查询次数
失败率

具体召回了哪些文档应放Trace或AI质量平台。

十、Agent系统必须额外记录什么

step_no
model_decision
tool_name
tool_arguments_hash
tool_result_hash
approval_status
retry_count
termination_reason

一次Agent任务可能持续几十步。

只看最终答案无法判断:

  • 是否重复调用;
  • 是否目标漂移;
  • 是否绕过审批;
  • 是否在错误结果上继续执行。

十一、成本应该在哪一层计算

实时监控

Micrometer:

Token Counter
按模型估算成本
预算使用率

单请求追踪

Trace或LLM平台:

每次Generation成本
工具循环累计成本
缓存命中

财务结算

业务数据库:

租户月账单
用户配额
项目成本中心
内部计费

不要依赖Prometheus做最终财务结算,因为指标可能因采样、重启和保留策略不适合审计计费。

十二、采样策略怎么定

指标

100%记录

Trace

可以按场景采样:

错误请求:100%
高风险请求:100%
普通成功请求:5%—20%
慢请求:100%

Prompt与Completion

按数据等级和质量需要:

测试环境:较高比例
生产普通请求:低比例脱敏
投诉与低评分请求:100%
高风险业务:按审计规则

十三、什么时候只用Micrometer就够了

适合:

  • 内部Demo;
  • 单模型问答;
  • 没有Tool;
  • 没有RAG;
  • 不处理敏感业务;
  • 只关心稳定性。

十四、什么时候必须增加LLM质量平台

  • Prompt频繁迭代;
  • 多模型A/B;
  • RAG效果治理;
  • Agent多步骤;
  • 需要Dataset和回归评测;
  • 大量用户反馈;
  • 团队需要查看Generation。

十五、什么时候必须自建审计

  • AI会修改业务数据;
  • 涉及资金和合同;
  • 有人工审批;
  • 有监管要求;
  • 需要长期追责;
  • 用户可以申请导出或删除数据。

十六、推荐落地顺序

第一阶段
Micrometer+Prometheus

第二阶段
OpenTelemetry+Trace Backend

第三阶段
LLM质量平台+Dataset

第四阶段
高风险业务审计表

不要一开始就采集所有全文数据,却没有明确使用场景。

总结

四类工具的分工可以概括为:

Micrometer
→ 系统是否健康

OpenTelemetry
→ 请求经过哪里

LLM Observability
→ 模型为什么这样回答

业务审计表
→ 谁对这次业务行为负责

企业AI可观测性真正需要的是分层组合,而不是寻找一个包办所有问题的平台。

延伸阅读

如果你正在关注企业级 AI 应用、Spring AI、RAG、Agent 与 MCP 工程化落地,欢迎访问 智元界

https://www.zyentor.com/

智元界将持续分享可运行的技术实战、架构设计、问题排查与企业应用案例。