概述

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

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

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

監測的黃金信號

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

Latency 延遲

延遲是衡量完成操作所需時間的指標。測量方法的具體細節取決于組件，但一些常見的參考物是處理時間，響應時間或傳輸時間。

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

Traffic 流量

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

持續的高流量數字可能表示該服務可能需要更多資源，或者出現問題阻止了流量正確路由。但是，對于大多數情況，流量速率對于幫助理解問題最為有用。例如，如果延遲增加超出可接受的水平，則能夠將該時間幀與流量峰值相關聯是有幫助的。可以使用流量來了解可以處理的最大流量以及服務在各個負載階段如何降級或失敗。

Error 錯誤

跟蹤錯誤以了解組件的運行狀況以及它們未能適當地響應請求的頻率非常重要。某些應用程序或服務會在現成接口中暴露錯誤，但有些可能需要額外的工作來從其他程序收集數據。

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

Saturation 飽和

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

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

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

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

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

• 單體服務器
• 應用和服務
• 集群服務器
• 依賴外部環境
• 端到端的體驗

上面的排序是按層級不斷擴展范圍和級別。

收集單個服務器組件的度量標準

要收集的基本級別度量標準是與系統所依賴的基礎計算機相關的度量標準。雖然現代軟件開發中的大量工作用于抽象物理組件和低級操作系統細節，但每個服務都依賴于底層硬件和操作系統來完成其工作。因此，密切關注機器的基礎資源是了解系統健康狀況的第一步。

在考慮在機器級別收集哪些指標時，請考慮可用的各個資源。這些將包括服務器硬件的設備以及操作系統提供的核心抽象，如進程和文件描述符。根據四個黃金信號來看，某些信號可能是顯而易見的，而其他信號可能更難以推理。

布倫丹·格雷格，一個有影響力的性能工程師，列出了很多方法來獲得從Linux系統核心指標以滿足一個框架，他提出了USE性能分析方法（utilization, saturation, and errors）。由于USE方法與四個黃金信號之間存在顯著重疊，因此我們可以將他的一些建議用作確定從服務器組件收集哪些數據的起點。

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

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

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

• 延遲 :(沒有 - 很難找到一個好的測量方法而且不可操作）
• 流量：正在使用的內存量
• 錯誤：內存不足錯誤
• 飽和度：OOM殺手事件，交換使用

對于存儲設備：

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

該網絡信號可以是這樣的：

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

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

收集應用程序和服務的度量標準

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

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

重要的是要記住，本節中的指標代表了我們上次能夠使用的通用方法的隔離。從這一點開始，最重要的指標將非常依賴于應用程序的特征，配置以及計算機上運行的工作負載。我們可以討論識別最重要指標的方法，但結果將取決于服務器的具體要求。

對于為客戶提供服務的應用程序，四個黃金信號通常可以很容易地選擇：

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

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

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

衡量服務器集群及其通信的度量標準

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

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

此級別的黃金信號與上一節中測量服務運行狀況的信號非常相似。但是，他們會考慮到小組成員之間需要的額外協調：

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

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

與外部依賴關系和部署環境相關的度量標準

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

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

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

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

這些指標可以幫助您識別依賴項的問題，提醒您即將耗盡資源，并幫助控制開支。如果服務具有插入替代方案，則可以使用此數據來確定在度量指示發生問題時是否將工作移動到其他提供程序。對于靈活性較低的情況，指標至少可用于提醒操作員響應情況并實施任何可用的手動緩解選項。

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

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

雖然之前描述的指標非常有用，但本節中的指標通常是設置警報的最重要指標。為避免響應疲勞，警報（尤其是頁面）應保留用于對用戶體驗具有可識別負面影響的方案。通過使用在其他級別收集的指標向下鉆取，可以調查這些表現在外面的問題。

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

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

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

結論

在本文中，我們首先討論了四個黃金信號，這些信號對于發現和理解系統中的有影響的變化很有幫助。之后，我們使用這四個信號作為基礎來評估在部署的不同層級中需要跟蹤的重要因素。

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