監控體系的核心指標

簡介

了解系統狀態對于確保應用程序和服務的可靠性和穩定性至關重要。有關部署運行狀況和性能的信息不僅可以幫助您的團隊對問題做出反應，還可以讓他們放心地進行更改。獲得這種洞察力的最佳方法之一是使用強大的監控系統，該系統可以收集指標、可視化數據并在出現問題時提醒操作員。

在我們對指標、監控和警報指南的介紹中，我們討論了一些涉及監控軟件和基礎設施的核心概念。指標是監控系統處理的主要材料，用于構建被跟蹤系統的內聚視圖。了解哪些組件值得監控以及您應該查看哪些具體特征是設計一個系統的第一步，該系統可以提供有關您的軟件和硬件狀態的可靠、可操作的見解。

在本指南中，我們將首先討論用于確定要跟蹤的最關鍵指標的流行框架。之后，我們將介紹如何在整個部署過程中將這些指標應用于組件。此過程將首先關注單個服務器的基礎資源，然后調整范圍以涵蓋越來越大的關注領域。

監控的黃金信號

在極具影響力的 Google SRE（站點可靠性工程）書中，關于監控分布式系統的章節介紹了一個有用的框架，稱為監控的四個黃金信號，它代表了在面向用戶的系統中要衡量的最重要的因素。我們將在下面討論這四個特征中的每一個。

延遲

延遲是對完成操作所需時間的度量。具體如何測量取決于組件，但一些常見的類似物是處理時間、響應時間或行程時間。

測量延遲可讓您具體衡量完成特定任務或操作所需的時間。捕獲各種組件的延遲允許您構建系統不同性能特征的整體模型。這可以幫助您找到瓶頸，了解訪問哪些資源需要最多的時間，并注意到操作突然花費的時間比預期的時間長。SRE 一書的作者強調在計算延遲時區分成功和不成功請求的重要性，因為它們可能具有非常不同的配置文件，可能會扭曲服務的平均值。

流量

流量衡量您的組件和系統的“繁忙程度”。這會捕獲您的服務的負載或需求，以便您了解您的系統當前正在執行多少工作。

持續的高或低流量數字可能表明服務可能需要更多資源，或者問題阻止流量正確路由。但是，在大多數情況下，流量率對于幫助了解通過其他信號浮出水面的問題最有用。例如，如果延遲增加超過可接受的水平，能夠將該時間范圍與流量峰值相關聯是有幫助的。流量可用于了解可以處理的最大流量以及服務在不同負載階段如何降級或失敗。

錯誤

跟蹤錯誤以了解組件的健康狀況以及它們未能正確響應請求的頻率非常重要。某些應用程序或服務會在干凈、現成的界面中暴露錯誤，但可能需要額外的工作來從其他程序收集數據。

區分不同類型的錯誤可以更輕松地查明影響應用程序的問題的確切性質。這也為您提供了警報的靈活性。如果出現一種類型的錯誤，您可能需要立即收到警報，但對于另一種錯誤，只要比率低于可接受的閾值，您就不會擔心。

飽和

飽和度衡量給定資源的使用量。百分比或分數經常與具有明確總容量的資源一起使用，但對于沒有明確定義的最大值的資源，可能需要更具創造性的測量。

飽和度數據提供有關服務或應用程序有效運行所依賴的資源的信息。由于一個組件提供的服務可能會被另一個組件使用，因此飽和度是暴露底層系統容量問題的粘合指標之一。因此，一層中的飽和和延遲問題可能與底層中流量或錯誤測量的顯著增加相對應。

測量整個環境中的重要數據

使用四個黃金信號作為指導，您可以開始查看這些指標在整個系統層次結構中的表達方式。由于服務通常是通過在更基本的組件之上添加抽象層來構建的，因此應設計指標以在部署的每個級別添加洞察力。

我們將研究常見分布式應用程序環境中存在的不同級別的復雜性：

• 單獨的服務器組件
• 應用程序和服務
• 服務器集合
• 環境依賴
• 端到端體驗

上面的順序擴展了每個后續層的抽象范圍和級別。

為單個服務器組件收集的指標

需要收集的基本級別指標是與您的系統所依賴的底層計算機相關的指標。盡管現代軟件開發在抽象物理組件和低級操作系統細節方面付出了相當大的努力，但每項服務都依賴于底層硬件和操作系統來完成其工作。因此，密切關注機器的基礎資源是了解系統健康狀況的第一步。

在考慮在機器級別收集哪些指標時，請考慮可用的單個資源。這些將包括服務器硬件的表示以及操作系統提供的核心抽象，如進程和文件描述符。從四個黃金信號的角度來看每個組成部分，某些信號可能很明顯，而其他信號可能更難以推理。

Brendan Gregg 是一位有影響力的性能工程師，他概述了許多從 Linux 系統獲取核心指標的方法，以滿足他稱為性能分析（利用率、飽和度和錯誤）的 USE 方法的框架的需求。由于 USE 方法和四個黃金信號之間存在顯著重疊，我們可以使用他的一些建議作為起點，以確定從服務器組件收集哪些數據。

要測量 CPU，以下測量可能是合適的：

• 延遲：CPU 調度程序的平均或最大延遲
• 流量：CPU 利用率
• 錯誤：特定于處理器的錯誤事件、故障 CPU
• 飽和度：運行隊列長度

對于內存，信號可能如下所示：

• 延遲：（無 - 很難找到一種好的衡量方法且不可操作）
• 流量：正在使用的內存量
• 錯誤：內存不足錯誤
• 飽和度：OOM 殺手事件，交換使用

對于存儲設備：

• 延遲：讀取和寫入的平均等待時間（await）
• 流量：讀寫 I/O 級別
• 錯誤：文件系統錯誤、/sys/devices 中的磁盤錯誤
• 飽和度：I/O 隊列深度

網絡信號可能如下所示：

• 延遲：網絡驅動程序隊列
• 流量：每秒傳入和傳出的字節或數據包
• 錯誤：網絡設備錯誤、丟包
• 飽和度：溢出、丟包、重傳段

除了物理資源的表示外，收集與強制執行限制的操作系統抽象相關的指標也是一個好主意。屬于此類別的一些示例是文件句柄和線程計數。這些不是物理資源，而是由操作系統設置的上限構造，以防止進程過度擴展自身。大多數都可以使用 ulimit 之類的命令進行調整和配置，但跟蹤這些資源使用的變化可以幫助您檢測軟件使用中潛在的有害變化。

為應用程序和服務收集的指標

向上移動一層，我們開始處理在服務器上運行的應用程序和服務。這些程序使用我們之前處理的單個服務器組件作為資源來完成工作。此級別的指標可幫助我們了解單主機應用程序和服務的運行狀況。我們已將分布式多主機服務分成一個單獨的部分，以闡明這些配置中最重要的因素。

雖然上一節中的指標詳細說明了各個組件和操作系統的功能和性能，但此處的指標將告訴我們應用程序能夠執行我們要求它們的工作的能力。我們還想知道我們的應用程序依賴哪些資源以及它們如何管理這些約束。

重要的是要記住，本節中的指標與我們上次能夠使用的通用方法有所不同。從現在開始，最重要的指標將非常依賴于您的應用程序的特征、配置以及您在機器上運行的工作負載。我們可以討論確定最重要指標的方法，但您的結果將取決于具體要求服務器執行的操作。

對于為客戶服務的應用程序，四個黃金信號通常很容易挑選：

• 延遲：完成請求的時間
• 流量：每秒服務的請求數
• 錯誤：處理客戶端請求或訪問資源時發生的應用程序錯誤
• 飽和度：當前正在使用的資源的百分比或數量

您需要跟蹤的一些更重要的指標是與依賴項相關的指標。這些通常最好通過與單個組件相關的飽和度指標來表達。例如，應用程序內存利用率、可用連接、打開的文件句柄數量或活動的工作人員數量可以幫助您了解在物理服務器上下文中應用的配置的效果。

這四個黃金信號主要是為分布式微服務設計的，因此它們采用客戶端-服務器架構。對于不使用客戶端-服務器架構的應用程序，相同的信號仍然很重要，但“流量”信號可能需要稍微重新考慮。這基本上是對繁忙度的衡量，因此找到一個能夠充分代表您的應用程序的指標將達到相同的目的。具體將取決于您的程序正在做什么，但一些通用的替代品可能是每秒處理的操作數或數據。

衡量服務器集合及其通信的指標

大多數服務，尤其是在生產環境中運行時，將跨越多個服務器實例以提高性能和可用性。這種增加的復雜程度增加了對監測很重要的額外表面積。分布式計算和冗余系統可以使您的系統更加靈活，但基于網絡的協調比單個主機內的通信更脆弱。強大的監控可以幫助減輕處理不太可靠的通信渠道的一些困難。

除了網絡本身，對于分布式服務，服務器組的健康和性能比應用于任何單個主機的相同措施更重要。雖然服務在局限于單個主機時與其運行的計算機密切相關，但冗余多主機服務依賴于多臺主機的資源，同時與對任何一臺計算機的直接依賴保持分離。

此級別的黃金信號與上一節中衡量服務健康狀況的信號非常相似。但是，他們將考慮到組成員之間所需的額外協調：

• 延遲：池響應請求的時間，與對等方協調或同步的時間
• 流量：池每秒處理的請求數
• 錯誤：處理客戶端請求、訪問資源或到達對等點時發生的應用程序錯誤
• 飽和度：當前使用的資源量、當前滿負荷運行的服務器數量、可用的服務器數量。

雖然這些與單主機服務的重要指標有明確的相似之處，但每個信號在分布時都會變得更加復雜。延遲成為一個更復雜的問題，因為處理可能需要多個主機之間的通信。流量不再是單個服務器能力的函數，而是組能力和用于分配工作的路由算法效率的總結。引入了與網絡連接或主機故障相關的其他錯誤模式。最后，飽和度擴展到包括主機可用的組合資源、連接每個主機的網絡鏈接以及正確協調對每臺計算機所需依賴項的訪問的能力。

與外部依賴和部署環境相關的指標

要收集的一些最有價值的指標存在于您的應用程序或服務的邊界，不受您的直接控制。外部依賴項，包括與您的托管服務提供商和您的應用程序構建依賴的任何服務相關的依賴項。這些代表您無法直接管理的資源，但會損害您保證自己服務的能力。

由于外部依賴關系代表關鍵資源，因此在完全中斷的情況下唯一可用的緩解策略之一是將操作切換到不同的提供者。這只是商品服務的可行策略，即便如此，也只有事先規劃并與提供商松散耦合。即使緩解困難，了解影響應用程序的外部事件也非常有價值。

應用于外部依賴的黃金信號可能類似于：

• 延遲：從服務接收響應或從提供者提供新資源所需的時間
• 流量：推送到外部服務的工作量，向外部 API 發出的請求數
• 錯誤：服務請求的錯誤率
• 飽和度：使用的帳戶限制資源量（實例、API 請求、可接受的成本等）

這些指標可以幫助您識別依賴關系的問題，提醒您即將發生的資源耗盡，并幫助控制費用。如果服務有替代方案，當指標表明出現問題時，該數據可用于決定是否將工作轉移到不同的提供者。對于靈活性較差的情況，這些指標至少可以用來提醒操作員對這種情況做出響應并實施任何可用的手動緩解選項。

跟蹤整體功能和端到端體驗的指標

最高級別的指標在用戶與之交互的最外層組件的上下文中跟蹤通過系統的請求。這可能是一個負載均衡器或其他路由機制，負責接收和協調對您的服務的請求。由于這是與您的系統的第一個接觸點，因此在此級別收集指標可提供整體用戶體驗的近似值。

雖然前面描述的指標非常有用，但本節中的指標通常是設置警報時最重要的指標。為避免響應疲勞，警報（尤其是頁面）應保留用于對用戶體驗有明顯負面影響的場景。可以通過使用在其他級別收集的指標進行深入研究來調查這些指標中出現的問題。

我們在這里尋找的信號類似于我們之前描述的單個服務的信號。主要區別在于我們在這里收集的數據的范圍和重要性：

• 延遲：完成用戶請求的時間
• 流量：每秒用戶請求數
• 錯誤：處理客戶端請求或訪問資源時發生的錯誤
• 飽和度：當前正在使用的資源的百分比或數量

由于這些指標與用戶請求并行，因此超出這些指標可接受范圍的值可能表明對用戶有直接影響。不符合面向客戶或內部 SLA（服務級別協議）的延遲、指示嚴重高峰或下降的流量、錯誤率增加以及由于資源限制而無法處理請求都是相當簡單的推理在這個級別。假設指標準確，此處的值可以直接映射到您的可用性、性能和可靠性目標。

總結

在本指南中，我們首先討論了最有助于發現和理解系統中具有影響力的變化的四個黃金信號。之后，我們使用信號作為鏡頭來評估在部署的不同層進行跟蹤的最重要因素。

從上到下評估您的系統有助于確定運行可靠和高性能服務所需的關鍵組件和交互。這四個黃金信號可以成為構建指標以最好地指示系統健康狀況的一個很好的起點。但是，請記住，雖然黃金信號是一個很好的框架，但您必須了解特定于您的情況的其他指標。收集您認為最有可能警告問題或幫助您在出現問題時進行故障排除的任何數據。

免責聲明：本公眾號所發布的文章為本公眾號原創，或者是在網絡搜索到的優秀文章進行的編輯整理，文章版權歸原作者所有，僅供讀者朋友們學習、參考。對于分享的非原創文章，有些因為無法找到真正來源，如果標錯來源或者對于文章中所使用的圖片、連接等所包含但不限于軟件、資料等，如有侵權，請直接聯系后臺，說明具體的文章，后臺會盡快刪除。給您帶來的不便，深表歉意。