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 垂直方案四個維度進行對比，並以定性表格呈現差異。

路線對比簡表

維度	傳統監控（Zabbix/Nagios）	經典 APM（New Relic/Datadog）	現代可觀測性（OpenTelemetry + 列式/微服務後端）	eBPF 無侵入觀測（如 Cilium/Pixie）
資料覆蓋	固定指標為主，日誌為附屬檔案	日誌、指標、APM Tracing 兼有，但多訊號在內部常處於分立模組	三訊號統一模型，強調高基數任意維度聚合與跨訊號關聯	核心/程序級網路與系統呼叫追蹤，應用層語義需外部對映
關聯能力	低，基本依賴人工比對時間戳	部分自動關聯，通常僅在單一廠商產品內部封閉完成	天然以 Trace ID/Label 為核心實現訊號間與跨服務關聯	需與 OTel 等上層管道聯合，將核心事件按時間視窗與應用 Trace 結對
儲存架構	平面 RRD 檔案或關聯式資料庫	專有後端叢集（通常為黑盒）	開放式多引擎組合：TSDB + 列式引擎 + 全文引擎 + 物件儲存	無持久化或僅短暫快取，需依賴上游管道
對 AI/ML 訓練的適用性	幾乎不可用	需大量定製化 Agent 和遙測匯出配置，原生 GPU/NCCL 支援薄弱	可通過生態（DCGM Exporter、PyTorch Profiler OTel 匯出）靈活整合，適合開發自定義排障器	在捕獲通訊層異常方面表現突出，但缺乏對訓練語義的原生理解
運維複雜度	低	中（託管 SaaS 簡化維護）	中到高（自建管道、儲存與查詢叢集，需整合維護）	中（要求的 Linux 核心版本、節點相容性及安全權限管理較複雜）
成本結構	低基礎設施成本，高人力成本	按資料量/主機數計價，規模擴大後商業成本急劇上升	開源元件免費，硬體與運維團隊成本為主體；可私有化部署	極低的執行時開銷與儲存成本，但需投入專家時間進行埋點維護

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 訓練可觀測性密切相關的部署模式、分析能力和生態開放性。

對比維度	Datadog	Grafana Labs (LGTM)	Dynatrace	Honeycomb	雲端服務商原生（AWS/Azure/GCP）
核心哲學	一站式 SaaS，全訊號覆蓋，開箱即用的儀表盤與關聯	開源標準制定者，可插拔後端，交給使用者最大控制權	全棧自動化拓撲發現，以 AI 引擎進行根因分析	服務於開發者互動式除錯的高基數分析引擎	與自有基礎設施無縫整合，降低初始接入門檻
部署模式	SaaS，提供部分本地節點	開源自行部署 + Grafana Cloud 託管服務	SaaS 與本地託管皆可（強調全棧一鍵代理）	SaaS 為主	公有雲端服務，部分可通過混合/Azure Arc 等方式延伸至本地
AI 訓練支援深度	預置 GPU/K8s 儀表板，可通過 API 匯入自定義指標；開放生態對接 DCGM	完全靈活，需自行搭建 DCGM Exporter + Tempo/ClickHouse 關聯流程；極高自由度	OneAgent 自動發現程序與 GPU 使用率；但深入訓練內部 Trace 需額外整合	需自建上游 OTel 埋點，在訓練排障中強於 SQL 式高基數探索	各自提供原生 GPU 監控（如 AWS 的 DL 容器監控），深度依賴對應平台服務
查詢與關聯能力	統一的 Datadog 查詢語言，跨產品關聯成熟	Grafana 統一介面，通過資料來源外掛實現跨後端鑽取；自定義能力極強	Davis AI 自動歸因，人工查詢可自定義但生態相對封閉	獨有的列式查詢引擎，尤其適合任意維度組合的即時鑽取	各自查詢語言，跨服務聯動在單一雲端平台內較順暢；多公有雲端部署時面臨割裂
成本可控性	按用量計費，AI 大叢集產生的海量資料若不加精細化管理則商業成本攀升明顯	開源元件無許可費，成本主要由硬體與運維團隊構成；需團隊具備調優與治理能力	按主機或用量計費，全棧代理可降低配置成本但可能增加管理開銷	按資料量或事件數計費，適合以追蹤和除錯為核心的團隊	通常按用量付費，與雲端賬單合併，大規模使用下需最佳化資料攝入
典型使用者畫像	追求最快上線、運維人力偏緊的中大型企業	開發者文化強、具備平台工程團隊的科技公司與一流 AI 實驗室	管理大規模混合 IT 資產（大型機、虛機、容器共存）的傳統大型企業	追求卓越開發者體驗、產品驅動的科技組織	以單一公有雲端為主陣地、或處於雲端遷移初期的團隊

結論性觀察：在 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：只要全量採集所有遙測資料就實現了完美的可觀測性

糾偏：全量採集意味著儲存成本和訊雜比的全面惡化。優秀的可觀測性在於“高密度且有意義的訊號”，即通過智慧尾部取樣、邊緣聚合以及非對稱資料保留策略，儲存下故障復原所必需的完整上下文，而不是儲存海量分辨不出異常模式的原始資料。在千