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/
智元界将持续分享可运行的技术实战、架构设计、问题排查与企业应用案例。