什麼是黃金信号名額？您如何監控 Kubernetes 應用程式中的黃金信号？Golden Signals 可以幫助您檢測微服務應用程式中的問題。這些信号是一組簡化的名額，從使用者或消費者的角度提供服務的廣泛視圖，是以您可以檢測可能直接影響應用程式行為的潛在問題。
監控所有
在之前Prometheus簡介部分介紹監控的基本目标，首先是及時發現問題其次是要能夠快速對問題進行定位。對于傳統監控解決方案而言，使用者看到的依然是一個黑盒，使用者無法真正了解系統的真正的運作狀态。是以Prometheus鼓勵使用者監控所有的東西。下面列舉一些常用的監控次元。
監控模式
除了上述介紹的不同監控級别以外。實際上根據不同的系統類型和目标，這裡還有一些通用的套路和模式可以使用。
4個黃金名額
Four Golden Signals是Google針對大量分布式監控的經驗總結，4個黃金名額可以在服務級别幫助衡量終端使用者體驗、服務中斷、業務影響等層面的問題。主要關注與以下四種類型的名額：延遲，通訊量，錯誤以及飽和度：
- 延遲：服務請求所需時間。
記錄使用者所有請求所需的時間，重點是要區分成功請求的延遲時間和失敗請求的延遲時間。
- 通訊量：監控目前系統的流量，用于衡量服務的容量需求。
流量對于不同類型的系統而言可能代表不同的含義。例如，在HTTP REST API中, 流量通常是每秒HTTP請求數。
- 錯誤：監控目前系統所有發生的錯誤請求，衡量目前系統錯誤發生的速率。
對于失敗而言有些是顯式的(比如, HTTP 500錯誤)，而有些是隐式(比如，HTTP響應200，但實際業務流程依然是失敗的)。
對于一些顯式的錯誤如HTTP 500可以通過在負載均衡器(如Nginx)上進行捕獲，而對于一些系統内部的異常，則可能需要直接從服務中添加鈎子統計并進行擷取。
- 飽和度：衡量目前服務的飽和度。
主要強調最能影響服務狀态的受限制的資源。 例如，如果系統主要受記憶體影響，那就主要關注系統的記憶體狀态，如果系統主要受限與磁盤I/O，那就主要觀測磁盤I/O的狀态。因為通常情況下，當這些資源達到飽和後，服務的性能會明顯下降。同時還可以利用飽和度對系統做出預測，比如，“磁盤是否可能在4個小時候就滿了”。
RED方法
RED方法是Weave Cloud在基于Google的“4個黃金名額”的原則下結合Prometheus以及Kubernetes容器實踐，細化和總結的方法論，特别适合于雲原生應用以及微服務架構應用的監控和度量。主要關注以下三種關鍵名額：
- (請求)速率：服務每秒接收的請求數。
- (請求)錯誤：每秒失敗的請求數。
- (請求)耗時：每個請求的耗時。
在“4大黃金信号”的原則下，RED方法可以有效的幫助使用者衡量雲原生以及微服務應用下的使用者體驗問題。
USE方法
USE方法全稱"Utilization Saturation and Errors Method"，主要用于分析系統性能問題，可以指導使用者快速識别資源瓶頸以及錯誤的方法。正如USE方法的名字所表示的含義，USE方法主要關注與資源的：使用率(Utilization)、飽和度(Saturation)以及錯誤(Errors)。
- 使用率：關注系統資源的使用情況。 這裡的資源主要包括但不限于：CPU，記憶體，網絡，磁盤等等。100%的使用率通常是系統性能瓶頸的标志。
- 飽和度：例如CPU的平均運作排隊長度，這裡主要是針對資源的飽和度(注意，不同于4大黃金信号)。任何資源在某種程度上的飽和都可能導緻系統性能的下降。
- 錯誤：錯誤計數。例如：“網卡在資料包傳輸過程中檢測到的以太網網絡沖突了14次”。
通過對資源以上名額持續觀察，通過以下流程可以知道使用者識别資源瓶頸：
黃金信号，Kubernetes 應用程式監控标準
恭喜，您已成功在 Kubernetes 中部署您的應用程式。這時您會發現舊的監控工具幾乎毫無用處，并且您無法檢測到潛在問題。經典監控工具通常基于靜态配置檔案，旨在監控機器，而不是微服務或容器。在容器世界中，事情變化很快。容器以令人難以置信的速度建立和銷毀，如果沒有特定的服務發現功能，就不可能趕上。根據最新的Sysdig 容器使用報告，22% 的容器存活時間不到 10 秒，54% 的容器存活時間不到 5 分鐘。
大多數現代監控系統為許多不同的目的提供了種類繁多的名額。很容易淹沒在名額中，而忽視與您的應用程式真正相關的内容。設定太多不相關的警報會使您進入永久性緊急狀态和“警報耗盡”。想象一下，一個被大量使用并一直在引發負載警報的節點。隻要節點中的服務工作，你就不會做任何事情。警報過多與沒有警報一樣糟糕，因為重要的警報被淹沒在無關緊要的海洋中。
這是很多人都面臨的問題，幸運的是，已經有人解決了。答案是四個黃金信号，這是Google SRE 手冊中首次使用的術語。黃金信号是四個名額，它們可以讓您很好地了解與該服務互動的參與者所看到的應用程式的真實健康狀況和性能，無論他們是最終使用者還是微服務應用程式中的其他服務。
Golden signals metric: Latency explained
延遲是您的系統為針對服務的請求提供服務所需的時間。這是檢測性能下降問題的重要标志。
使用延遲時，僅使用平均值是不夠的，因為它們可能會産生誤導。例如，我們有一個服務顯示平均 100 毫秒的響應時間。僅憑這些資訊我們就可以認為它非常好，但使用者的回報是它被認為是緩慢的。
可以使用不同的統計參數（如标準偏差）來找到這個沖突的答案，這将使我們了解延遲值的分散情況。如果我們有兩種請求，其中一種非常快，另一種較慢，因為它對資料庫更加密集。如果一個典型的使用者互動有一個慢請求和 10 個快速請求，平均值可能會很低，但應用程式會很慢。瓶頸分析也很重要，不僅僅是平均值。
避免這種行為的一個很好的工具是直方圖名額。這些表示不同延遲門檻值下的請求數量，并允許它們以百分位數聚合。百分位數是低于給定百分比的路徑成本的值。例如，p99 表示我 99% 的請求的延遲值低于百分位數。
正如您在螢幕截圖中看到的，平均延遲是可以接受的，但是如果我們檢視百分位數，我們會發現值存在很大差異，進而更好地了解真實的延遲感覺是什麼。不同的百分位數表達不同的資訊；p50 通常表示一般性能下降，而 p95（或 p99）允許檢測特定請求或系統元件中的性能問題。
可能認為 1% 的請求的高延遲不是什麼大問題，但現在想想需要多個請求才能完全加載和顯示的 Web 應用程式。在這種常見的場景中，1% 的請求中的高延遲會影響最終使用者的高得多的速率，因為這些多個請求之一會降低整個應用程式的性能。
另一個用于分析延遲值的有用工具是APDEX 分數，根據您的 SLA 條款，它可以提供基于百分位數的系統狀況良好程度的一般概念。
Golden signals metric: Errors explained
您的服務傳回的錯誤率是更深層次問題的一個很好的名額。不僅要檢測顯式錯誤，還要檢測隐式錯誤，這一點非常重要。
顯式錯誤可以是任何類型的 HTTP 錯誤代碼。這些很容易識别，因為錯誤代碼很容易從回複标頭中獲得，并且它們在許多系統中都非常一緻。這些錯誤的一些示例可能是授權錯誤 (503)、未找到内容 (404) 或伺服器錯誤 (500)。在某些情況下，錯誤描述可能非常具體（418 – 我是茶壺）。
- 不生成 HTTP 回複的錯誤，因為請求時間超過逾時時間。
- 明顯成功的請求中的内容錯誤。