Observability 3 本柱＋Profile 打造完整可觀測性解決方案

前言

想在現代化的雲端原生環境中，識別效能瓶頸和低效的 CPU 使用率，是件極為複雜且極具挑戰的任務。 

隨著雲端原生環境的複雜性增加，使用者也急需一套高效的可觀測性解決方案。一般來說，企業能透過可觀測性的三大核心資訊－指標、日誌和軌跡，來優化應用程式和基礎架構的可靠性和效能。雖然指標、日誌和軌跡能為可觀測性提供富含價值的資訊，然而，它們仍無法提供用者系統最全面的訊息。

這篇文章，我們將探討為何不間斷的剖析訊號（profiling signals）是可觀測性工具棧中不可或缺的元素，以及如何利用剖析訊號彌補指標、日誌和軌跡的不足。另外，我們也會談及將這 4 項可觀測性訊號整合至統一平臺，而非將其分散為獨立工具的重要性。

4 種類型的可觀測性訊為何？

在進入細節前，我們先簡單地介紹 4 種可觀測性訊號的形式以及它們常見的應用範例。

Profile （剖析，在本文中也稱為剖析訊號）：剖析信號是一種堆疊追蹤 (stacktraces)，它提供代碼於何處耗費資源的詳細資訊（通常為 CPU 週期或記憶體）。剖析訊號能提供系統中最耗資源區域的總覽，以及單行程式碼的細節。

Metrics（指標）：指標是代表系統在特定時間狀態和性能的數值。這種訊號通常被用於監測系統健康狀況、識別趨勢以及觸發告警訊息。

Log（日誌）：日誌是系統產生的事件和訊息紀錄。它們提供對系統行為的洞察，並協助識別異常。

Traces（軌跡）：軌跡是系統中請求路徑（Request Path）的詳細記錄。它們被用來了解系統物件中彼此的相依性和互動關係。

為何日誌、指標和軌跡無法應付日漸複雜的雲端環境？

可觀測性不是僅用於監測，而是用來更全面的了解整個 IT 系統，幫助 IT 人員回答各種「為什麼這樣」、「為什麼那樣」的問題。為了有效地了解系統，開發人員、SRE（Site Reliability Engineer） 和雲端工程師需要對整個系統中的運算資源有更細微的能見度，包括那些潛伏於表面之下的未知因素（unknown-unknowns），這也是剖析訊號（在正式環境中）在可觀測解決方案中扮演關鍵角色的地方。

雖然指標、日誌和軌跡在提供系統效能洞察方面，都具備各自的優勢，然而與之相比，剖析訊號能提供更深層的能見度，還能被用來識別藏匿於細節中的問題，例如：資料結構和記憶體配置的相關問題，以及 Kernal Space（核心空間） 與 Userspace（使用者空間） 的代碼能見度（Code Visibility）。

換句話說，監測指標、日誌和軌跡其實就如同監測人體的重要生命跡象。這些資訊提供關於健康狀況和效能的基礎資訊，例如：體溫、體重、心率以及導致症狀發生的事件紀錄。與之相比，剖析就像照 X 光，它讓使用者能夠看到身體內部的運作狀況以及了解不同系統間如何互相作用。因此，剖析訊號為使用者提供的資訊更詳細，也能幫助使用者發現宏觀指標無法識別的問題。

此外，剖析訊息提供的能見度相較過往又更加的廣和深，這賦予使用者揭開系統中未知因素的能力。這種更深層的全系統能見度讓使用者擺脫對未知的猜想，並讓其快速觸及「為什麼」問題的核心，例如：為什麼我們把 X ％ 的 CPU 資源花在功能 Y 上？為什麼 Z 這個現象會發生？整個 IT 環境中，耗費最多資源的功能為何？

Elastic Universal Profiling 能夠幫助 DevFinOps（開發、維運和財務團隊）更好地了解特定程式碼對雲端運算資源和碳足跡的影響。DevFinOps 能透過 Elastic Universal Profiling 確定資源被浪費於哪些特定區域，並採取行動來優化和降低成本，以及降低應用程式對環境的衝擊，最終節省成本與企業的碳足跡。

總而言之，在大多數的情況下，指標和軌跡為系統中的「可見的潛在變因」提供能見度。日誌，在另一方面為系統中「已知又可解決的因素」提供能見度。可觀測性的三本柱為系統提供宏觀層面的能見度。如果可觀測性解決方案缺乏剖析訊號，系統中的能見度將出現極大的缺口，因為系統中總是存在著「未知的潛在風險」。剖析訊號透過提供系統微觀的能見度，幫助減少系統中的未知漏洞，而這種能見度在現代的雲原生環境更是不可或缺。

我們將在下段探討如何利用周哈里窗架構深入「未知潛在變因」這個概念。

周哈里窗（Johari Window）架構和可觀測性的關係為何？

周哈里窗（Johari Window）這個框架，是由 Joseph Luft 和 Harry Ingham 二人共同提出，該框架被國防和風險管理領域中的專業人士廣泛採用以評估威脅和風險。根據該框架，系統的資訊分類為：已知又可解決的因素（Known-Known）、可見的潛在變因（Known-Unkown）以及在上述分類後仍無法歸類的潛在風險（Unkown-Unkown）。

可觀測性旨在透過搜集和分析資料，以獲得系統中的洞見，因此我們利用周哈里窗將可觀測性訊號進行以下分類：

• 已知又可解決的因素（Known-Known）泛指我們知道也能察覺的變因。我們能將已知又可解決的因素比喻為可觀測性中的日誌。因為唯有已知的資訊才能被其記錄下來。
• 可見的潛在變因是指當我們意識到自己不了解某些事情的真相，透過進一步地調查，將這些未知找出。我們能將可見的潛在變因比喻為可觀測性中的軌跡和指標。例如：指標讓我們監測預定義的測量值，例如：平均回傳值和端點吞吐量（Calls-per-minute），而軌跡則能協助調查系統中一個特定的請求在系統中的流向。
• 無法歸類的未知因素指的是經由上述分類後仍無法歸類的未知變因，而這些未知的潛在風險在造成傷害前都能隱蔽自己的蹤跡。這與軟體工程中的黑天鵝理論有些類似。因此 IT 人員需要剖析訊號來破解系統中的未解之謎。

總而言之，雖然指標、日誌和軌跡提供使用者以宏觀的視野監測系統資訊，但剖析訊號卻能提供使用者更詳細、更細粒度視角來監測系統內部的運作流程。這種深層的可觀測性可以幫助更好地識別潛風險並降低平均檢測時間（MTTD）。

更全面的監測組合：可觀測性＋剖析訊號

單單依賴可觀測性中的 3 大指標或剖析資訊是不夠的。

為了加強可觀測性的優勢，建議使用者在統一平臺上搜集以上 4 種形式的訊號－指標、日誌、軌跡和剖析訊號。這些訊號能幫助 IT 人員更全面的了解他們的環境，並賦予他們利用單一事實來源（single correlated source of truth）來回答問題的原因、內容、地點和時間。另外，為了將投資報酬率最大化，企業必須擁有一個能將所有可觀測性訊息整合至單一平台的高效策略。

系統中的工具氾濫是當前可觀測性面臨的主要問題。根據 Gartner 的報告，許多企業中的分布式團隊會使用為數眾多的工具來監測它們軟體棧中的各個部分，但這卻會造成資料孤島、更高的開銷以及更長的平均修復和檢測時間（ MTTD 和 MTTR）。

Elastic Observability 透過將指標、日誌、軌跡和剖析訊號整合至統一平臺上。對此，Elastic Universal Profiling（測試版）是 Elastic Observability 中的頭等物件（ first-class citizen），因為 Elastic Universal Profiling 旨在打造一個將指標、日誌和軌跡更緊密結合。

Elastic Observability 和 Universal Profiling

Elastic Universal Profiling 提供使用者全系統和整個產品線的不間斷剖析訊號。

Elastic 的 Universal Profiling 具有輕量化以及無需調整設備細節的特性。以eBPF 作為核心，它克服了其他剖析解決方案的局限性，因為使用者無需更改應用程式代碼。對此，他們能更快速地找出效能瓶頸、降低雲端成本以及優化平均檢測和修復時間。

受益於低耗能的特性，Universal Profiling  平均耗費不到 1% 的 CPU 資源。利用這種優勢，它能夠在正式環境中大規模地為使用者提供更廣、更深的基礎架構和雲原生環境能見度。

對於一個在幾百個伺服器上運行的正式環境應用程式，初步結果顯示，優化程式碼能夠幫助節省 10％-20% 的 CPU 資源，從而降低每年的成本以及碳排放。

Universal Profiling 提供前所未見的系統能見度

總而言之，可觀測性的核心旨在完整的了解系統資訊，而非監測幾個關鍵指標。為了達成目的，IT 人員必須在統一的可視化解決方案中使用指標、日誌、軌跡和剖析資訊。然而單靠可觀測性中 3 種型態的資訊（指標、日誌和軌跡）是不夠的，使用者還必須不間斷的搜集剖析訊息。因為剖析訊息就如同放大鏡，為系統中的未知領域提供細粒度的能見度，找出問題的解答，並填補其他訊號留下的資訊漏洞。

一套全面的可觀測性策略必須能夠在統一的平台上同時搜集以上 4 種可觀測訊息。Elastic Observability 透過指標、日誌、軌跡和連續剖析訊號為使用者提供統一平台，並同時解決監測工具龐雜的問題。