Layer 0：可觀測性 — 自主運維的基石

2026 年 4 月 · 12 分鐘閱讀 · Aidaris Technologies 架構系列

可觀測性 OpenTelemetry SRE 架構

你無法自動化你看不到的東西。在系統能夠自主運行之前——在它能夠偵測故障、理解其根本原因並執行修復之前——它必須首先能夠以足夠的清晰度感知自己的狀態，以回答這個問題：為什麼會發生這種情況？

這就是可觀測性。不是監控。不是告警。可觀測性是一門架構學科，它確保系統中的每個有意義的事件都被捕獲、關聯並能夠實時查詢。它是自主運維的每個後續層級都依賴的基礎層。

大多數組織認為他們擁有可觀測性，因為他們有儀表板。他們沒有。他們擁有的是監控——一組預定義的信號，告訴你什麼出了問題。可觀測性告訴你為什麼，因為系統發出足夠的結構化信息來描述其內部狀態，使你可以重建發生的事情，而無需猜測。

監控與可觀測性之間的鴻溝

這種區別不是語義上的。它是架構上的，它決定了你的自動化是可靠的還是魯莽的。

監控系統回答你預期提出的問題：「CPU 是否較高？我們是否收到錯誤？延遲是否上升？」這些很有用。它們會提醒你有問題。但它們不能解釋問題。

可觀測系統回答你沒有預期的問題。用戶報告他們的上傳間歇性失敗。你的錯誤率儀表板在整個集群中顯示 0.1% 的錯誤。你的 CPU、記憶體和磁盤都正常。你的監控提供了什麼都沒有。但一個可觀測的系統——一個有分佈式追蹤來追蹤該用戶的請求通過每個服務邊界的系統——可以向你顯示延遲峰值確切發生在哪裡、哪個資料庫查詢花費 15 秒（通常花費 50 毫秒），以及它是否與特定後端服務負載相關聯。

區別不在於複雜性。它在於結構。監控關於預定義信號。可觀測性關於擁有足夠的結構化信息，使你可以提出任何問題並找到答案。

可觀測性的三大支柱

支柱 1：使用 OpenTelemetry 的分佈式追蹤

分佈式追蹤是單個請求流經整個系統的完整記錄：從用戶的瀏覽器到你的 API 閘道，通過微服務，進入資料庫，然後返回。每個步驟都是一個「跨度」（span）——一個工作單位，具有時間、元數據和與其他跨度的因果關係。

OpenTelemetry 是捕獲這些追蹤的行業標準。它是供應商中立的、與語言無關的，並且設計為足夠輕量級以在生產環境中大規模運行。

為什麼這對自主運維很重要？因為當你的自動化系統偵測到延遲峰值時，它需要回答：「哪個服務很慢？它總是很慢還是特定於此區域？它是否與特定類型的請求相關聯？」沒有分佈式追蹤，這些問題幾乎不可能回答。有了它們，答案是立即的。

實施 OpenTelemetry 需要紀律：

每個邊界的檢測。 API 呼叫、資料庫查詢、快取命中、外部服務呼叫——每個服務邊界的交叉都必須被追蹤。部分追蹤基本上是無用的。
豐富的上下文傳播。 追蹤 ID 必須流經整個堆棧：從 HTTP 標頭到訊息佇列再到後台工作。如果追蹤被中斷，你就無法追蹤請求。
深思熟慮的取樣。 追蹤每個請求可能代價不菲。取樣策略——捕獲 10% 的追蹤、所有錯誤追蹤或超過延遲閾值的追蹤——在保留信號的同時降低成本。

儲存和查詢追蹤的基礎設施同樣重要。Jaeger（開源）或 Grafana Tempo（商用）等工具提供儲存和視覺化層。Tempo 特別有價值，因為它直接與 Grafana 集成，使你可以從 Grafana 告警點擊進入導致它的追蹤。

支柱 2：使用 Prometheus 的結構化指標

指標是時間序列數據：隨時間標記（維度）的數值。「下午 3:45 的 CPU 使用率為 78%。」「下午 3:46 的錯誤率為 2.3%。」「響應延遲 95 百分位數為 250 毫秒。」

Prometheus 是現代基礎設施中收集和儲存指標的標準。它使用一個簡單而強大的模型：每個指標由名稱和一組標籤標識。http_request_duration_seconds{service="auth", method="POST", status="200"} 告訴你返回 200 狀態碼的 auth 服務的 POST 請求的持續時間。

對於自主運維，指標是控制表面。當你希望系統根據延遲自動擴展時，你查詢 Prometheus。當你想決定是否回滾部署時，你檢查錯誤率是否增加。當你設置 SLO（服務等級目標）時，你根據 Prometheus 指標定義它們。

但指標必須捕獲正確的信號。大多數團隊為操作指標檢測系統：CPU、記憶體、磁盤、請求計數、錯誤計數、延遲。這些是基本的。高成熟度的可觀測性還捕獲商業信號：

評估的功能標誌（哪些隊列正在使用哪些功能？）
購物車添加、結帳、付款失敗（用戶是否實際完成交易？）
搜索查詢、零結果搜索（搜索質量是否下降？）
首次有意義的渲染時間（前端是否很慢？）

沒有商業信號，你的可觀測性系統可以告訴你系統很快但業務在失敗。有了它們，你可以將操作更改直接關聯到商業影響。

Prometheus 本身只是時間序列資料庫。對於視覺化、儲存和告警，Grafana 是行業標準。Grafana 儀表板不僅漂亮——它是一種查詢語言。儀表板應該提出你關心的問題：「我本週的錯誤預算消耗是多少？有多少服務違反其 SLO？過去 30 分鐘改變了什麼？」

支柱 3：使用 ELK Stack 的結構化日誌

日誌是系統的敘述。與聚合指標或追蹤請求的追蹤不同，日誌捕獲離散事件：「用戶登錄失敗」、「資料庫連接池耗盡」、「快取未命中率高」。當日誌是結構化的時——不是自由格式文本，而是帶有一致字段的 JSON 對象——日誌最有價值。

ELK Stack（Elasticsearch、Logstash、Kibana）仍然是使用最廣泛的開源日誌記錄平台。Elasticsearch 將日誌儲存在可以搜索和聚合的索引中。Logstash 在日誌流入時解析和轉換日誌數據。Kibana 是查詢和視覺化層。

對於自主運維，結構化日誌有兩個目的：

調查。 當出現問題時，Kibana 允許你按服務、按錯誤類型、按時間戳、按用戶 ID 搜索日誌。你可以從 Grafana 告警鑽進 Kibana 以查看實際發生的情況。
模式檢測。 AIOps 平台分析日誌以識別重複模式——故障前的事件序列。沒有結構化日誌，這是不可能的。

一台機器每天記錄千兆字節的原始文本不是可觀測性。具有一致字段名、適當時間戳和有意義上下文的結構化日誌是必要的。日誌級別（debug、info、warn、error）不如日誌實際所說的重要，以及它們是否可以被搜索和聚合。

架構：將其結合在一起

三大支柱——追蹤、指標、日誌——必須集成以形成一個連貫的可觀測性系統：

你的應用代碼（帶有 OpenTelemetry 檢測）
  ↓
收集器 → 處理層（取樣、批處理、轉換）
  ↓
Jaeger(追蹤) | Prometheus(指標) | Elasticsearch(日誌)
  ↓
Grafana 儀表板（統一視覺化層）
  - 指標和 SLO 儀表板
  - 追蹤探索器
  - 日誌聚合
  - 告警規則

這個架構為自主運維提供了幾項關鍵功能：

診斷。 當出現問題時，你可以從 Grafana 告警導航到 Prometheus 查詢再到 Jaeger 追蹤再到 Kibana 日誌，重建確切發生的事情。
自動化反饋。 自動化系統查詢 Prometheus 以獲取指標，搜索 Kibana 以查找模式，並追蹤以理解故障模式。
學習。 每個事件都以結構化、可查詢的數據捕獲。事後分析不是猜測；它是基於證據的。

可觀測性作為一門工程學科

建立可觀測性不是一個有終點的項目。這是一門持續的工程學科。它需要：

檢測標準。 每個服務都應該以相同的格式發出追蹤、指標和日誌。這需要商定的約定和工具支持。
基數管理。 如果你發出具有無限維度的指標或日誌（如用戶 ID），儲存成本會爆炸。可觀測性基礎設施需要對標記內容和方式進行紀律性選擇。
保留政策。 追蹤和日誌的儲存代價高昂。關於保留什麼以及多長時間的政策必須是有意的。高價值數據（錯誤、延遲異常值）可能保留 90 天；例行調試日誌保留 7 天。
性能。 可觀測性檢測本身不能降低應用的速度。追蹤、指標收集和日誌發送必須是非同步的和容錯的。如果你的可觀測性系統失敗，你的應用必須繼續運行。

常見陷阱

追蹤檢測不足。 團隊將 OpenTelemetry 添加到主要服務，但忘記了資料庫驅動程序、HTTP 客户端庫或訊息佇列。部分追蹤幾乎沒有用。如果請求跨越 5 個服務邊界，你只檢測 3 個，你就會遺漏緩慢。

沒有上下文的指標。 「響應時間：500 毫秒」告訴你很少。按端點、按區域、按客戶層分類的響應時間，並與並發流量相關聯，會告訴你一切。在豐富的標籤中投資。

日誌作為調試。 具有自由格式文本的非結構化日誌難以聚合和分析。日誌聚合平台需要一致的結構。如果你不能按服務、按錯誤類型或按時間窗口查詢日誌，它們就無法提供可觀測性。

「僅針對故障的可觀測性」錯誤。 大多數團隊只在出現故障時添加檢測。但可觀測性在顯示正常運行時最有價值。你需要健康狀況的基線，然後才能檢測到異常。

一切的基礎

可觀測性被稱為 Layer 0，不是因為它很簡單，而是因為一切都依賴於它。在不完整的可觀測性基礎上構建的自動化 runbook 系統將執行錯誤的修復。基於不反映現實的指標的 SLO 驅動控制迴圈將優化到錯誤的目標。在沒有追蹤的不可變基礎設施系統上構建的系統無法診斷問題。

我們在試圖自主運維的組織中看到的最常見的失敗模式是跳過 Layer 0。他們在為人類故障排除設計的監控系統之上部署複雜的 AIOps 平台、GitOps 工具和自我修復基礎設施。結果：漂亮的儀表板、昂貴的工具和沒有人理解的故障系統。

建立持久的自主運維的組織從這裡開始。他們投資於 OpenTelemetry 檢測。他們建立回答商業問題的 Grafana 儀表板。他們構造日誌，使模式可見。他們將可觀測性作為一級工程關注，而不是事後想法。

這個基礎——可觀測性作為一門架構學科——是使其後的一切成為可能的。

系列中的下一個

一旦可觀測性牢固，下一層是運行手冊自動化：取你現在可以看到的已知故障並自動化它們的修復。閱讀 Layer 1。

在 AIDARIS，我們與團隊合作建立實際有效的可觀測性系統。如果你對你的可觀測性基礎是否能支持自主運維感到不確定，我們很想幫助你評估它。