Observability

3 秒看懂

可观测性（Observability）是衡量一个系统能否仅通过其外部输出——即遥测数据——推断其内部运行状态的工程指标。

在分布式软件和 AI 基础设施中，这一能力建立在三大支柱之上：日志（Logs） 提供带时间戳的离散事件记录；指标（Metrics） 以数值形式对系统某一时刻的状态进行聚合度量；分布式追踪（Traces） 则串联起一次请求在跨越多个服务、进程、节点时的完整调用路径。三者叠加，使得平台工程师、SRE 或 AI 训练集群的运维者，无需修改任何系统代码，即可向系统提出“为什么这条训练任务突然挂起”“为什么我的 GPU 集群利用率在凌晨三点突然掉零”等任意临时命题，并快速逼近根因。

对于读者来说，最简单的理解是将“传统监控”与“可观测性”做一区分：前者如同汽车的仪表盘——只显示水温、转速、油量等预设指标，一旦某个传感器失效或发生不在预设清单内的故障，仪表盘便无法给出有效指引；后者则更像给整辆车接上了诊断仪，你可以根据当前的故障现象，动态地查询任意节点、任意通信环节的实时与近期状态，沿着因果链逐层下钻，而不必依赖提前设想好的告警模板。

在 AI 原生基础设施（AI-Native Infrastructure）的语境中，可观测性的价值更为直接：一次千卡级、万亿参数规模的训练任务，其失败原因可能根植于显存碎片化、慢节点（straggler）、网络微突发（microburst）、拓扑环路中的 NCCL 死锁等极其隐蔽的角落。具备良好可观测性的集群，能将此类问题的平均修复时间从数小时甚至数天缩短到分钟级，直接决定模型产出的速度与成本。

3 分钟产业解释

从产业视角审视，可观测性今天的定位已不再是一项单纯的技术辅助手段，而是正在成长为云原生与 AI 基础设施层中的独立软件品类与工程准则。

传统运维与监控工具的巅峰形态，大致体现为以 Nagios、Zabbix 为代表的第一代产品：它们通过预设阈值、已知的故障模式定义规则，并在指标偏离预定区间时触发告警。这一范式在相对静态的物理机、单体应用时代尚足以应付，但进入微服务、容器编排、弹性扩缩容占主导地位的云原生时代后，其局限性暴露无疑：故障模式从“已知的已知”大面积转向“未知的未知”，运维人员甚至无法事先穷尽到底该监控哪些端口、哪些进程间通信异常能导致业务中断。

可观测性工程（Observability Engineering）则通过将系统输出标准化为日志、指标、追踪三种信号，并借助统一的数据采集、传输、存储与查询层，使得运维者和开发者可以在故障发生之后，以一种“假设驱动”的方式与系统对话。一个典型的排查路径可能是：

1. 从告警或指标仪表盘发现某训练 Job 的 P99 迭代延迟突增 3 倍；
2. 单击该异常时间段对应的指标曲线，切入该时间段内未被采样的错误 Trace；
3. 根据 Trace ID 关联出训练调度器、参数服务器节点及具体 Worker 对应的结构化日志行；
4. 在日志中发现某一条 NCCL AllReduce 操作在 Ring 拓扑的第三跳上耗时由常规的 200μs 剧增至 12s，同时伴随“nv_link_error”关键字；
5. 最终定位为某个 GPU 上的 NVLink 降级，导致整条通信环严重阻塞。

这种“从聚合指标到单体追踪再到离散日志”的交互式下钻，本质上不同于传统监控中“盯着仪表盘等待某个红线被触及”。对于一个技术组织而言，引入可观测性并不只是多部署几套开源工具，而是需要从仪器化（Instrumentation）标准、采集策略、采样策略到后端存储、可视化与告警的全面工程化与平台化。

在 AI/ML 训练场景，这一需求的紧迫性被进一步放大。根据多家公有云厂商与大规模 AI 实验室的白皮书与公开技术博文[¹]显示，当训练集群从数百张 GPU 扩展到数千张乃至万卡级时，因慢节点、通信瓶颈或节点间时钟漂移导致的训练停滞并不呈线性增长，而是非线性、间歇性地出现。传统的 GPU 使用率、CPU 负载指标完全无法捕捉这些问题。能够追踪每一次 AllReduce、AllGather 操作耗时，并将其与对应的网络瞬时延迟、显存温度、GPU SM Clock 等指标关联起来的工具链，正从“锦上添花”升级为“任务交付的前提条件”。

在市场与资本层面，可观测性已经形成了一个独立的软件赛道，涵盖了从开源社区驱动的 OpenTelemetry 数据采集标准，到 Datadog、Splunk、Dynatrace 等商业 SaaS 产品，再到以 Grafana Labs 为代表的开放核心（Open Core）商业模式。与此同时，传统 IT 运维工具（如 SolarWinds、BMC）和云服务商原生监控（如 AWS CloudWatch、Azure Monitor）也在积极向可观测性方向演进，整个市场呈现混合竞争与分层互补的状态。

技术原理

一个现代的、适用于云原生与 AI 基础设施的可观测性系统，其技术架构通常可以抽象为一条高吞吐、低延迟的数据流水线：仪器化 → 采集 → 处理 → 路由 → 存储 → 查询与可视化。以下从三大信号的生成、传播、存储与推理机制出发，逐层拆解核心技术原理。

1. 信号的生成与语义约定

日志：是最原始、信息熵最高的信号形态。一条高质量的结构化日志不仅包含时间戳、日志级别、消息体，还应当嵌入 Trace ID、Span ID、服务名、环境标签乃至训练 Job ID、GPU UUID 等关键上下文。现代最佳实践通常要求应用直接输出 JSON 格式日志，以避免后续在高基数字段的解析上消耗过多计算资源。对于 AI 框架（如 PyTorch、JAX），日志所承载的具体语义已逐步从通用的进程日志向领域专属事件倾斜，例如 DataLoader 阶段的预取线程饥饿、算子融合失败、或显存分配器（CUDA Allocator）的碎片回收动作等。

指标：将系统状态压缩为带标签的数值。指标设计的核心挑战在于标签基数：一条gpu_utilization{gpu_uuid="...", job_id="...", node="..."}指标，如果每一维度的组合都独一无二，就构成了“高基数指标”，极易导致传统时序数据库（TSDB）因索引膨胀而性能崩溃。为应对此问题，工程上采取的策略包括：在采集端或流处理层进行预聚合（如仅保留按 cluster、job 粒度的 GPU 利用率）、在 TSDB 引擎中引入列式存储与近似算法，以及对高基数维度采用不同的后端（如 ClickHouse）进行独立存储与查询。

追踪：定义了一次逻辑操作（如一个 HTTP 请求、一次训练 Step 的 forward + backward + allreduce）在分布式系统中的完整因果链。其核心数据结构是 Span：每个 Span 包含操作名、起始/结束时间戳、标签、事件日志以及所属的 Trace ID。Span 之间通过父子关系或链接（Span Links）构成有向无环图。在 AI 训练场景中，一个典型的 Trace 可能横跨：外部请求 → 调度器 → Kuberentes API Server → Worker Init → DataLoader → 前向传播 → AllReduce → 后向传播 → Checkpoint 持久化，其中任一 Span 的耗时膨胀都能被精确归位。

2. 上下文传播：统一信号的“骨架”

单一信号的价值有限，真正的可观测性建立在信号之间的关联之上。这一关联依赖上下文传播机制，当前业界标准为 W3C Trace Context 规范。

其工作原理如下：当外部请求抵达网关时，网关或在服务网格中的 Sidecar 生成一个全局唯一的 trace-id，并将该 ID 作为一条特殊的 HTTP 头（traceparent）注入请求中。后续每经过一个服务或算子，服务将解析该头部，提取 trace-id 并生成新的 span-id，同时将自身生成的 span-id 作为“父”传递给下游。在 gRPC 通信中，该信息通过 gRPC metadata 传递；在消息队列（如 Kafka）中，则通过消息头携带；对于 GPU 间 NCCL 通信等不经过标准应用层协议的场景，可以通过关联进程级的追踪探针，将通信操作的历史轨迹与对应的 Trace ID 进行时间窗口对接。

通过这一机制，即便不同服务采用不同语言编写，运行在不同容器或主机上，所有遥测信号最终都能在同一个 Trace ID 下被收拢。用户在查询界面中，能够一键从 Grafana 上的异常指标，跳转到该时刻对应的分布式追踪瀑布图，再钻取到该 Span 生命周期内吐出的每一行关联日志。

3. 采集、处理与动态采样

现代遥测数据采集已形成以 OpenTelemetry Collector（OTel Collector） 为核心的标准化架构。该 Collector 支持以 Agent 或 Gateway 模式部署，并提供三大类管道组件：

• Receiver：接收来自 OTel SDK、Fluent Bit、Prometheus Exporter、NVIDIA DCGM、eBPF 探针等数据源的信号；
• Processor：在内存中对数据进行批处理、过滤、属性遮盖（如脱敏）、尾采样、指标聚合等操作；
• Exporter：将处理后的数据推送至后端存储或分析系统，如 Prometheus、Mimir、ClickHouse、Tempo、Elasticsearch 等。

其中，尾采样（Tail Sampling） 是面向 AI 训练场景的关键技术。不同于头部采样——即在 Span 创建时随机丢弃大部分样本——尾采样允许在 Span 完成、其完整信息暴露之后再做出保留/丢弃的决策。例如，一个设定为“保留所有包含 error=true 属性或端到端延迟大于 2 秒的 Trace”的策略，可以在海量正常请求中精准保留极少数异常 Trace，既大幅降低存储成本，又最大程度避免“丢失罕见故障样本”的风险。对于千卡集群上每隔数千迭代才出现一次的梯度同步超时问题，尾采样几乎是实现有效捕获的唯一可行路径。

4. 存储引擎与高基数分析

可观测性后端的存储架构通常不是单一的，而是针对不同信号采用多引擎组合：

• 时序数据库（如 Mimir、VictoriaMetrics）负责存储聚合指标，支持基于标签的快速过滤、滚动聚合以及规则告警。
• 全文搜索引擎（如 Elasticsearch、Loki）负责存储日志，允许进行关键词搜索、正则匹配和字段级统计聚合。Loki 的设计哲学区别于 Elasticsearch 之处在于：它仅对标签（Label）建立索引，不对日志内容本身建立全文索引，从而大幅降低索引开销，适合以标签（如 job、host）为第一过滤条件的查询模式。
• 列式分析引擎（如 ClickHouse、Apache Druid）或专有追踪存储（如 Tempo、Honeycomb 的 Retriever）负责存储追踪 Span 及其属性，支持以 Trace ID、操作名、高基数属性（如 user_id、gpu_serial）为过滤条件的高通量扫描。列式引擎的优势在于对高基数字段进行压缩存储，并通过 Bloom Filter、倒排索引等技术加速检索。
• 对象存储用于存放经过 gzip/zstd 压缩后的冷数据，供审计、法务或长期的训练任务回溯使用。

在 AI 训练可观测性这一垂直领域中，对于高基数属性的查询需求远高于通用微服务场景。例如，需要在数万张 GPU 中迅速筛选出过去一小时内所有发生过单比特 ECC 错误纠正且同时伴随 SM Clock 下降的显卡列表，并就地对这些显卡关联的训练任务进行性能归因。这就要求存储层不仅具备高基数属性扫描能力，还能支持跨信号、多步骤的即时 SQL 式查询，目前最能胜任这一任务的技术底座通常为 ClickHouse 等列式分析引擎。

5. eBPF 的无侵入式观测

对于无法修改代码或安装 SDK 的封闭环境——例如某些厂商提供的 GPU 驱动栈、用户态网络库或第三方 AI 编译器运行时——eBPF（extended Berkeley Packet Filter）提供了在内核层捕获观测数据的能力。通过将经过验证的沙箱化程序动态加载到 Linux 内核的挂载点（kprobes、tracepoints、uprobes 等），eBPF 能够非侵入地收集：

• 网络系统调用（tcp_sendmsg/tcp_recvmsg）的迟延与传输量，重构 NCCL 通信环上各节点之间的数据流分布；
• 块设备 I/O 的耗时与队列深度；
• CPU 调度延迟与进程切换频率；
• CUDA 内核启动相关的系统调用信息（如 cuLaunchKernel 的调用耗时）。

这些内核级事件随后被转换为 OpenTelemetry Span 或指标的格式，送入统一的可观测性管道，完成从内核信号到应用语义的桥接。需要指出的是，eBPF 探针对系统的 CPU 消耗极低，通常在个位数百分点的吞吐量损耗以下，因此尤其适合长期开启，用于事后回溯那些无法复现的瞬间异常事件。

总体而言，可观测性后端本身已演化为一套分布式数据系统：它必须同时满足对高吞吐写入（每秒数百万条日志与数十万个指标采样点）、低延迟查询（交互式排障要求秒级响应）以及海量数据局部性关联的要求。工程团队在构建和选型时，本质上是在对一个多引擎、多策略的系统进行集成与调优，使其在信号忠实度、存储成本与排障效率之间取得符合业务负载特征的平衡。

关键参数

评估一个可观测性平台或一项可观测性策略的成熟度与适用性，不能止步于功能有无，而应转向可量化的工程指标。以下定义面向云原生与 AI 训练场景的核心评价维度，并注明定性/半定量基准（当前公开资料尚缺乏行业统一的权威定量基准，此处所列参考值综合自各家产品文档及社区最佳实践分享）：

1. 遥测数据完整性

   • 定义：在系统故障从发生到恢复的完整时间窗口中，相关信号（特别是尾采样的追踪数据）是否被无损保留。
   • 参考实践：对于明确包含 status=error 或满足自定义规则（如 P99 延迟 >Xms）的 Trace，要求保留率趋近于 100%。头部采样方案通常无法满足此条件。
   • 上下文：该指标直接决定了是否能在事后进行可靠的根因分析。完整性不足意味着不可复现的故障可能反复出现而无法收敛。

2. 信号间关联成功率

   • 定义：在统一的查询起点（通常为 Trace ID）下，能够成功将异常 Trace 与其对应的结构化日志行、以及该时间窗口的节点级指标快照进行精确关联的概率。
   • 工程建议：目标关联成功率 >99%。失败通常源于上下文传播链条破损、时钟不同步或日志采集端裁剪了必要的上下文字段（如 Trace ID）。
   • 对 AI 场景的特殊要求：必须覆盖 DataLoader 子进程、NCCL 通信内核状态快照以及 GPU 显存分配日志等非传统微服务组件。

3. 高基数查询响应时间

   • 定义：在以高基数字段（如 gpu_uuid、job_id、user_uid）作为过滤和分组条件进行聚合查询时（例如“按 GPU UUID 分组计算过去一小时内 SM 利用率 P5/P95 分布”），查询界面返回结果所需的时间。
   • 定性目标：对于高基数基础指标，应控制在秒级；对于跨 Trace 聚合的多维分析（如“过去 24 小时内，所有 AllReduce 耗时大于 1s 的 Trace 按训练任务 ID 分布”），应控制在分钟级或以内。
   • 说明：响应时间受后端存储引擎（TSDB vs. 列式分析引擎）及数据量影响极大。

4. 存储保留周期与成本比

   • 定义：每 TB 遥测数据（聚合指标、原始日志、追踪 Span）在不同保留策略下的存储成本，以及各个信号可保留的最长时限。
   • 参考实践层次：精细追踪（包含所有高基数属性）可能仅保留数小时到 1 天；聚合指标保留 13 个月或更长；日志和冷数据归档至对象存储。企业需要在排障追溯需求与预算间作出折中，并将策略写入可观测性平台的数据生命周期管理规则中。

5. 采样公平性与召回率

   • 定义：尾部采样策略能否在极力压缩正常请求数据量的同时，仍确保稀有异常模式不被遗漏。
   • 定性检验：是否能捕获“每 1000 次训练步骤出现一次的小梯度爆炸”或“每隔 45 分钟出现一次的 NCCL 超时”等周期性稀疏异常。若采样策略仅基于并发限制而对异常模式无感知，则稀有异常很可能被彻底丢弃。

6. 系统负载开销

   • 定义：在目标集群上部署仪器化 Agent、eBPF 探针以及开启期望的遥测数据输出后，对训练吞吐量（samples/sec）产生的平均负面影响。
   • 定性范围：主流方案通常要求应用层 SDK 导致的额外 CPU 与延迟开销低于 5%；eBPF 探针的开销则普遍低于 1%～2%。具体数值因框架、框架版本及采集数据量而异，需以目标负载实测为准。

7. 数据采集到可视化延迟

   • 定义：从系统某一事件产生（如 GPU 异常时钟降频），到其反映在仪表盘或告警通知中的端到端时间差。
   • 业务约束：对于实时训练中断告警，要求延迟 ≤1 分钟；对于趋势性分析仪表盘，可放宽至 5～10 分钟。此延迟由采集间隔、管道批处理策略及后端写入刷新频率共同决定。

以上关键参数共同构成了衡量可观测性方案优劣的量化标尺。在实践中，没有一种方案能在所有维度上取得满分，技术团队必须根据自身业务特征——例如是“对训练中断极度敏感的大模型厂商”，还是“以成本优化为首要目标的传统企业 AI 平台”——来设计参数配置与架构选型。

技术路线

当前可观测性的技术路线并非单一方案的一统天下，而是呈现为从传统监控到可观测性原生、从纯开源到商业 SaaS、从侵入式 SDK 到无侵入探针的多条路径交织并存的局面。以下从数据采集标准、后端架构、典型部署模式以及 AI 垂直方案四个维度进行对比，并以定性表格呈现差异。

路线对比简表

AI 基础设施可观测性技术路线现状

在 AI 训练领域，技术路线尚未收敛至单一范式。目前主流实践中可观察到以下分层：

• GPU 基础设施层：以 NVIDIA DCGM（Data Center GPU Manager）为核心，配合 Prometheus DCGM Exporter 将 GPU 温度、功耗、SM/内存时钟频率、ECC 错误计数、PCIe 吞吐量等转化为时序指标。该层是目前成熟度最高的部分。
• 网络与通信观测层：主要通过 InfiniBand 计数器、NCCL 调试日志与 eBPF 驱动的节点间通信追踪提供数据。部分 AI 平台开始尝试将 NCCL 集体通信操作的整体耗时拆解为各 Rank 上的贡献，标记出瓶颈节点。
• 训练框架内层：由 PyTorch Profiler、TensorBoard、JAX profiling 等提供算子级、Step 级耗时。目前正通过 OpenTelemetry 生态逐步标准化，将训练 Step 作为 Span、DataLoader 迭代作为子 Span，显式输出给外部可观测性后端。
• 作业与调度层：Kubernetes 事件、Volcano/KubeFlow 调度器日志与队列指标，结合分布式训练任务的工作节点启动时序，构成理解任务整体状态的骨骼。

可以观察到，市场正从“每一层各自监控”的碎片化模式，走向以 OpenTelemetry 为统一采集语义、以可插拔后端为分析引擎的整合路线。同时，eBPF 作为“不打扰训练代码”的补充选项，正在被更多受限于封闭框架或不便修改代码的环境采纳。

上游

可观测性产业的上游，指的是为可观测性平台提供数据生成、仪器化、标准制定以及底层运行环境支撑的技术与组件层。

1. 仪器化标准与 SDK

   • OpenTelemetry（CNCF 孵育项目）：当前最核心的上游事实标准，定义了 SDK（多语言实现）、API 规范、OTLP 数据传输协议和数据模型。OTel 为日志、指标、追踪提供了统一的语义约定和采集模型，是绝大多数下一代可观测性平台的基石。
   • 专有框架/SDK：包括 NVIDIA DCGM（用于 GPU 遥测）、PyTorch Profiler（输出至 TensorBoard 或 OTel 导出器）、JAX 的性能分析接口，以及各云厂商的监控 Agent（如 AWS CloudWatch Agent、Azure Monitor Agent）。

2. 数据采集与导出组件

   • Prometheus Exporter 生态：包括 Node Exporter（主机级 CPU/内存/磁盘）、DCGM Exporter（GPU）、NCCL Exporter（通信库指标）以及各类数据库、消息队列的 Exporter。这些 Exporter 将受监控系统的内部状态转换为 Prometheus 格式的指标端点。
   • 日志采集器：如 Fluent Bit、Fluentd、Logstash、Vector 等，负责从容器 stdout、文件路径或系统日志套接字中采集中间格式的日志，并进行初步过滤、解析和路由。
   • eBPF 探针与内核观测框架：包括 Cilium、Pixie、Falco 等，通过动态加载内核模块化程序，无侵入采集网络流、系统调用、进程生命周期等事件，并转换为遥测信号。

3. 中间传输层

   • 消息队列与流平台：Kafka、Apache Pulsar、Redpanda 等通常被部署在大型可观测性管道的前端，以承担突发的海量遥测数据流量，起到削峰填谷的作用，并实现采集端与后端存储之间的解耦。
   • 容器编排与服务网格：Kubernetes 负责可观测性后端组件（如 Grafana、Tempo、ClickHouse）的部署与管理；Istio/Envoy 等网格则自动注入 Sidecar，输出服务间调用的追踪与延迟指标，极大降低了仪器化的人工改造量。

4. 关键硬件与加速器

   • GPU 与 AI 加速器：NVIDIA GPU、AMD Instinct、以及各家厂商的 AI 加速器内置大量的性能计数器（Performance Counter）和健康监控接口，是 GPU 层遥测数据的最终源头。
   • 高速网络设备：InfiniBand 交换机与 ConnectX 系列网卡提供了硬件级端口计数器、流控统计和误码率信息，是诊断 AllReduce 性能瓶颈不可绕过的基础数据源。

下游

可观测性的下游涵盖了存储、分析、可视化、告警、智能运维与财务管理的完整价值链。其核心在于将上游产生的原始信号转化为可行动洞见。

1. 存储与处理引擎

   • 时序数据库（TSDB）：如 Grafana Mimir、VictoriaMetrics、InfluxDB、Thanos（高可用 Prometheus 方案）。负责存储聚合指标，提供快速的时间范围过滤、聚合函数下推和告警规则评估。
   • 全文日志引擎：Grafana Loki（轻量级标签索引 + 对象存储后端）、Elasticsearch（需要全文索引时使用）、OpenSearch（社区驱动的 Elasticsearch 分支）。
   • 追踪与高基数分析引擎：Grafana Tempo（在对象存储上以低成本存储全量 Span）、ClickHouse（用于高基数追踪分析与复杂的跨信号 SQL 查询）、Honeycomb 的专有列式引擎（面向交互式高基数调试）。
   • 对象存储：AWS S3、MinIO、Ceph 等，通常作为归档层，存放压缩后的全量日志、历史追踪数据及长期保序的聚合指标快照。

2. 可视化与查询界面

   • Grafana：已成为跨多后端统一可视化的标准界面，通过内置数据源插件连接 Mimir、Loki、Tempo、Elasticsearch、ClickHouse 等，支持构建按 Trace ID 关联跳转的排障工作流。
   • 专有控制台：如 Datadog 的统一操作界面、Dynatrace 的 Smartscape 拓扑视图、Splunk Observability Cloud 的 APM 地图，它们提供更深度的自动关联与向导式诊断，但绑定于各自的商业生态。

3. 告警与事件管理

   • Prometheus Alertmanager：主要负责面向指标的阈值告警，支持分组、抑制、静默与多路由分发。
   • Grafana OnCall、PagerDuty、Opsgenie等：实现排班、升级策略和跨团队的告警协作，将可观测性信号与组织流程连接起来。
   • AIOps 与自动化处置：面向特定领域的智能检测（如对 GPU ECC 错误突增的预测），以及通过自动化 Runbook（如自动降级训练精度、隔离慢节点）将观测闭环为行动。

4. 智能运维与成本分析

   • 异常检测与根因分析：基于可观测性数据流进行非监督学习（如季节分解、聚类）以标记出非典型的训练性能曲线，再配合规则引擎进行故障假设验证。Dynatrace 的 Davis AI 是此方向的商业代表之一。
   • FinOps 与 GPU 经济学：通过解析按项目、团队、训练任务维度的 GPU 利用率、显存占用与通信开销，将资源消耗透明化，识别闲置或低效配置，为企业内部结算与成本优化提供数据支撑。Grafana 与专有 FinOps 平台常在此层对接。

5. 合规与审计

   • 长期保留的不可篡改遥测数据，可用于模型训练的安全审计、合规举证（如证明某模型训练未曾使用受限数据）以及关键业务决策回溯。对象存储的不变性与 WORM（一次写入，多次读取）特性在此环节发挥基础作用。

受益公司

以下所列公司基于其在可观测性产业链中的公开市场地位、产品矩阵和战略布局进行归纳。文中涉及的融资与估值信息均来自截至 2025 年 7 月的公开资料，未披露处标示“公开资料未见”。本段不构成任何投资建议。

1. Datadog（纳斯达克：DDOG） 作为可观测性 SaaS 领域的标杆企业，Datadog 提供覆盖基础设施监控、APM、日志管理、真实用户监控（RUM）、安全监控和 CI 可见性的统一平台。其按用量的计费模式与客户云资源使用规模高度相关，营收在过去数年保持高速增长（FY2024 年报显示全年营收约 26 亿美元）。在 AI/ML 方向上，Datadog 已推出面向 Kubernetes 上 GPU 工作负载的监控仪表板，并通过与 NVIDIA 的合作增强了对训练集群的指标收集。

2. Splunk（已被思科收购） Splunk 以日志分析和安全信息与事件管理（SIEM）起家，近年通过 Splunk Observability Cloud（原名 SignalFx）转型为可观测性平台供应商。其强项在于同时满足 IT 运维与安全团队的查询需求。思科的收购（2024 年完成）将 Splunk 的遥测能力与思科的网络硬件、全栈可观测性战略进行整合，目标直指跨数据中心与广域网的一体化观测。

3. Dynatrace（纽交所：DT） Dynatrace 以其高度自动化的拓扑发现（Smartscape）和用于根因分析的 Davis AI 引擎闻名。其单一代理（OneAgent）在传统行业转型云原生的过程中广受欢迎，能够快速覆盖从大型机到容器的异质基础设施。FY2025 财年 ARR 持续强劲增长（公开财报显示 ARR 突破 16 亿美元）。AI 训练方面，其 Davis AI 引擎已在尝试针对 GPU 资源进行异常归因建模。

4. Grafana Labs Grafana Labs 采用开放核心（Open Core）模式，围绕开源的 Grafana、Loki、Tempo、Mimir 构建了 LGTM 可观测性堆栈，并提供企业增强版和 Grafana Cloud 托管服务。根据公开融资信息，Grafana Labs 估值在 2022 年即已突破 50 亿美元。因其开源属性与后端的多样化兼容性（可对接 ClickHouse、Elasticsearch、Prometheus 等），该堆栈已成为多数自建可观测性平台的默认选择，尤其是在成本敏感且需要高定制化的 AI 实验室和科技公司中。

5. Elastic（纽交所：ESTC） 以 Elasticsearch 为核心，Elastic 在全文搜索领域的强大索引能力使其在日志分析和安全分析场景地位稳固。其 Elastic Observability 方案同时整合了 APM、基础架构监控和通用分析，允许用户使用 Elasticsearch 查询语言对多信号执行联合分析。对于需要同时搜索海量非结构化训练日志与结构化指标的团队，Elastic 是具有竞争力的选择。

6. Honeycomb Honeycomb 是“可观测性 2.0”理念的首倡者，技术差异点在于其自研的高基数列式存储引擎，专门优化了对任意维度的高性能即时查询。其产品更偏向服务软件工程师进行调试，而非传统运维仪表盘。该公司已获多轮融资（包括 2023 年估值达 4 亿美元的融资轮，公开资料），客户群集中于追求一流开发者体验的科技公司。

7. 云服务商（AWS、微软、Google） 三大公有云均提供原生可观测性产品：AWS 拥有 CloudWatch、X-Ray 与托管 Grafana/AMP（Amazon Managed Prometheus）；微软 Azure 提供 Azure Monitor、Application Insights 和容器洞察；Google Cloud 则以 Cloud Monitoring、Cloud Logging 和 Cloud Trace 为核心，并贡献了 OpenTelemetry 生态的大量代码与标准。云厂商的优势在于与自身 IaaS/PaaS 层无缝集成，往往作为大量企业可观测性入口的第一步。在 AI 可观测性方向上，各家正积极扩展对 GPU 工作负载和 AI 平台服务的监控覆盖。

8. 国内相关企业 国内可观测性市场呈现碎片化格局，除云厂商（阿里云 ARMS、腾讯云云监控、华为云 AOM）外，还有专注于 APM 或日志分析的独立 ISV（如基调听云、博睿数据、日志易等），以及基于开源组件进行定制集成和部署的服务商。在 AI 训练可观测性这一细分领域，目前以公有云提供的深度学习容器监控方案与头部 AI 实验室的自研平台为主，公开的独立垂直产品或初创公司信息尚不充分。

市场规模

市场规模概述

截至 2025 年 7 月，可观测性与 IT 运维分析市场正处于持续扩张阶段。根据多家第三方研究机构（如 Gartner、IDC、MarketsandMarkets）在 2023–2024 年间发布的行业报告口径，全球可观测性平台、IT 基础设施监控与 AIOps 相关市场规模合计在 300 亿–400 亿美元量级，年均复合增长率（CAGR）多落在 10%–15% 区间。其中，以 SaaS 形态交付的现代可观测性产品的增速显著高于传统本地化部署的监控工具。

驱动因素

市场的增长由以下结构性力量驱动：

• 云原生与微服务的全面渗透：传统监控工具已无法应对大规模、动态化、多语言的分布式工作负载。CNCF 2024 年调查显示，超过 70% 的被调查者在生产环境中使用 Kubernetes，可观测性几乎成为容器化部署的必选项。
• AI/ML 训练集群规模的急剧攀升：AI 实验室和大型企业的训练集群从数百张 GPU 迈向数千甚至万卡级别，集群内部故障的频率和影响范围呈非线性上升。每一次训练因慢节点、通信挂死或硬件静默错误而中断，都可能造成数万至数十万美元的直接计算资源浪费与项目延迟，这迫使企业将对可观测性的投资视为降低训练总拥有成本（TCO）的必然支出。
• 安全与合规需求的融合：可观测性数据与安全信息事件管理（SIEM）的边界正在模糊，企业倾向于统一存储和分析运维日志与安全日志，从而扩大了可观测性后端的预算池。
• FinOps 与云成本优化的推动：在经济周期波动中，企业利用可观测性数据消除 GPU 和 CPU 资源闲置、归因各团队资源消耗的诉求日益强烈，为可观测性平台提供了新的价值主张和增收通道。

细分市场特点

• 商业化 SaaS 市场：Datadog、Splunk、Dynatrace、New Relic 等是主要玩家，采用按主机数或数据摄入量计费，大客户（年度合约超过百万美元）的持续扩张是增长主引擎。
• 开源与自建市场：以 OpenTelemetry + Grafana LGTM + ClickHouse 为代表的开源方案，在互联网原生企业、AI 实验室以及注重数据主权和成本控制的中大型组织中快速渗透。这部分“市场”虽不直接体现为软件许可证销售，但驱动了围绕部署、定制化、运维支持和培训的服务型收入。
• AI 训练可观测性细分市场：仍处于早期阶段，缺乏独立的权威市场规模数据。当前支出主要体现为大模型与算力服务商内部工程团队的专项建设成本，以及购买 Datadog 等商业平台中 GPU 监控附加功能的增购费用。由于此领域与 AI 基础设施支出高度绑定，其潜在规模可能随万卡集群的普及而快速增长。

声明：以上定性描述与数量级区间综合自多份公开行业研究报告摘要，具体年份、基准口径与统计方法论因研究机构而异，此处不作为精确财务预测的依据。如需进行精确的商业决策，建议直接查阅付费原版行业报告。

玩家对比

以下对比聚焦于不同策略底层逻辑的差异，而非逐一罗列功能。比较维度覆盖与 AI/ML 训练可观测性密切相关的部署模式、分析能力和生态开放性。

结论性观察：在 AI 基础设施可观测性战场上，目前还没有一家能够在“训练代码级别 Trace、GPU 硬件层遥测、NCCL 通信监控、弹性调度事件”四者之间提供完全一体化、开箱即用体验的厂商。各类组织倾向于以 OpenTelemetry 为采集总线，在其上嵌入多引擎后端，并以自研或高度定制的方式填补 AI 运维领域的空白。这一现状既给创业公司留下了垂直深耕的空间，也推动了现有平台厂商通过收购和内部研发快速补课。

风险

在评估可观测性技术与市场时，需识别以下结构性风险与技术性风险：

1. 技术锁定与成本失控风险

   • 过度依赖单一商业 SaaS 平台（尤其是按数据摄取量计费模式），可能导致随 IT 规模成长而指数级飙升的支出。若组织未能建立有效的数据生命周期管理、采样策略和无关信号过滤机制，其可观测性账单可能侵蚀甚至超出基础设施本身带来的边际收益。迁移成本极高，因为历史数据、仪表板、告警规则和团队工作流已与该平台深度耦合。

2. 高基数失控与存储爆炸

   • 在 AI 训练中，用户极容易将每个 GPU UUID、每个训练 Job ID、每个微批次 ID 作为标签，未经治理即输出为指标或追踪属性。缺乏基数限制和预聚合的遥测流水线会迅速导致后端存储索引膨胀、查询响应坠崖，最严重时造成整个可观测性平台不可用，在故障发生后反而因工具链自身瘫痪而失去排障能力。

3. 信号关联断裂与“数据沼泽”

   • OpenTelemetry 等标准虽已普及，但在实际实施中，上下文传播链条极易因网络中间件修改 Header、服务框架版本不一致、GPU 通信库未植入传播逻辑等原因中断。一旦链路断裂，海量的日志、指标和 Trace 将退化为彼此孤立的“数据沼泽”，运维价值急剧下降，而清理和修复的工程成本却非常高昂。

4. 人才与组织能力缺位

   • 部署一套生产级的可观测性平台（尤其是基于开源组件自建）并非单纯的工具安装，而要求团队具备跨时序数据库、列存储、流处理、eBPF 以及特定领域（如 GPU、NCCL）的工程能力。缺乏相应人才的企业可能在采购后无法有效将其转化为排障效率的提升，最终投资沉淀成一套没有人会使用的昂贵摆设。

5. 安全与隐私风险

   • 可观测性管道集中了系统中几乎所有组件的内省数据，包括日志中可能暴露的敏感信息、API 密钥、训练数据片段等。若采集、传输、存储环节缺乏统一的脱敏、加密和访问控制机制，可观测性平台自身将成为最高价值的安全攻击面。

6. AI 训练特有风险：语义鸿沟与静默故障

   • 即便拥有丰富的 GPU 遥测和 NCCL 指标，训练任务仍可能因深层框架 Bug、数值不稳定（如梯度静默爆炸/消失）而失效，且不在现有任何遥测信号的直接表征范围内。过度投资于底层基础设施监控而忽视模型层和训练算法层的可观测性，可能产生“监控一切却仍对故障机理一无所知”的语义鸿沟。

误读纠偏

误读 1：可观测性就是日志、指标和追踪三样东西的总和

纠偏：真正的可观测性不是多采集几类数据，而是通过数据使系统呈现出“可被提问”的特性。其核心在于能否不编写新的仪器化代码，就能对系统提出任意新的问题并获得回答。仅仅把三种信号分别丢进 Elasticsearch、Prometheus 和 Jaeger，却不通过 Trace ID 和统一语义层将它们紧密耦合，更不支持高基数临时查询，本质上只是“更丰富的高级监控”，而非可观测性。

误读 2：只要全量采集所有遥测数据就实现了完美的可观测性

纠偏：全量采集意味着存储成本和信噪比的全面恶化。优秀的可观测性在于“高密度且有意义的信号”，即通过智能尾部采样、边缘聚合以及非对称数据保留策略，保存下故障复原所必需的完整上下文，而不是存储海量分辨不出异常模式的原始数据。在千