根據維基百科的定義，「可觀測性 (Observability) 是衡量我們能多有效地透過系統的外部輸出，來推斷其內部狀態的一項指標」(2024)。換句話說，可觀測性指的是您透過檢視系統（例如應用程式或服務）所產生的資訊，來理解其內部運作狀況的容易程度。

分散式系統 (Distributed System) 是由一組獨立的電腦或節點 (nodes) 所組成的網路，它們協同運作以執行任務，表現得就像是一個單一系統。這類系統廣泛應用於雲端運算 (Cloud Computing) 等領域，其中應用程式的不同部分會在不同的伺服器上運行，藉此共享資源並達成工作負載平衡 (balance the workload)。由於分散式系統的複雜性，要在任何時間點掌握每個元件 (component) 內部的運作情形，往往是一項艱鉅的挑戰。這正是可觀測性變得至關重要的原因。

為了讓分散式系統具備可觀測性，我們必須以一種能讓我們推導其行為的方式來建立狀態模型。這個模型由三個要素組成：

首先是 工作負載 (Workload)。這是系統為了達成目標所執行的操作。例如，當使用者發送一個請求時，分散式系統通常會將其拆解為由不同服務處理的較小任務。這通常也被稱為 交易 (Transactions)。

第二是構成分散式系統結構的 軟體抽象層 (Software Abstractions)。這包含了諸如 負載平衡器 (Load Balancers)、服務 (Services)、Pods、容器 (Containers) 等元件。

最後是提供 運算資源 (Computational Resources)（如 RAM、CPU、磁碟空間、網路）以執行工作的 實體機器 (Physical Machines)。

根據我們的背景不同，在調查分散式系統的效能或進行故障排除時，我們往往會有特定的 切入視角 (bias)。應用程式開發人員通常專注於與工作負載相關的層面，而 維運團隊 (Operations Teams) 則傾向於關注實體資源。

為了真正理解一個系統，我們必須結合來自多個角度的洞察，並釐清它們彼此之間的關聯。然而，在我們能進行分析之前，必須先捕捉系統行為的各個面向。這通常是透過結合 日誌 (Logs)、指標 (Metrics) 和 追蹤 (Traces) 來完成的。

日誌（Logs）是一種僅能追加（append-only）的資料結構，用來記錄系統中發生的事件。 一筆日誌紀錄包含標示事件發生時間的時間戳記（timestamp），以及描述事件細節的訊息。然而，要制定一個標準化的日誌格式並非易事。其中一個原因是，不同類型的軟體通常傳達不同的資訊內容。HTTP 網頁伺服器的日誌，肯定與核心（kernel）的日誌截然不同。但即使是相似的軟體，人們對於「好的日誌」應具備的樣貌也常有不同看法。

除了內容之外，日誌格式也會隨著其使用對象（consumers）而有所不同。最初，純文字格式是為了迎合人類的可讀性而設計。然而，隨著軟體系統變得日益複雜，日誌的量級很快就變得難以管理。為了應對這個問題，我們開始將事件編碼為鍵值對（key/value pairs），使其具備機器可讀性（machine-readable），這通常被稱為結構化日誌（structured logging）。

此外，貨櫃化（containerized）應用程式的分散式與短暫特性（ephemeral nature），意味著登入個別機器去翻找日誌的做法不再可行。因此，人們開始構建日誌代理程式（logging agents）和通訊協定，將日誌轉發到專用的服務中。這些日誌系統實現了高效的儲存，並具備在集中位置搜尋與過濾日誌的能力。

服務在執行時捕獲的測量值。

日誌（Logs）非常擅長提供關於個別事件的詳細資訊。然而，有時我們需要掌握系統當前狀態的宏觀概覽（high-level view）。這正是指標（Metrics）派上用場的地方。

指標是透過對一組事件應用統計運算後，所推導出的單一數值。換句話說，指標代表的是一種聚合數據。這非常有價值，因為它們精簡的呈現方式，讓我們能夠將系統隨時間變化的情形繪製成圖表。

因應這些需求，業界開發了用來萃取指標的儀器（instruments）、用來表示與傳輸資料的格式與通訊協定、專門用來儲存資料的時序資料庫（time-series databases），以及讓終端使用者能存取這些資料的前端介面。

隨著分散式系統的規模擴大，傳統日誌系統在對複雜問題進行除錯（debug）時，顯然經常感到力有未逮。原因在於，我們往往必須理解系統中一連串事件的脈絡。

在單機環境下，堆疊追蹤（stack traces）讓我們能將例外狀況（exception）追溯回特定的程式碼行數。然而在分散式環境中，我們無法享有這種便利。取而代之的是，我們必須進行大量的過濾，才能定位出我們關注的日誌事件。為了理解整體脈絡（context），我們必須識別其他相關聯的事件，例如觸發該日誌紀錄的特定請求或交易，以及該請求在系統中處理時所涉及的服務或微服務之順序。這通常會導致大量的人工操作（例如比對時間戳記），或者需要對應用程式具備深厚的領域知識。為了正視這個問題，Google 開發了 Dapper，並普及了分散式追蹤（distributed tracing）的概念。

從本質上來說，分散式追蹤就是「強化版」的日誌記錄（logging on steroids）。其核心概念在於為日誌添加交易脈絡（transactional context）。這使得我們能夠推斷因果關係，並還原請求在系統中的完整路徑（journey）。

遙測（Telemetry） 是指從遠端或分散式系統自動收集並傳輸資料的過程，目的是為了監控、測量及追蹤這些系統的效能或狀態。遙測資料提供了關於應用程式各個部分運作情形的即時洞察（real-time insights）。這些數據成為可觀測性工具的基礎，協助開發人員和系統管理員觀察、除錯（troubleshoot）並最佳化系統，而無需手動檢查每一個元件。

從表面上看，Log（日誌）、Metric（指標）和 Trace（追蹤）在其生命週期和組成元件上有許多相似之處。一切都始於 Instrumentation（儀器化/埋點），負責捕捉並發送資料。這些資料必須具備由格式定義的特定結構。接著，我們需要一種機制來收集並轉發這些遙測數據。通常會有某種 Agent（代理程式） 來進一步擴充（enrich）、處理和批次打包資料，然後將其攝入（ingest）後端系統。這個過程通常涉及一個資料庫，以有效地儲存、索引和搜尋大量的資料。最後，會有前端分析介面讓終端使用者能存取這些數據。

然而，在實務上，我們針對每種類型的遙測開發專用系統是有充分理由的：每一種遙測訊號（signal）都帶來了獨特的技術挑戰。這些挑戰主要源於資料本質的不同。

資料模型、交換格式和傳輸協定的設計，高度取決於你處理的是非結構化或半結構化的文字資訊（Logs）、時間序列中緊湊的數值（Metrics），還是描述事件間因果關係的圖狀結構（Traces）。即使是針對單一種訊號，業界在這些議題上也尚未達成共識。

此外，我們如何運用並從遙測中獲取洞察的方式也大相徑庭。一個系統可能需要執行全文檢索、檢查單一事件、分析歷史趨勢、視覺化請求流程、診斷效能瓶頸等等。這些需求具體體現在儲存、存取模式、查詢功能等方面的設計與最佳化上。

當面對這些技術挑戰時，垂直整合（vertical integration） 成為了一種務實的解決方案。在實務中，可觀測性廠商往往將問題範圍縮小到單一訊號，並提供生成資料的 Instrumentation 以及分析遙測的工具，形成一個單一且完全整合的解決方案。

The Three Pillars of Observability: Metrics, Traces and Logs

正因為針對 Logs（日誌）、Metrics（指標）和 Traces（追蹤）擁有各自專用的系統，我們才普遍將它們稱為可觀測性的「三大支柱」。

「支柱」這個概念提供了一個極佳的思考框架（mental framework），因為它強調了以下重點：

• 遙測資料（telemetry）區分為不同的類別。
• 每一根支柱都具備其獨特的優勢，且能獨當一面。
• 這些支柱具有互補性，必須結合在一起，才能構成實現可觀測性的穩固基石。

面對市面上充斥著大量的開源與商用可觀測性解決方案，你可能會（很合理地）問自己：

1. 如果針對 Logs、Metrics 和 Traces 的產生、收集、儲存與分析，都已經有許多成熟的解決方案了，那我為什麼要在意（OpenTelemetry）？
2. 目前的可觀測性現狀到底有什麼問題？
3. 喔，好極了……這該不會又是一次試圖制定標準的嘗試吧？

這些都是合理的問題。為了回答這些問題，我們必須點出在建構與使用那些「基於支柱（pillar-based）」的可觀測性系統時，所衍生出的一些缺點。

首先，遙測資料的品質本身存在不足。為了說明這一點，讓我們想像一下我們要調查某個問題的根本原因（root cause）。

問題的第一個徵兆，通常是來自警報，或是指標儀表板（metrics dashboard）上的異常。為了確認該事件值得調查，我們必須先形成初步的假設。目前我們手上唯一的資訊是，在特定時間點發生了某些事情。因此，第一步通常是使用指標系統，去尋找其他在時間上具備關聯性（temporally correlated）且呈現異常行為的指標。

在對問題做出有根據的推測後，我們會希望深入挖掘（drill down）並調查問題的根本原因。為了獲取額外資訊，我們通常會切換到日誌系統（logging system）。在這裡，我們撰寫查詢語法並進行大量的過濾，試圖找出與那些可疑指標相關的日誌事件。

發現感興趣的日誌事件後，我們通常想了解該操作發生當下更廣泛的脈絡（context）。遺憾的是，傳統日誌系統缺乏重建特定交易中事件鏈的機制。傳統日誌系統往往無法捕捉操作的完整脈絡，導致難以將跨越不同服務或元件的事件關聯起來。它們經常缺乏保留關鍵 Metadata（如 Trace ID 或 Span ID）的能力，而這些對於連結相關事件至關重要。這種限制導致了系統行為視角的破碎化，單一操作的「故事」散落在多個日誌中，缺乏清晰的敘事。此外，缺乏標準化的查詢語言或介面，更加深了有效搜尋與分析日誌的難度，因為維運人員必須仰賴客製化腳本或手動過濾，才能發掘出模式與異常。

如果我們將視角從「構建」可觀測性解決方案的人，切換到「使用」它的人，就會發現一種本質上的脫節。真實世界的問題並不是由 Log、Metrics 或 Tracing 構成的。相反地，我們必須在不同類型的遙測數據之間來回切換，以建立心智模型（mental model）並推斷系統的行為。由於可觀測性工具往往是彼此不相連的資料孤島（silos），要釐清資訊片段之間的關聯，會給維運人員帶來巨大的認知負擔（cognitive load）。

另一個讓根本原因分析（root-cause analysis）變得困難的因素是，遙測資料往往深受「缺乏一致性」所苦。

這導致在不同服務或元件之間關聯（correlating） 事件變得相當困難，因為缺乏標準化的方式來識別相關聯的事件，例如透過 Trace ID 或 Span ID 來串接。

此外，目前也沒有直接了當的方法，能將多個針對特定解決方案（solution-specific）的日誌函式庫，整合到一個連貫的系統中。這最終導致我們對系統行為的觀察變得破碎且脫節。

讓我們從開源軟體開發者的角度來看待這件事。現今，大多數的應用程式都是建構在開源函式庫、框架和獨立元件之上。由於大量的運作都發生在應用程式開發者所撰寫的商業邏輯之外，因此從這些開源元件收集遙測數據（telemetry）至關重要。最了解軟體運作時哪些資訊至關重要的，莫過於開發者與維護者本身。然而，目前缺乏一種透過原生儀器化（native instrumentation） 來傳遞這些資訊的良好方式。

其中一個選項是選用特定可觀測性解決方案的儀器化工具。然而，這會為專案增加額外的相依性（dependencies），並強迫使用者將其整合到自己的系統中。雖然同時運行多套日誌與指標系統雖然不切實際（impractical），但在技術上尚屬可行；然而，分散式追蹤（Tracing）卻是完全不可能的，因為它需要所有人達成共識，採用統一的標準，才能讓 Trace Context 的傳遞（propagation） 順利運作。

電腦科學界解決問題的一個常見策略，就是增加一層間接層（indirection）。與其嵌入特定廠商的儀器化程式碼，開源開發者通常會提供可觀測性的 Hooks。這讓使用者能撰寫轉接器（adapters），將開源元件連接到自己的可觀測性系統。

雖然這種方法提供了較大的彈性，但也伴隨著不少問題。例如，每當軟體推出新版本時，使用者都必須留意並更新他們的轉接器。此外，這種間接層也增加了系統開銷（overhead），因為我們必須在不同的遙測格式之間進行轉換。

讓我們試著戴上終端使用者的帽子（站在使用者的立場）來看待這件事。一旦決定採用某個解決方案，應用程式的程式碼庫（codebase）中就會遍佈著許多針對該特定解決方案的函式庫呼叫（library calls）。

若日後想要轉換到另一個可觀測性工具，我們將被迫把現有所有的儀器化程式碼（instrumentation）連根拔除並替換，同時還得遷移我們的分析工具。這種「重新儀器化（re-instrumentation）」所需的巨大前期成本，使得遷移變得困難重重，而這正是供應商綁定（Vendor Lock-in） 的一種形式。

這個方程式的最後一個環節，是可觀測性廠商本身。乍看之下，廠商似乎是唯一從現狀中獲利的一方。在過去，高品質的儀器化（instrumentation）是與競爭對手做出市場區隔（differentiation）的絕佳方式。此外，由於為大量既有軟體開發整合介面（integrations）非常昂貴，可觀測性市場具有相對較高的進入門檻（barrier to entry）。

由於客戶對昂貴的「重新儀器化（re-instrumentation）」望之卻步，既有的老牌廠商面臨較少的競爭與創新壓力。然而，他們也正經歷著巨大的痛點。過去十年間，軟體開發的速度呈現指數級成長。現今 異質化（heterogeneous） 的軟體生態，使得要維護針對每一個函式庫、框架和元件的儀器化支援，變得根本不可能。

一旦廠商開始難以提供（特定的）儀器化支援，客戶就會開始拒絕採用他們的產品。結果導致各家解決方案都在競爭誰能打造出最好的「N 對 N 格式轉換器」，而不是將這些資源投入到開發更棒的分析工具上。另一個缺點是，轉換那些由外部來源產生的資料，往往會導致遙測資料品質的劣化（degradation）。一旦資料定義不再明確，分析起來就變得更加困難。

OpenTelemetry (OTel) 是一個開源專案，旨在提供標準化的工具和 API，用於生成、收集和匯出追蹤 (Traces)、指標 (Metrics) 和 日誌 (Logs) 等遙測數據。其目的是讓開發人員能深入掌握應用程式的可觀測性，進而協助監控、故障排除以及最佳化軟體系統。

OpenTelemetry 的主要目標包括：

• 統一的遙測 (Unified telemetry)： 將追蹤、日誌和指標結合至單一框架中，實現所有數據的關聯分析，並建立遙測數據的開放標準。
• 供應商中立 (Vendor-neutrality)： 可整合不同的後端系統來處理數據（不被特定單一廠商綁定）。
• 跨平台 (Cross-platform)： 支援多種程式語言（如 Java、Python、Go 等）與平台，使其能靈活適用於各種開發環境。

通常透過定義某個事物「不是什麼」，會更有助於理解它的本質。

OpenTelemetry 是：

1. 不是一套多合一 (All-in-One) 的監控或可觀測性工具 OpenTelemetry 不會取代像 Datadog、New Relic 或 Prometheus 這類功能完整的監控或可觀測性平台。相反地，它協助收集並標準化遙測數據（追蹤、指標、日誌），讓您可以將數據發送到這些工具進行視覺化和分析。
2. 不是數據儲存或儀表板 (Dashboarding) 解決方案 OpenTelemetry 本身不負責儲存或視覺化數據。它專注於收集和匯出遙測數據到負責儲存與呈現的外部系統，例如 Grafana、Jaeger 或 Prometheus。
3. 不是預先設定好的監控工具 OpenTelemetry 是一套用於收集和匯出數據的工具組 (Toolkit)，但它需要進行設定並與其他系統整合。它不會自動提供開箱即用 (out-of-the-box) 的監控或告警功能。
4. 不是效能最佳化工具 (Performance Optimizer) 雖然 OpenTelemetry 協助您收集詳細的效能數據，但它不會自動將應用程式效能最佳化。它是一種診斷工具，協助您收集數據洞察，以作為手動調校 (Manual tuning) 的依據。

總結來說： 本質上，OpenTelemetry 是一個針對遙測數據的「整合與標準化工具」，而非監控、日誌記錄或效能管理的多合一解決方案。它透過標準化數據收集流程，來與其他工具相輔相成 (Complements)。

截至本文撰寫時（2024 年 5 月），OpenTelemetry 是 CNCF（雲端原生運算基金會）中成長速度第二快的專案。OpenTelemetry 之所以獲得如此高度的關注，是因為它有望為我們產生遙測數據的方式帶來根本性的轉變 (Fundamental shift)。

我們必須記住，「可觀測性 (Observability)」還是一個相當年輕的領域。在過去，快速的創新步調以及（廠商間的）利益衝突 (Conflicts of interest)，阻礙了我們為遙測數據制定出一套廣泛採用的標準。然而，憑藉著 OpenTelemetry 目前的時機點與發展動能 (Momentum)，看來確實有極大的機會能推動遙測數據通用面向的標準化。

在本章中，我們涵蓋了 工作負載與資源分析（Workload and resource analysis） 的核心概念，為您在監控與優化現代應用程式時所需的術語打下基礎。我們強調了 可觀測性（Observability） 的重要性，以及它在了解分散式系統健康狀況與效能方面所扮演的關鍵角色。

您現在已經了解可觀測性的三大支柱——日誌（Logs）、指標（Metrics）與追蹤（Traces）——以及它們如何各自發揮獨特作用，以提供系統行為的完整視野。本章也點出了現代化、多語言開發（Polyglot）及分散式應用程式所帶來的挑戰，例如日益增加的複雜度，以及難以跨多種服務來關聯 遙測資料（Telemetry data） 的問題。

我們探討了 OpenTelemetry 是什麼——它是一個 供應商中立（Vendor-neutral） 的開源工具，用於收集與標準化遙測資料——並釐清了它「不是」什麼。我們特別強調 OpenTelemetry 並非一個一站式的可觀測性平台，而是一個強大的整合與資料收集工具。

最後，我們檢視了 OpenTelemetry 如何透過提供一種統一的方式，以高度適應性且跨平台的手法來收集追蹤、指標與日誌，從而解決傳統可觀測性解決方案的局限性。

A. 指標 (Metrics) 提供個別錯誤的詳細解釋，日誌 (Logs) 總結整體效能，而追蹤 (Traces) 則記錄每個請求完成所需的時間。

B. 追蹤 (Traces) 記錄即時 CPU 使用率，日誌 (Logs) 顯示效能趨勢，而指標 (Metrics) 則記錄請求在系統中的完整歷程。

C. 指標 (Metrics) 與追蹤 (Traces) 用於記錄使用者行為，而日誌 (Logs) 則監控伺服器效能與錯誤。

D. 日誌 (Logs) 捕捉用於故障排除的歷史資料，指標 (Metrics) 追蹤隨時間變化的系統效能，而追蹤 (Traces) 則跟隨請求在分散式系統中的路徑，以精準定位延遲或故障發生的位置。

A. OpenTelemetry 是一個針對分散式系統的完整監控與告警平台。

B. OpenTelemetry 是一個針對遙測資料（日誌、指標與追蹤）的資料收集工具，並可與可觀測性平台進行整合。

C. OpenTelemetry 是一個特定供應商專用的工具，用於在微服務環境中收集指標。

D. OpenTelemetry 會自動最佳化（Optimize）分散式應用程式的效能。

A. 正確 (True)

B. 錯誤 (False)

A. 來自每個服務的資料會發生衝突，導致無法採信任何日誌或指標。

B. 當偵測到效能問題時，每個服務會停止產生日誌，導致無法進行故障排除。

C. 難以將跨服務的資訊進行關聯 (Correlate)，這使得難以追蹤請求的流向，或無法精準定位 (Pinpoint)問題發生的位置。

D. 您將無法同時存取所有服務的日誌，導致在識別根本原因 (Root cause) 時產生延遲。