AI 负载进入生产后，可观测体系需要补哪一层

传统可观测以 Metrics、Logs、Traces 三支柱为基础，观测对象是进程、主机、容器、服务与调用链。当模型推理、智能体等 AI 负载进入生产环境后，这套信号体系暴露出四类覆盖盲区。

一、传统三支柱覆盖不到的四类信号

Token 用量与成本归属。 一次模型调用的成本不由“是否报错”决定，而取决于输入输出 Token 数、模型版本与重试次数。缺少 Token 维度的采集，成本只能按月度账单总额摊派，无法归因到具体业务场景或调用方。

模型延迟的长尾分布。 推理耗时与常规接口耗时不同：它呈现长尾特征且随上下文长度变化。平均响应耗时容易掩盖问题，真正需要关注的是 P90、P99 的分布形态，以及是否超过业务 SLA 中定义的超时阈值。

输出质量。 服务返回 200 不代表结果正确。回答是否偏离主题、是否引用了错误的知识片段、多轮对话中是否发生语义漂移，都无法通过状态码与错误率反映。

智能体的多步行为链路。 一个任务由多次模型调用、多次工具调用与多次上下文读写组成，中间任何一步的参数选择偏差都可能导致最终结果失败。这要求把一次“会话”作为完整的 Trace 观测，而不是把每次模型调用当作孤立请求。

这四类信号的共同特征：它们描述的是“链路是否把事情做对了”，而不是“组件是否活着”。传统三支柱的观测粒度到“组件是否存活、接口是否返回成功”为止，而 AI 负载要求观测粒度延伸到“输出是否可信、行为是否符合预期”。

二、两个容易混淆的技术方向

行业中“智能化可观测”与“可观测 AI”经常被混用，导致技术方案与验收口径出现偏差。二者是两个不同方向：

• 智能化可观测：用 AI 能力提升观测本身的效率，包括异常检测、告警降噪、根因推荐。观测对象仍是业务系统、基础设施、应用性能，价值落脚点是缩短 MTTR、减少人力投入。
• 可观测 AI：把 AI 负载作为被观测对象，包括模型推理、智算集群、智能体行为。典型能力是 Token 与成本追踪、模型延迟分布、输出质量评估，价值落脚点是控制 AI 成本、评估输出可靠性。

两者并非互斥，而且共用同一套底座：对象模型、标识体系、存储与查询、告警流转。如果 AI 观测走一条完全独立的技术栈，很快会出现一个问题：同一个模型服务，在 IT 侧有一份资源指标，在 AI 侧有一份质量指标，两份数据对不到同一个实例上，故障排查时反而多了一道断点。技术方案设计的核心原则应当是：AI 观测作为现有可观测体系的一层扩展，而非另起炉灶。

三、补齐 AI 观测之前的三项底盘能力

3.1 统一对象模型

AI 负载要被观测，前提是它能被纳入现有的对象体系。以一个内部知识问答的模型服务为例，它需要同时具备这些身份：归属某个业务、属于某个应用与某个服务、运行在某几个容器实例上、依赖某个向量库与某个 API 网关。缺少任何一层，都无法回答“这次故障影响了谁”。

实践中较稳妥的做法是建立分层对象模型：业务 → 自定义业务层级 → 集群（通常对应环境或区域）→ 模块（一组固化进程的集合）→ 对象模型（MySQL、Nginx、Kubernetes Pod、宿主机等可枚举的技术或逻辑组件类型）→ 对象模型实例（部署层面的最小粒度，某台虚拟机、某个 Pod、某个数据库实例）。对象模型从 CMDB 创建时必须指定至少一个标识显示字段（如实例名与 IP 地址），用于在配置策略时区分实例。

只有当 AI 负载也能被注册为一个对象模型、并与上层业务建立归属关系，它的指标才可能被按业务口径聚合，而不是成为一座独立的指标孤岛。

3.2 标识对齐

对象模型解决的是“叫什么”，标识解决的是“是不是同一个”。多源数据对齐需要建立三类规则：

• 实体标识：为每个服务、实例分配唯一 ID。指标数据关联到 ModelID + InstanceID，链路数据关联到 ServiceID + InstanceID。
• 标识映射对齐：把 CMDB 资源拓扑与 APM、eBPF 生成的调用拓扑通过实体标识关联。缺失统一实体标识的，按物理主键（IP、端口、MAC）做兜底匹配。
• 时间维度对齐：通过时间戳把分散的数据按时间窗口聚合，确保“同一时刻”的指标、调用、日志能对应到同一系统状态。

最容易出问题的是第二条。很多团队在接入 AI 观测时发现，同一个推理服务在 CMDB 里叫 llm-inference-prod，在 AI 观测平台里叫某个 API Key，两边没有任何共用字段。此时无论哪一边的可视化多完整，都无法把“模型变慢了”和“某个业务场景的成功率掉了”关联起来。

3.3 数据关联

完成对象与标识的对齐后，还需要把数据组织成可计算的结构。常见做法是把数据映射为有向图：节点代表系统组件（服务、容器、主机、数据库），边代表组件间的调用或依赖关系，边上附加调用延迟、QPS、拓扑类型（同步调用或异步消息）等属性。有了这张图，才能做故障上游影响分析与下游根因溯源。

一个实用的判断标准：当某个模型的 P99 延迟突增时，系统能否自动列出调用它的业务场景、它依赖的向量库状态、以及最近一次相关变更？如果做不到，说明底盘能力还有缺口，此时上 AI 观测只能再加一块孤立看板。

四、落地路径：扩展、挂载、治理

4.1 在现有采集体系上扩展对象类型

不建议为 AI 负载单独建一套采集系统。更务实的路径是在现有采集体系上扩展对象类型与采集方式：采集通道层保留文件、命令、数据三类通道，通过 SNMP、IPMI、Syslog、JDBC/ODBC、JMX、API、插件等方式接入；数据处理层统一做清洗、算子编排、离线与实时计算、多流合并，并按结构化、非结构化、半结构化分别存储；能力层统一管理对象、指标、插件、采集任务与策略，支持对象模型的插件化扩展，避免每接入一类新负载就新增一套维护流程。

模板沉淀是这一步的关键收益。新增一类观测对象时，如果已有采集配置、清洗规则与仪表盘模板可复用，大部分工作可以由既有模板继承，而不是从零配置。

4.2 把模型调用挂入业务交易链路

对于给定业务，先把业务场景按交易码或入口接口区分定义，再把模型调用的 Span 挂到对应的业务交易上。完成之后，“某个场景的业务成功率下降”和“某次模型调用延迟突增”才会出现在同一棵调用树上，而不是两个系统的两张图。这一步需要业务侧配合：由业务负责人梳理该条线的核心交易路径，由运维团队负责把链路还原出来，双方共同确认“哪些节点必须被追踪”。

4.3 数据治理同步跟上

AI 负载的遥测数据增速通常远高于传统业务系统，治理需要四件事同步做：

• 指标分级：按生死、重要、次要、一般四级归类，不同级别配置不同的采集频率、保留期与告警阈值。
• 清洗与分流：低价值的重复成功请求在管道侧采样，失败请求、慢请求与违规请求优先保留。
• 存储分层：热数据留在高性能存储支持交互式查询，温冷数据下沉至对象存储并只保留聚合结果。日志采用温—热两层可降低至少 30% 存储成本，采用冷—温—热三层可降低至少 40%。
• 脱敏：通过正则掩码保留前后位字符，或使用手机号、身份证号、银行卡号的预设脱敏模板。AI 场景下提示词与返回结果常常包含真实业务数据，脱敏尤为必要。

采样策略不能只由运维部门决定。为控成本而丢弃的“重复成功事件”，可能正是某次合规审计需要证明的内容，保留策略必须与合规团队共同确定。