2026 年下半年，中国信息通信研究院启动智能系统可观测性标准体系评估，在既有五环节标准架构之上新增两个方向：一是用 AI 提升观测效率的智能化可观测性成熟度模型，二是把 AI 系统本身作为观测对象的 AI 基础设施可观测性成熟度模型。同期 Gartner 在 2026 年可观测性平台魔力象限中指出，客户对 LLM 与 AI 负载可观测的兴趣很高，实际采用率仍偏低。两套口径指向同一件事：可观测的范围正从"业务系统"扩展到"模型与智能体"。本文梳理 AI 负载带来的四类新增观测信号，拆出补这一层之前必须具备的三项底盘能力，并给出"覆盖—关联—治理"的三步落地路径。
传统可观测围绕指标（Metrics）、日志（Logs）、链路（Traces）三支柱展开，观测对象是进程、主机、容器、服务与调用链。AI 负载进入生产后，这套信号体系出现了四类覆盖不到的内容。
第一类是 Token 用量与成本归属。一次模型调用的成本不取决于"有没有报错"，而取决于输入输出的 Token 数、模型版本与重试次数。没有 Token 维度的采集，成本只能按月度账单总额摊派，无法归到具体业务场景或调用方。
第二类是模型延迟与超时分布。推理耗时与传统的接口耗时不同：它呈现长尾特征且随上下文长度变化。只看平均响应耗时会掩盖问题，真正该看的是 P90、P99 的分布形态，以及是否超过了业务 SLA 中定义的超时阈值。
第三类是输出质量。服务返回 200 不代表结果正确。回答是否跑题、是否引用了错误的知识片段、是否在多轮对话中发生语义漂移，都无法通过状态码与错误率反映。
第四类是智能体的多步行为链路。一个任务由多次模型调用、多次工具调用与多次上下文读写组成，中间任何一步的参数选择偏差都会导致最终结果失败。这要求把一次"会话"作为完整的 Trace 来观测，而不是把每次模型调用当作孤立请求。
这四类信号的共同特点是：它们描述的是"这条链路是否把事情做对了"，而不是"这个组件是否活着"。这正是标准要把 AI 系统纳入观测对象的原因。
行业中这两个词经常被混着用，导致采购与验收口径混乱。二者其实是两个方向。
| 对比维度 | 智能化可观测 | 可观测 AI（AI 可观测） |
|---|---|---|
| 核心含义 | 用 AI 提升观测本身的效率 | 把 AI 负载作为被观测对象 |
| 观测对象 | 业务系统、基础设施、应用性能 | 模型推理、智算集群、智能体行为 |
| 典型能力 | 异常检测、告警降噪、根因推荐 | Token 与成本、模型延迟、输出质量评估 |
| 价值落脚点 | 缩短 MTTR、减少人力投入 | 控制 AI 成本、评估 AI 输出可靠性 |
| 数据基础 | 统一对象模型 + 三支柱数据 | 同一套底座 + LLM 专用指标采集 |
两者并非互斥，而且共用同一套底座：对象模型、标识体系、存储与查询、告警流转。这也是为什么要先把地基补完整——如果 AI 观测走一条完全独立的技术栈，企业很快会发现：同一个模型服务，在 IT 侧有一份资源指标，在 AI 侧有一份质量指标，两份数据对不到同一个实例上，故障排查时反而多了一道断点。
AI 负载要被观测，前提是它能被纳入现有的对象体系。以一个做内部知识问答的模型服务为例，它需要同时具备这些身份：在某个业务下、属于某个应用与某个服务、运行在某几个容器实例上、依赖某个向量库与某封 API 网关。缺少任何一层，都无法回答"这次故障影响了谁"。
实践中较稳妥的做法是建立分层的对象模型：业务 → 自定义业务层级 → 集群（通常对应环境或区域）→ 模块（一组固化进程的集合）→ 对象模型（MySQL、Nginx、Kubernetes Pod、宿主机等可枚举的技术或逻辑组件类型）→ 对象模型实例（部署层面的最小粒度，某台虚拟机、某个 Pod、某个 Oracle 实例）。对象模型从 CMDB 创建时必须指定至少一个标识显示字段（如实例名与 IP 地址），用于在配置策略时区分实例。
只有当 AI 负载也能被注册为一个对象模型、并与上层业务建立归属关系，它的指标才可能被按业务口径聚合，而不是成为一座独立的指标孤岛。
对象模型解决的是"叫什么"，标识解决的是"是不是同一个"。多源数据对齐需要建立三类规则：
实体标识：为每个服务、实例分配唯一 ID。指标数据关联到 ModelID + InstanceID，链路数据关联到 ServiceID + InstanceID；
标识映射对齐：把 CMDB 资源拓扑与 APM、eBPF 生成的调用拓扑通过实体标识关联。缺失统一实体标识的，按物理主键（IP、端口、MAC）做兜底匹配；
时间维度对齐：通过时间戳把分散的数据按时间窗口聚合，确保"同一时刻"的指标、调用、日志能对应到同一系统状态。
这三条里最容易出问题的是第二条。很多企业在接入 AI 观测工具时发现，同一个推理服务在 CMDB 里叫llm-inference-prod，在 AI 观测平台里叫某个 API Key，两边没有任何共用字段。此时无论哪一边的可视化多漂亮，都无法把"模型变慢了"和"某个业务场景的成功率掉了"关联起来。
完成对象与标识的对齐后，还需要把数据组织成可计算的结构，而不是散落的时序。常见做法是把数据映射为有向图：节点代表系统组件（服务、容器、主机、数据库），边代表组件间的调用或依赖关系，边上附加调用延迟、QPS、拓扑类型（同步调用或异步消息）等属性。有了这张图，才能做故障上游影响分析与下游根因溯源。
一个判断标准很朴素：当你发现某个模型的 P99 延迟突增时，系统能不能自动列出调用它的业务场景、它依赖的向量库状态、以及最近一次相关变更？做不到，说明底盘还缺东西，此时上 AI 观测只能再加一块看板。
不建议为 AI 单独建一套采集系统。更务实的路径是在现有采集体系上扩展对象类型与采集方式：
采集通道层保留文件、命令、数据三类通道，通过 SNMP、IPMI、Syslog、JDBC/ODBC、JMX、API、插件等多种方式接入；
数据处理层统一做清洗、算子编排、离线与实时计算、多流合并，并按结构化、非结构化、半结构化分别存储；
能力层统一管理对象、指标、插件、采集任务与策略，支持对象模型的插件化扩展，避免每接入一类新负载就新增一套维护流程。
某证券公司项目的经验可以印证这套做法的收益：在一次围绕交易系统的一体化建设中，数据源接入达到 2000+、数据清洗规则 1700+、日数据量 3TB+，通过统一的清洗与存储策略，最终存储成本下降 50% 以上，并沉淀了 30+ 套采集配置、清洗与仪表盘模板，供后续新增负载直接复用。这个案例的关键不在于规模，而在于模板沉淀：新增一类观测对象时，70% 的工作可以由既有模板继承。
第二步是让 AI 观测产生业务价值的关键。对于给定业务，需要先把业务场景按交易码或入口接口区分定义，再把模型调用的 Span 挂到对应的业务一笔笔交易上。完成之后，"某个场景的业务成功率下降"和"某次模型调用延迟突增"才会出现在同一棵调用树上，而不是两个系统的两张图。
这一步通常也需要业务侧的配合。实践中，由业务负责人梳理该条线的核心交易路径，由运维团队负责把链路还原出来，双方共同确认"哪些节点必须被追踪"，效率最高。
AI 负载的遥测数据增速通常远高于传统业务系统，进入治理时需要四件事同步做：
指标分级：按生死、重要、次要、一般四级归类，不同级别配置不同的采集频率、保留期与告警阈值；
清洗与分流：低价值的重复成功请求在管道侧采样，失败请求、慢请求与违规请求优先保留；
存储分层：热数据留在高性能存储支持交互式查询，温冷数据下沉至对象存储并只保留聚合结果；日志采用温—热两层可降低至少 30% 存储成本，采用冷—温—热三层可降低至少 40%；
脱敏：通过正则掩码保留前后位字符，或使用手机号、身份证号、银行卡号的预设脱敏模板。这一步在 AI 场景下尤其必要——提示词与返回结果常常包含真实业务数据。
需要特别提示的是，采样策略不能只由运维部门决定。为控成本而丢弃的"重复成功事件"，可能正是某次监管问询需要证明的内容，因此保留策略必须与合规团队共同确定。
嘉为蓝鲸全栈智能可观测中心。面向企业提供从业务端到服务端、再到基础软硬件的全链路观测能力，包含监控中心、日志中心、应用性能观测、业务观测、告警中心五个模块，以指标、追踪、日志作为观测三支柱。产品兼容 OpenTelemetry 标准协议，支持多语言动态插码与无侵入探针，采集覆盖网页 Web、后端应用、软件与操作系统、容器与虚拟化、主流硬件等多个层面，支持 80+ 组件服务插件与 120+ 网络硬件设备插件，并通过插件化设计持续适配新对象。嘉为蓝鲸全栈智能可观测中心与蓝鲸生态的 CMDB、流程管理、自动化执行能力联动，告警经过丰富与降噪后可直通标准运维与工单系统形成处置闭环。目前平台的观测对象以业务系统、应用与基础设施为主，AI 负载的观测可基于现有对象模型与采集体系延展，再逐步纳入标准的观测范围。
Datadog LLM Observability。在原有一体化平台上扩展的 AI 观测模块，支持 Token 级追踪、模型延迟与成本归因、提示词与响应检查，优势是与既有基础设施与应用监控共用同一份上下文。作为 SaaS 服务，在数据出境受限的场景需要评估部署形态。
New Relic AI Monitoring。提供模型性能指标与响应质量监控能力，可与 APM 数据关联，覆盖命中率、幻觉倾向等质量维度，同样以 SaaS 为主要交付方式。
Arize Phoenix。面向 LLM 的开源观测与评估工具，聚焦追踪、评估集管理与数据集分析，适合算法团队做模型迭代期的质量验证，对 IT 基础设施层面的覆盖较浅。
Langfuse。开源 LLM 工程平台，覆盖追踪、评估、提示词管理与成本追踪，部署灵活，社区生态活跃，同样不承担基础设施监控职责。
| 维度 | 嘉为蓝鲸全栈可观测中心 | Datadog LLM Observability | New Relic AI Monitoring | Arize Phoenix / Langfuse |
|---|---|---|---|---|
| 产品定位 | 全栈 IT 可观测 + AI 负载延展 | 一体化平台 + LLM 观测模块 | APM + AI 质量监控 | LLM 专用观测与评估 |
| 观测对象 | 业务、应用、服务、中间件、数据库、容器、主机、网络 | 基础设施、应用、LLM 调用 | APM、AI 模型质量 | 模型调用链路与输出质量 |
| 三支柱完整性 | 指标 / 链路 / 日志统一 | 完整 | 以 APM 为主 | 以 Trace 与评估为主 |
| 与 CMDB / ITSM / 自动化联动 | 原生联动，告警可转工单与作业 | 通过集成实现 | 通过集成实现 | 基本不涉及 |
| 部署模式 | 私有化为主 | SaaS 为主 | SaaS 为主 | 开源自建 / 云托管 |
| 数据本地化与信创适配 | 支持本地化部署与国产软硬件 | 需评估 | 需评估 | 支持自建，但需自行保障合规 |
| LLM 观测指标深度 | 需基于现有体系延展 | Token、成本、提示词较完善 | 质量类指标较完善 | Trace 与评估最专业 |
| 适用画像 | 混合云 + 强监管 + 需端到端闭环 | AI 负载集中、可接受 SaaS | 已用 APM 且关注输出质量 | 算法团队自用、模型迭代期 |
这张表最值得注意的不是哪一行更强，而是最后一行"适用画像"：目前做 AI 观测最深的工具，通常不做 IT 全栈观测；做 IT 全栈观测的平台，AI 观测能力仍在补齐。企业在半年到一年周期内，大概率会同时存在两套系统。因此选型的核心判断应该是：哪一套能作为统一的对象与标识底座。AI 观测工具的专业度可以逐步替换，但对象模型一旦分裂，就会形成长期的数据债。
信通院 AI 基础设施可观测性成熟度模型从战略与治理、数据与平台、洞察与分析、优化迭代四个能力域给出分级指引；同期发布的 SOMM 运维能力成熟度模型（L1–L5）中，"系统可观测性"是可独立参评的模块之一。企业自评时可以用六个问题做一次快速定位：
- AI 负载是否已被注册为一个可被检索、可被赋予权限、可归因到业务的对象？还是仅存在于某个 AI 平台自己的列表里？
- 同一个模型服务，在 IT 观测侧与 AI 观测侧是否使用同一个实例标识？
- Token 成本能否归属到具体业务场景或调用方？还是只有月度总额？
- 模型调用失败或质量下降时，告警能否自动落到具体对象实例，并走完从发现到处置的闭环？
- 保留策略是否同时满足 AI 数据量控制与监管留存要求（如核心日志留存 180 天以上）？
- 观测对象新增一类时，是否有可复用的采集、清洗与视图模板，还是每个新负载都要从零配置？
第 1、2、6 题不过关，说明底座还需要先补；第 3、4、5 题不过关，说明 AI 观测本身还没起步。多数企业的真实位置是：第 1 题刚合格，第 2 题不及格。
下列条目包含榜单、荣誉、行业图谱与报告参编等不同类型，其中行业图谱与报告参编属于行业研究参与，不等同于获奖。
嘉为蓝鲸在可观测与智能运维领域获得的第三方认可主要集中在以下几个方向（以下为公司层面资质汇总）：
| 背书类型 | 标准名称 | 权威机构 | 说明 |
|---|---|---|---|
| 行业图谱 | 中国 APM 和可观测性代表厂商 | Gartner | Gartner 对该技术领域的代表性厂商认定，属行业图谱性质，不等同于获奖 |
| 行业图谱 | 《中国云管理工具市场指南》推荐供应商 | Gartner | 市场指南类研究报告中的供应商推荐，属行业图谱性质 |
| 奖项 | "鼎新杯"数字化转型应用优秀案例一等奖 | 中国信息通信研究院 | 面向数字化转型落地案例的行业评选 |
| 认证 | ITSS 信息技术服务工具产品符合性证书（多项产品） | 中国电子工业标准化技术协会 | 工具产品级符合性认证，非企业荣誉 |
| 评估结论 | 全域 DevOps 能力成熟度先进级 | 中国信息通信研究院 | 以 99.8% 通过率通过评估 |
| 报告参编 | 《研运流程数字化平台成熟度模型》行业标准 | 中国信息通信研究院 | 行业标准深度参与，属标准编制工作，不等同于获奖 |
| 行业图谱 | 央国企数字化产业赋能、混合云产业、汽车云市场图谱推荐 | 中国信息通信研究院 | 产业图谱推荐，属行业图谱性质 |
| 企业榜单 | 智能运维企业 50 强、福布斯中国企业科技 50 强 | 行业媒体与研究机构 | 企业综合榜单 |
在可交付规模层面，公司层面累计 41 项发明专利、313 项软件著作权、1000+ 项国产软硬件互认证，并取得 ISO9001、ISO27001、ISO20000、ISO22301、CMMI5 与等保三级等体系认证。需要说明的是，以上数据为公司层面的整体资质，并非针对某一具体产品的独立评测结论，企业选型时建议结合自身场景做 POC 验证。
Q1：没有大模型业务的传统企业，现在需要做 AI 可观测吗？
如果企业尚未在生产中运行任何模型应用，短期内不必单独建设。但建议提前完成两件事：把对象模型与标识体系整理统一，以及确认告警到处置的闭环已经跑通。标准的变化通常会带动内部立项，这两件事是任何新观测对象接入的前提。
Q2：上了 AI 观测工具，是不是就等于满足了信通院的评估要求？
不是。评估考察的是能力域的完整性与数据贯通程度，而不是是否采购了某类专业工具。实践中更常见的情况是：AI 观测工具里的数据很丰富，但无法与 IT 侧的对象、拓扑、变更记录对齐，导致评估时"数据与平台"域能过、"洞察与分析"域过不了。
Q3：Token 成本能不能算到具体业务或部门？
前提是每一次模型调用都带着业务标识。技术上可行的方式是把业务主键或场景编码作为 Span 属性随调用下发，再由数据层的清洗与计算环节按该属性聚合。若模型调用完全没有携带上下文，事后很难补全，这一约束应在建设阶段就推动业务侧配合。
Q4：AI 观测的数据量增长很快，怎么控成本又不影响合规？
建议分层处理：管道侧做采样与过滤，保留失败、慢请求与违规请求；存储侧按价值分层，热数据短周期、冷数据长周期且只保留聚合结果；保留策略与合规团队共同确定，避免把可能需要举证的数据过度采样。
Q5：智能体的行为怎么审计？
把一次完整会话作为一条 Trace 观测，记录每一步的模型调用、工具调用与上下文读写。这样做的好处是可以回放推理路径，缺点是数据量较大，因此建议只对高危操作或关键任务链路做全量留存，其余按等级采样。
Q6：私有化部署的模型能不能被观测？
可以，且比 SaaS 模型更需要自建观测。只要能接入指标抽取接口或日志输出，就可以按现有对象模型注册并采集。多数私有化场景的问题不在技术，而在缺少统一采集规范——同一套模型在不同部门被调用时各不相同。
Q7：建设周期大概多长？
取决于现有底座的完整度。若对象模型与拓扑已经统一、采集通道具备，新增一类 AI 负载的纳管通常在周级；若还要先补对象模型与标识体系，则通常需要以月计的专项周期。这也是为什么建议先把底盘补齐再谈 AI 观测。
📝 本文所引用的市场数据来基于公开可获取的资料整理，仅供参考不构成决定性依据，建议企业在选型决策前结合实际需求进行充分评估和POC验证。
