可觀測性與監控：兩者有何不同？

當應用程式發生問題時，客戶會受到影響，最終也會影響到業務本身。IT 團隊必須全力找出問題的根本原因並儘快解決。而日益複雜且分散的雲端架構讓應用程式服務變得更加難以掌握，使情況更加複雜。這時，監控與可觀測性就能派上用場，協助找出問題的根本原因。

可觀測性常被當作監控的同義詞使用。這兩個術語經常被交替使用，但實際上並不相同，剛接觸 IT 基礎架構與軟體開發的初學者常常對兩者感到困惑。這是因為兩者雖然都以維持系統健康為目標，但在處理問題的目的、方法與範疇上卻各不相同。

那麼，可觀測性與監控之間究竟有什麼差異？您又該如何判斷哪一種更適合您組織的需求呢？您需要的是可觀測性，還是監控就已足夠？我們將深入探討兩者的運作方式，協助您找到這些問題的答案。

監控：傳統方法

什麼是監控？

監控是指從 IT 系統收集、擷取並分析彙整資料，以評估系統健康狀態的過程。這類資料的範例包括應用程式、基礎架構及/或雲端遙測資料。多年來，監控一直是維持系統順暢運作的首選解決方案。

監控仰賴預先定義的指標，例如 CPU 或記憶體使用率、網路流量、日誌與追蹤資料。舉例來說，包括檢查伺服器狀態、網路延遲、回應時間、磁碟與 CPU 使用率等。這些資料讓 IT 團隊能夠即時追蹤基礎架構與應用程式的效能與可用性。監控工具與平台可提供儀表板與警示，並具備報告功能，協助 IT 團隊監控各元件、預測可能發生的問題，並排解特定環境中出現的問題。

監控真正展現其價值之處，在於分析長期趨勢與發出警示。它不僅能顯示應用程式的運作狀況，還能呈現其隨時間變化的使用情形。

監控的用途為何？

現今的網頁應用程式會運用多種類型的監控，例如基礎架構監控（Infrastructure Monitoring）、合成監控（Synthetic Monitoring）以及真實使用者監控（Real User Monitoring，RUM）。以下說明這些監控類型的用途：

• 基礎架構監控（Infrastructure Monitoring） 追蹤與 IT 系統目前健康狀態相關的即時指標，例如伺服器健康狀態、正常運行時間與資源使用率。
• 合成監控（Synthetic Monitoring） 通常用於監控短期趨勢，透過自動化工具來測量系統的功能。例如，它會使用範例數值來判斷網頁應用程式是否如預期般運作。
• 真實使用者監控（Real User Monitoring，RUM） 更適合用於監控長期趨勢，其做法是記錄使用者與應用程式之間的實際互動，藉此了解應用程式的效能或功能是否符合預期。

監控的限制

監控雖然實用，但也存在明顯的限制。試著想像您的 IT 環境是一位正在接受診斷的病患——監控能揭露病患的症狀，但這些症狀往往不足以揭示這些症狀與問題背後更深層的原因。

監控的限制包括：

• 無法偵測根本原因或提供解決方案： 監控能協助團隊觀察系統效能，並在偵測到已知故障時發出警示，但無法告訴您問題為何發生，也無法告訴您該如何解決。
• 僅能識別「已知的未知」： 監控只能根據預先定義的條件偵測問題，您必須事先知道需要追蹤哪些指標與日誌。如果發生團隊未曾預料、超出預先定義條件範圍的問題，監控便無法察覺，進而導致遺漏關鍵的正式環境故障及其他問題。
• 無法主動解決問題： 監控只能在超出預設錯誤門檻時做出被動反應，卻無法協助您在問題發生前加以預測、診斷根本原因，或主動採取措施防止問題發生。
• 不適用於現代分散式環境： 監控工具傳統上各自獨立運作，在現代雲端架構以及更大型、分散式的環境中，其效率相當有限。 簡而言之，監控通常屬於被動反應性質，著重於找出症狀，而非解決根本問題。

可觀測性：因應複雜系統的現代解決方案

什麼是可觀測性？

可觀測性是指根據外部輸出來理解複雜系統內部狀態的能力，具體來說，就是透過分析系統產生的資料，例如日誌、指標與追蹤資料。當系統具備可觀測性時，使用者無需額外的測試或撰寫程式碼，即可從系統產生的資料中找出效能問題的根本原因。

可觀測性解決方案會分析輸出資料，評估系統的健康狀態，並提供可付諸行動的洞見來解決問題。這讓 DevOps 團隊能以整體且統一的視角，掌握整個 IT 環境的脈絡並理解各元件間的相依關係。最終，團隊便能主動偵測問題，並更快速地解決問題，特別是在分散式系統中。

可觀測性工具提供可自訂的儀表板、自動化功能、分析能力與警示，協助團隊更快速、更有效地進行根本原因分析。部分平台甚至更進一步，能自動修正這些問題。

簡而言之，可觀測性是一種不斷演進的工具，用於提升現代 IT 維運及其所管理服務的效能與韌性。韌性提升，生產力也隨之提升。

什麼時候需要可觀測性？

系統越是複雜、難以預測且分散，可觀測性就顯得越重要。以下是一些常見的應用情境：

• 雲端原生應用程式與微服務： 隨著系統越來越分散、各種服務在雲端甚至多個雲端上執行，要在混合雲、雲端或多雲環境中以人工方式監控所有項目會變得愈發困難。透過可觀測性，無論微服務託管於何處，您都能追蹤各微服務之間的互動情形。
• 關聯日誌、指標與追蹤資料： 可觀測性讓您能夠即時分析並關聯日誌、指標與追蹤資料，藉此更準確地掌握系統健康狀態。

可觀測性相較於監控的主要優勢

比較可觀測性與監控時，以下是可觀測性相較於監控的主要優勢：

• 排解「未知的未知」問題： 透過可觀測性，您能夠識別並排解難以預測的問題，例如複雜、動態系統中發生的故障，其中包括 IT 團隊可能未曾預料會發生的問題。
• 主動預防問題： 可觀測性能協助您在問題升級為重大事故之前及早發現，並具備在問題發生之前主動採取預防措施的能力。
• 加快除錯速度並縮短 MTTR（平均解決時間）： 透過可觀測性工具，您能夠追蹤整個技術堆疊中的問題，並迅速找出根本原因，加快除錯流程。

為什麼可觀測性與監控看起來如此相似？

那麼，究竟是什麼導致可觀測性與監控之間的混淆呢？首先，這兩個詞彙本身就十分相似，且兩者的最終目標也相近。兩者都旨在提供系統健康狀態、效能與行為方面的洞見，目的同樣是提升系統可靠性，並找出問題原因以改善整體效能。

兩者也仰賴相同的資料，並運用相同的資料收集、分析與視覺化技術，以便主動偵測並排解問題。最終，兩者都能協助工程師確保系統可靠性、優化效能並有效運用資源。無論您想建立的是可觀測系統還是受監控系統，都必須先擷取正確的輸出資料，這需要安裝收集器與代理程式，並可能需要對應用程式程式碼進行檢測。

這兩項工作也可以並存。如前所述，監控是可觀測性的一個子集。事實上，許多可觀測性平台的介面中都內建了監控工具，這代表您無需使用兩套不同的工具來分別處理監控與可觀測性——所有功能都已整合在一起。

可觀測性與監控，您該選擇哪一個？

在深入說明監控與可觀測性之後，我們來到了關鍵問題：在可觀測性與監控之間，究竟哪一個更勝一籌？您又該如何判斷哪種模式最適合您的環境？以下這張簡單的表格，將直接比較監控與可觀測性。

• 如果您的系統規模小且可預測 → 監控就已足夠。 簡單的應用程式或複雜度極低的小型基礎架構，可以依賴監控來偵測隨時出現的效能問題。
• 如果您執行的是分散式、雲端應用程式 → 就需要可觀測性。 對於跨多個雲端執行的微服務或系統而言，可觀測性能提供理解互動情形與診斷問題所需的深度。
• 如果您經常遇到系統中斷且除錯速度緩慢 → 請採用可觀測性。 如果您的系統難以預測，或面臨大量事故，可觀測性能透過提供更完善的診斷，大幅縮短停機時間。

如何從監控轉型為可觀測性

如果您目前依賴傳統監控，但希望轉型採用可觀測性，以下是逐步操作指南：

步驟 1：找出目前監控策略中的缺口

評估您目前的監控做法在哪些方面存在不足。是否有些問題您無法追溯到根本原因？您的團隊是否難以快速除錯？

步驟 2：導入分散式追蹤與日誌關聯

首先，在系統中加入分散式追蹤（適用於微服務）與日誌關聯功能，這能讓您追蹤請求的路徑，並更有效地找出瓶頸或故障點。

步驟 3：選擇能與您的技術堆疊整合的可觀測性工具

尋找能與您目前基礎架構良好整合的可觀測性工具，常見的選擇包括 Prometheus、OpenTelemetry 與 AWS CloudWatch。請確保該工具支援並能與您所使用的雲端服務、Kubernetes 及其他技術整合。

步驟 4：訓練團隊掌握主動式可觀測性技巧

採用可觀測性需要轉變思維方式。請訓練您的團隊，不僅將這些工具用於被動應對問題，更要主動分析資料並優化系統效能，以防患於未然。

結語

監控 有助於偵測問題，而 可觀測性 則更進一步。它能協助您理解問題發生的原因，並在問題演變成更大的麻煩之前加以解決。如果您所處的是傳統、小規模的環境，監控或許就已足夠。然而，隨著系統規模擴大、複雜度提高，可觀測性便成為維持高可用性與效能不可或缺的要素。

如果您已準備好邁出提升系統健康狀態的下一步，不妨先從檢視目前的監控設定開始。立即著手探索可觀測性工具，深入洞察您的系統，確保運作更順暢、更可靠。TrueWatch 能與全球六大雲端無縫整合，並提供豐富多樣、開箱即用且易於使用的功能與工具。無論您目前使用的是什麼系統，TrueWatch 都能輕鬆融入您的 IT 技術堆疊。系統管理的未來趨勢在於主動出擊，您絕不希望因此落後於人。