概述

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

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

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

監測的黃金訊號

在極具影響力的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（服務級別協議）的延遲，指示嚴重峰值或下降的流量，錯誤率增加以及由於資源限制而無法提供請求在這個級別都非常易於推斷。假設指標是準確的，則可以根據您的可用性，效能和可靠性目標直接對映此處的值。

結論

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

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