一、概念

　　2023年的《可觀測性技術發展研究報告》指出，可觀測性指的是通過系統的外部輸出來度量系統內部運行狀態的能力。監控是可觀測性的關鍵核心組成部分，兩者是相互依賴的不同概念，監控是爲提高系統的可觀測性而執行的操作。

　　業界將可觀測性能力劃分爲 5 個層級，其中告警（Alerting）與應用概覽（Overview）屬於傳統監控的概念範疇。觸發告警的往往是明顯的症狀與表象，但隨着架構與應用部署方式的轉變，不告警並非意味着一切正常，因此，獲取系統內部的信息就顯得尤爲重要，而這些信息則須藉助可觀測性能力的另一大組成部分——主動發現（Preactive）。

1）可觀測性與監控的區別

　　傳統的監控以運維爲核⼼，側重於某些值（錯誤的時間和內容等），通過對照已知閾值檢測特定系統的運行狀況，這些閾值將提示是否存在已知設定條件的錯誤，這是一種被動方式，只能發現已知可能出現的錯誤，並且收集到的不同系統組件的數據可能是孤立的，其相互關係很難理解。

　　而可觀測性以開發爲核⼼，基於指標收集、日誌分析、事件追蹤、機器學習等技術和方法，提供更全面、更主動、自適應的監控和分析能力，可以全面瞭解所有相互關聯的系統，更準確的指出問題發生的位置和原因，主動識別和定位任何故障異常，無論是已知的還是未知的錯誤。例如它會回答是代碼變更的哪一部分造成了這種影響，並提出合適的修復方法。

　　在《可觀測性工程》一書中提到，可觀測性使得工程師不需要依靠人類的經驗和直覺來檢測系統的問題，可以有條不紊、客觀地研究任何問題，而無須考慮之前是否瞭解這個系統。從開發和運維的角度將應用程序的層層調用邏輯透明化，從而方便企業快速進行故障定位，降低 MTTR（Mean time to repair，平均故障修復時間），提升整體的用戶體驗。

　　人工智能（AI）和機器學習（ML）越來越多地被用於可觀測性平臺，以提供自動化異常檢測、根本原因分析和預測性見解。這些技術有助於減少識別和解決複雜系統中問題所需的時間和精力。

2）DevOps 和 SRE

　　DevOps 是 Development 和 Operations的混成詞，突出重視 Dev（開發人員）和 Ops（運維人員）之間的溝通合作，通過自動化流程來使得軟件構建、測試、發佈更加快捷、頻繁和可靠；SRE（Site Reliability Engineering）是指網站可靠性工程，直接掌管互聯網公司的機器和服務，保證網站不宕機是他們的使命。

　　DevOps 和 SRE 團隊的工作是瞭解生產系統和馴服複雜性。因此，他們很自然地會關心其構建和運行系統的可觀測性。SRE 專注於根據服務級別目標（SLO，Service Level Objective）和錯誤預算（Error Budget）來管理服務。DevOps 專注於通過跨職能實踐來管理服務，開發人員對其生產中的代碼負責。

3）可觀測性平臺

　　構建可觀測性平臺需要具備：

統一構建方式，將各種指標、鏈路、追蹤、用戶行爲、事件、安全等數據統一收集，建立多維度的直接關係，實現數據聯動的能力，賦予開發、運維和測試統一的技術數據分析能力。
統一數據模型，涵蓋各種基礎設施、技術棧中收集的全量數據，不僅僅包含指標，也需要支持相關的日誌以及鏈路等數據。數據進行結構化處理，達成數據模型的統一。
統一信息處理，包含採集、整理、儲存等，統一查詢，統一展示的基礎。
統一查詢分析，使用分析引擎進行統一的數據分析，可觀測平臺具備一類語法簡單且功能強大的類 SQL 查詢語言。
統一內容消費，通過優秀的圖表展示，運行情況定期彙總生成報表，實時監控和告警通知，及時發現異常，通過開放 API 接口將可觀測性數據對外開放。
環境適配能力，具備自定義集成更多被觀測系統的業務信息能力，即數據編排能力或數據驅動編程能力，允許平臺靈活地集成額外的數據。

二、三大支柱

　　可觀測性的三大支柱包括：指標（metrics）、日誌（log）和鏈路（trace），它們也叫遙測（telemetry）數據。

1）日誌

　　日誌就是系統運行過程中輸出的文本數據，包含系統對指定對象執行的操作、結果和時間等信息。

　　日誌格式往往是結構化的（例如 JSON 格式），如此定義後數據能更加清晰，並且便於機器解析。

{
  "logName": ...,
  "resource": ...,
  "httpRequest": ...,
  "jsonPayload": {
    "user"   : "some-user",
    "method" : "GET",
    "code"   : 200,
    "size"   : 777,
    "host"   : "192.168.0.1",
    "path"   : "/some-path",
    "referer": "some-referer",
    "agent"  : "Opera/12.0"
  }
}

2）指標

　　指標可量化系統狀態和性能，某個被測量的主體在一個時間範圍內的各個時間點上的測量值，例如服務器 CPU 使用情況、內存、網絡流量和請求延遲等數據。

　　指標是傳統監控系統軟件中的主要組成部分，它是預聚合度量。由指標生成的數值反映了預定義時間段內系統狀態的聚合報告。當將指標值收集到監控系統中時，預先聚合好的措施就成了監測系統狀態的最小顆粒度。

3）鏈路

　　鏈路（即鏈路追蹤）可深入瞭解請求路徑、性能瓶頸和系統依賴關係，多個處理數據的片段（也叫 span，跨度）通過鏈路 ID 進行串聯，組成一條鏈路追蹤。

　　如果不能理解依賴關係，那麼調試將會變得非常困難。例如下游數據庫服務出現性能瓶頸，那麼服務延遲可能就會堆積。在上游三到四層檢測到延遲時，確定系統的哪個模塊是問題的根源可能會非常困難，因爲在幾十個其他服務中都可以看到相同的延遲。

　　將鏈路可視化爲瀑布圖（兩張圖分別是兩個工具）能更容易的展示請求的每個階段，及其在每個部分的開始和結束時間，瀑布圖的每一行（組成部分）就是一個 span。

　　爲了構建任何路徑的視圖，每個 span 都需要 5 段數據：鏈路 ID、span ID、Parent ID、時間戳和執行時長。其中鏈路 ID 由根 span ID 生成，會貫穿請求的各個階段；Parent ID 用來記錄 sapn 之間的嵌套包含關係。

　　追蹤工具本身有較強的侵入性，通常是以插件式的探針來實現。除了硬編碼之外，還可以採用優秀的開源項目： OpenTelemetry。 OpenTelemetry（OTel）支持多種編程語言（Go、JavaScript、Java 等），能捕獲指標、日誌、鏈路等遙測數據，並且僅需埋點一次，就能將遙測數據發送至所選的後端。架構圖如下圖所示，由API，SDK和Collector三部分組成。

　　在官方的 Github 中給出了許多的示例，包括 Node 的框架 Express 和 KOA，數據庫的 MySQL 和 MongoDB，甚至對日誌庫（bunyan）也有示例。

三、SLO

　　閾值告警只適用於已知的未知情況，例如 CPU 佔用超過 80%、內存可用率低於 10% 等，其表現過於僵硬和粗糙，不能可靠地表明動態環境中的用戶體驗下降，沒辦法做到上下文關聯。可靠的告警需要更精細的顆粒度和可靠性，這就是 SLO 可以幫助補充的地方。

　　SLO（Service Level Objective，服務水平目標）是測量服務健康的內部目標，提供一個安全區間，幫助團隊在外部用戶體驗達到不可接受的水平之前進行識別和補救問題。爲了解決告警疲勞的問題（所謂告警疲勞是指大量誤報或不需要操作的告警會讓人逐漸減少對所有告警的關注），在設計告警規則時需要兩個注意點：

告警必須由可靠的指標觸發，只有在用戶服務體驗處於降級時才能觸發。
告警必須是可操作的，即確定用戶已經受到了影響，需要採取行動。

　　SLA（Service Level Agreement，服務水平協議）是指系統服務提供者（Provider）對客戶（Customer）的服務承諾，即正常運行時間、響應能力和責任等可衡量指標的協議，描述了在達到或沒有達到 SLO 的後果，例如如果服務在一個月內未達到 99.95％的可用性，那麼該服務提供商每分鐘都會因不合規而補償客戶。如果 SLA 是與客戶之間的正式協議，那麼 SLO 就是向客戶作出的個人承諾，SLO 可以設定客戶期望。

　　通常，SLO 與 SLA 類似，但更嚴格。例如如果 SLA 中的數據可用性閾值設置爲 99.9%，那麼 SLO 中的數據可用性閾值應爲 99.99%。

1）SLI

　　SLO 是基於用戶最終體驗而不是系統指標作爲標準，來量化服務可用性的目標。而這個目標是用 SLI（Service Level Indicator，服務水平指標）來衡量的。

　　SLI 把系統狀態分爲好和壞。存在兩種類型的 SLI：

基於時間的測量，也叫基於窗口的測量，例如在每個 5 分鐘的窗口中，延遲小於 300ms 的 P99 分位。
基於事件的測量，也叫基於請求的測量，例如在一個給定的滾動時間窗口中，耗時小於 300ms 的事件比例。

　　建議設置基於事件測量的 SLI，因爲它提供了更可靠和更細化的方式來量化服務的狀態。假設將用戶體驗定義爲：用戶應該能夠成功地加載你的主頁並迅速看到結果。用一個 SLI 來表達，意味着對事件進行限定，然後確定是否符合條件，在這個例子中，SLI 將做以下工作：

篩選符合條件的事件，其中事件持續時間小於 100ms。
如果持續時間小於 100ms，並且成功地提供了服務，則認爲是好的。
如果持續時間大於 100ms，並且成功地提供了服務，則認爲是壞的，即使返回一個成功代碼。

　　綜上所述，可以將 SLA、SLO 和 SLI 的關係如下表展示：

SLI

SLO

SLA

衡量系統穩定性的指標，例如：

慢響應：響應時間超過2秒的請求數/請求數
求錯誤率：錯誤數/請求數

SLI 判斷規則，例如：

SLI ≤目標
下限 < SLl < 上限

SLA 與 SLO 類似，但判斷規則稍微寬鬆點，

並且會描述在達到或沒有達到 SLO 的後果

　　更多 SLI 指標（來自 Google 的 SRE 書籍）參考如下：

響應或者請求類型的服務。
- 可用性：服務成功響應的請求比例。
- 延遲：響應請求需要多長時間，超過某個閾值的請求比例。
- 吞吐量：可以處理多少個請求。
數據存儲類型的服務。
- 可用性：數據是否可以按需訪問，可以成功讀取和寫入的比例。
- 延遲：讀取和寫入需要多長時間，超過某個閾值的比例。
- 耐用性：用戶所需要的特定數據是否存在。
數據管道（Pipeline，將輸入的數據進行轉換並進行輸出，例如從多種來源收集日誌並生成報告）。
- 正確性：進入管道的產生正確的值的記錄所佔的比例。
- 新鮮度：新數據或處理結果需要多長時間出現。

2）錯誤預算

　　SLI 是衡量系統穩定性的指標，包括請求計數（例如每分鐘產生 2XX 或 5XX 響應的 HTTP 請求數），響應延遲時間（例如 HTTP 2XX 響應的延遲時間）等。SLO 是每個指標對應的目標，SLO 又會被轉化爲錯誤預算，因爲錯誤預算的形式更加直觀。轉化後，要做的穩定性提升和保障工作，其實就是想辦法不要把錯誤預算消耗完，或者不能把錯誤預算快速大量地消耗掉。

　　任何錯誤事件都會花費 SLO 中的一些錯誤預算（下面是一張錯誤預算消耗圖）。錯誤預算表示企業願意容忍的最大系統不可用性，即系統在不產生約定後果的情況下可以出現故障的最長時間。

　　如果 SLO 是爲了確保 99.9% 的請求成功，那麼基於時間的計算，表明系統在一個標準年內不可用的時間不超過 8 小時 45 分 57 秒，更多參數可參考下表。

SLO（正常運行時間佔比）	每年允許停機時間	每月允許停機時間
99.99%	52 分鐘 35 秒	4 分鐘 23 秒
99.95%	4 小時 22 分鐘 48 秒	21 分鐘 54 秒
99.9%	8 小時 45 分鐘 57 秒	43 分鐘 50 秒
99.5%	43 小時 49 分鐘 45 秒	3 小時 39 分鐘
99%	87 小時 39 分鐘	7 小時 18 分鐘

　　只要有足夠的錯誤，系統就可以提醒你有可能違反 SLO 的規定。如果一個潛在的條件影響了之前定義的那個用戶體驗，就應該觸發告警，因爲有人需要調查原因。基於 SLO 的告警都是基於症狀的：它們告訴你有問題。它們是可操作的，因爲現在要由響應者來確定爲什麼用戶看到了影響並採取行動加以緩解。

　　當錯誤預算耗盡時，保障服務穩定性的優先級要高於新功能的上線。如果可以預見到錯誤預算即將用完，那麼就有機會提前採取行動修復它，而不是任其發生。一個解決方案是追蹤錯誤預算消耗率：

選擇一個非零的閾值來發出告警，例如可以在預算降低到 30% 以下時發出告警。
創建預測消耗告警來觸發零級以上告警，這些預測會告訴你當前條件是否會導致消耗整個錯誤預算。

　　第四和第五章節的內容均來源於《深入淺出可觀測性》。

四、可觀測性平臺

　　以一款成熟的可觀測性平臺爲例，在建立 SLO 之後，就可以通過儀表盤來持續跟蹤，並將相關的 SLI 統一展示出來。同時，也可以針對 SLI 和 SLO 的狀態設定監控器，及時獲取異常事件的告警。

1）錯誤詳細

　　當通過儀表盤直接查看整個服務 SLO 和錯誤餘額的情況時，也能夠同時查看相關 SLI 的情況。例如如果發現頁面錯誤率有異常，可以進一步進行分析，查看錯誤的詳細情況。

2）錯誤統計

　　在錯誤分析頁面，還能進一步查看多個維度的錯誤統計。例如想了解具體哪些頁面有報錯，可以查看“頁面錯誤率排行”，然後進一步下鑽去查看這個頁面（也就是 View 查看器）的詳細信息。

3）頁面數據

　　通過 View 頁面，可以看到用戶訪問時的頁面性能數據，包括頁面地址、頁面加載類型、頁面加載時間、用戶停留時間等。如果列表最左側出現紅色小三角的標記，說明這個頁面是有報錯的，點擊其中一條可以查看詳細的信息。

4）網絡請求

　　因爲之前已經做了數據的關聯，所以可以繼續下鑽，查看相關的鏈路、日誌和指標信息，還能夠直接查看相關聯的視圖。也就是說，在一個界面中，可以多維度地查看各種數據。

　　比如說，點擊“Fetch/XHR”的標籤頁，就可以查看用戶在訪問時，向後端應用發出的每一個網絡請求，包括髮生時間、請求的鏈路和持續時間；如果網絡請求存在對應的 TraceID，而且已經和前端用戶訪問的數據進行了關聯，那麼就可以點擊列表中的某個請求，進一步下鑽來分析問題。

　　點開具體的請求之後會跳轉至對應鏈路的詳情頁，這裏可以看到鏈路 Tracing 的詳細信息，包括整條鏈路中每個 span 的流轉和執行時間。如下圖所示，這時候可以注意到有一條紅色標記的 span，這表示系統有報錯，可以在詳情中查看詳細的報錯信息，定位問題的原因。

5）關聯數據

　　還有的時候，問題的情況比較複雜，所以希望不僅能夠查看鏈路的屬性和耗時，也能夠直接查看相關的日誌、主機的性能、網絡情況以及相關聯的視圖，將各維度的數據綜合在一個界面來分析。

　　如下圖所示，當查看鏈路的詳細信息時，能夠同時關聯分析鏈路發生時相關主機的負載情況（包括指標和網絡）、相關的日誌等信息。

6）MySQL

　　在下圖中，可以將 MySQL 數據庫的監控視圖與 MySQL 相關的服務綁定在一起，這樣在查看 MySQL 相關的鏈路時，也能夠同時查看數據庫的負載情況，更加全面地分析問題。

五、平臺成熟度

　　建立可觀測性還必須有明確的指導方針，當評估可觀測性最終的實現結果時，可以將其分解爲 3 個關鍵問題：

出現問題時，我多久能收到通知？是在最終用戶使用體驗已經開始受到影響之前嗎？
如何快速地對問題進行分類並瞭解其影響？
如何找到根本原因以便解決問題？

　　對應着這三個問題，可以將可觀測性成熟的程度框架分爲 3 個階段。在每個階段，重點都是在出現問題的時候，儘可能快地修復問題，或是減輕對最終用戶的影響。

1）感知到問題

　　解決問題的第一步是知道問題的存在，而且最好是在最終用戶知道或者是被真正影響之前。通常，知道問題正在發生就足以觸發補救的措施。

　　例如，如果你部署了新版本的服務，而該服務觸發了影響用戶使用的告警，那麼回滾部署就是補救問題的最快途徑。我們不需要了解事件的全部影響或者診斷事件的根本原因，因爲這些可以等到事後再做檢查和修復。

　　在這個階段的關鍵動作和考量包括下面幾點。

快速告警：縮短問題發生和通知觸發之間的時間。
提高信噪比：確保告警是可操作的。
將通知範圍僅限於需要採取行動的團隊：從一開始就確定問題範圍並將其發送給正確的團隊。
自動化告警設置：讓大多數服務或主機產生相同的指標數據，這意味着自動化或模板化告警，它可以幫助工程師瞭解問題，而無需複雜的設置過程。

2）對問題進行診斷

　　這一階段的目標是快速瞭解問題的背景和影響。一旦告警觸發，如果最近對系統的更改不是很明顯需要回滾，下一步就要了解業務影響和嚴重性了。

　　例如，如果你確定只有一組有限流量切換中的用戶受到影響，那麼關閉該流量切換就可能解決問題。或者，如果對一個可用區域或集羣的請求受到影響，你可以將請求重新路由到其他區域或集羣。
在這個階段的關鍵動作和考量如下。

具備上下文的儀表板：將告警直接鏈接到儀表板，這些儀表板不僅顯示告警的來源，還顯示相關的上下文數據。
高基數數據：允許工程師對數據進行“切片”，從而進一步明確問題的影響範圍。
高維度數據：允許工程師通過儘可能多的角度、條件來聚合信息，從而在排查故障時縮小範圍，明確方向。

3）理解問題

　　這個階段最好發生在問題被修復之後，此時工程師可以花時間定位和理解潛在問題，而不會受到業務和用戶影響帶來的直接壓力。隨着微服務數量的不斷增加，對事件進行事後分析就像是複雜網絡中的導航，它也決定了你需要與哪個服務所有者
合作。

　　在這個階段的關鍵動作和考量如下。

輕鬆理解服務依賴關係：識別有問題的服務的直接上下游依賴項。
在不同數據類型之間進行聯合和跳轉的能力：對於複雜的問題，你需要綜合考量儀表盤上的指標趨勢、異常值，跳轉到相關的日誌和鏈路追蹤信息，需要統一的工具給出數據關聯分析結果，而不是人肉地做關聯和排查。
更進一步的是智能分析和預測：能夠自動檢測基礎設施和應用程序問題，幫助用戶提前發現 IT 系統運行過程中潛在的問題，通過根因分析，快速定位異常問題的原因，並進行提前的預警。

參考資料：

OpenTelemetry Example

通過OpenTelemetry接入Node.js Trace數據（阿里雲）

通過OpenTelemetry上報Node.js應用數據（阿里雲）

Distributed Tracing 101 for Full Stack Developers

如何基於標準化的OpenTelemetry構建APM探針能力