監控SRE的黃金訊號

weixin_33807284發表於2018-06-05
\

關鍵要點

\\
  • 金牌訊號對於運營團隊監控其系統和發現問題至關重要。\\t
  • 隨著我們轉向微服務和容器，這些訊號變得尤為重要，其中包括第三方在內的更多功能更加分散。\\t
  • 需要監測的指標有許多，但行業經驗表明，包括速率，錯誤，延遲，飽和度和利用率這5個指標幾乎包含了所有需要了解到底怎麼回事的相關資訊。\\t
  • 獲取這些訊號非常具有挑戰性，通過有效的服務和工具可以帶來很多改變。\\t
  • 這些訊號作為異常檢測（尋找不尋常的模式）的一部分最為有效，因為這些指標會隨時間和日期的變化而產生很大的變化。\
\\

金色訊號現在越來越受歡迎，部分原因是網站可靠性工程（SRE）的興起，以及Google相關的書籍以及各行各業的人就提高網站、效能和監控能力的部落格。

\\

監測黃金訊號很重要，但關於如何實際監測和使用它們的文章並不多。本文概述了什麼是金色訊號，以及如何在各種常見服務中獲取和使用它們。

\\

什麼是金色訊號？

\\

目前沒有明確的協議，但有以下當今金色訊號的三大主要列表：

\\

你可以看到有些是重疊的。USE是關於具有內部檢視的資源，而RED則是關於請求和實際工作的外部檢視。

\\

在本文中，我們將關注由五個訊號組成的超集：

\\
  • 請求率 - 請求率，請求/秒。\\t
  • 錯誤率 - 錯誤率，誤差/秒。\\t
  • 延遲 - 響應時間，包括佇列/等待時間，以毫秒為單位。\\t
  • 飽和度 - 某些東西的超負荷程度如何，直接通過諸如佇列深度（或有時併發）之類的東西來衡量。當系統飽和時變為非零。\\t
  • 利用率 - 資源或系統的繁忙程度。通常表示0-100％，對預測最有用（飽和度通常對警報更有用）。\

飽和度和利用率通常是最難獲得的，但它們往往是搜尋當前和未來問題最有價值的。

\\

我們應該如何處理我們的訊號？

\\

這些是“黃金”訊號的關鍵原因之一是，他們試圖測量直接系統中影響終端使用者和工作生產部分的東西 - 它們是對重要事情的直接測量。

\\

這意味著它們比較直接的測量（如CPU，RAM，網路，複製延遲和其他等等若干事情）更有用。

\\

我們以幾種方式使用金色訊號：

\\
  • 警報 - 告訴我們什麼時候出現問題。\\t
  • 疑難解答 - 幫助我們找到並解決問題。\\t
  • 調整和容量規劃 - 幫助我們讓事情變得更好。\

首先要關注的一個方面是如何在這些訊號上進行警報。

\\

大體上，您可以也應該對這些訊號使用當前的警報方法，因為它們比通常受監視的CPU，RAM和其他較低階別的指示器更有用。獲得資料後，觀察一段時間，然後開始在正常工作流程中新增基本警報，以檢視這些訊號如何影響您的系統。

\\

但是，金色訊號也很難警報，因為它們不適合傳統的靜態警報閾值，比如高CPU使用率、低可用記憶體或低磁碟空間。靜態閾值很有用，但很難設定好且容易產生很多警報噪音，任何操作人員（以及任何與他們待在一起的人）都會這麼跟你說。

\\

但無論如何，還是要從靜態警報開始著手，但是要將閾值設定為可以肯定某些異常或錯誤的閾值，例如，延遲時間超過10秒，長佇列，錯誤率高於每秒幾個。

\\

如果您使用靜態警報，請不要忘記下限警報，例如每秒接近零請求或延遲，因為這通常意味著出現問題，即使在凌晨3點，流量較輕時也是如此。

\\

你是平均數還是百分數？

\\

基本警報通常使用平均值與某個閾值進行比較，但是使用中值不會像使用大/小異常值的那麼敏感，如果您的監控系統能夠這樣做的話。這將減少錯誤警報。

\\

百分比更好。例如，您可以在95%的延遲上警報，這是一個非常好的衡量不良使用者體驗的方法。如果95%是好的，那麼大多數人都是好的。你會經常震驚怎麼你的百分比那麼糟糕。

\\

這是一個異常，還是隻是個偶然事件？

\\

理想情況下，您現在就可以開始對您的金色訊號使用異常檢測。這對於捕捉非高峰問題或非常低的度量值尤其有用，例如當您的Web上的請求速率凌晨3點比正常情況高5倍或在中午由於網路問題降至零時。此外，異常檢測允許更緊密的警戒帶，所以您可以比靜態閾值（它必須相當寬以避免錯誤警報）更快地發現問題。

\\

但是，異常檢測可能具有挑戰性，因為甚至很少有本地監控解決方案可以實現這一點。這也相當新和難以調整（特別是在金色訊號中常見的“季節性”和趨勢）。支援異常檢測的工具包括一些SaaS /雲監控解決方案，如DataDog或SignalFX，以及Prometheus或InfluxDB等本地工具。

\\

無論您的工具是什麼，如果您想更好地瞭解異常檢測帶來的各種選項、演算法和挑戰，您應該閱讀Baron Schwartz的“ 監測異常檢測”一書。

\\

我可以看到你？

\\

除了警報之外，您還應該視覺化這些訊號。嘗試將一個給定服務的所有訊號集中在一個頁面上，以便您可以及時在視覺上對其建立關聯關係，以檢視錯誤率與延遲或請求速率以及其他訊號有怎樣的關聯性。以下是Datadog的一個例子：

\\

b41ef09aa6e080fc1de6e3b0bb312595.png

\\

您還可以使用標記/事件豐富您的指標，例如部署，自動縮放事件，重新啟動等。理想情況下，將所有這些度量標準顯示在系統圖上，以檢視服務是如何關聯的，以及在哪裡較低階別的延遲或錯誤可能會影響較高階別。

\\

修復我，修復你

\\

關於警報的最後要注意的是，我發現SRE金色訊號警報更具挑戰性，因為它們是很少直接暴露在警報中的潛在問題的症狀。例如，低階別服務中的單個高延遲問題很容易導致整個系統出現很多延遲和錯誤警報。

\\

這通常意味著工程師必須擁有更多的系統知識，並且能夠更深入地挖掘問題，而這些問題很容易出現在任何一個服務或資源中。

\\

即使對於基本的高CPU或低RAM問題，工程師總是必須連線所有點對警報進行深入挖掘。但是金色的訊號通常更加抽象，並且很容易擁有它們。

\\

幸運的是，金色訊號通過為每個服務和堆疊的每一層提供明確的度量標準提供幫助。這有助於確定哪些服務最有可能導致問題（尤其是如果您擁有準確的依賴資訊），從而集中精力處理它。

\\

現在，我們來看看如何從常用服務中獲取黃金訊號資料。

\\

從多個服務獲取資料

\\

以可用的方式在感興趣的領域獲取這些資料存在一些細微差別和挑戰，下面的元素已經被簡化了一些。還要注意，在某些情況下，當您使用基於計數器的指標（如網路位元組數，日誌行數，總請求數和其他資料）時，您必須自行處理，如差值計算（每秒更改一次）（大多數監測系統將自動執行此操作）。

\\

負載均衡器的黃金訊號

\\

負載平衡器是大多數現代系統的關鍵元件，通常在應用程式之前，但也越來越多地在系統內部，支援容器，套接字服務，資料庫等等。

\\

目前有幾種流行的負載均衡器，因此我們將涵蓋三種最常見的負載均衡器：HAProxy，AWS ELB和AWS ALB。

\\

負載均衡器前端和後端

\\

負載均衡器具有前端和後端，通常每個都有幾個。根據您的體系結構，您可以使用所有這些的總和，或者可以為各種服務分解訊號以獲取更多詳細資訊。

\\

另外，正如您將在下面看到的，負載均衡器通常擁有比Web /應用伺服器本身更好的各種Web /應用伺服器的後端資料。所以你可以根據哪個更容易監控來選擇。

\\

HAProxy

\\

HAProxy 資料採用CSV格式，可以通過三種方式訪問​​：CSV，CLI和unix套接字。

\\

HAProxy金色訊號（大寫字母引用官方HAProxy變數名稱）可以按如下方式檢索：

\\
  • 請求率 - 使用REQ_TOT並進行增量處理以獲得比率。伺服器的利用率（儘管這只是在最後一秒）。\\t
  • 錯誤率 - 使用響應錯誤ERESP，這意味著後端錯誤。這是一個計數器，所以你必須對它進行增量處理。您也可以通過後端伺服器獲取此資訊。您還可以獲得對任何系統都至關重要的HTTP 5xx錯誤計數。\\t
  • 延遲 - 使用響應時間RTIME（每個後端），它計算最近1024次請求的平均值。每臺伺服器也可用。\\t
  • 飽和度 - 排隊請求的使用數量，QCUR。應該是零，如果更高則警報。\\t
  • 利用 - 這對HAProxy沒有用處，因為它很難測量，並且在大多數系統中，HAProxy的容量遠遠超過後端系統。因此，超負載幾乎是不可能的。\

AWS ELB和ALB

\\

AWS Elastic Load Balancing和應用程式負載平衡服務的所有資料點均通過CloudWatch提供。如果您對ELB / ALB訊號做了百分比和統計，請務必仔細閱讀文件中經典負載平衡器指標的統計資訊部分。

\\

ELB指標適用於ELB整體，但不適用於後端組或伺服器。ALB資料非常相似，具有更多可用資料，而度量標準名稱存在一些差異。度量標準由Target Group（通過Dimension Filtering）提供，適用於ALB整體，您可以從中獲取後端伺服器的資料，而不是直接監控Web /應用程式伺服器。來自ALB的每個伺服器的資料是不可用的（儘管您可以按可用區進行過濾，如果每個可用區只有一個目標後端伺服器，則可以按每個伺服器進行過濾）。

\\

ALB / ELB訊號（請注意，sum（）部分是指啟用這些指標時必須選擇的CloudWatch統計函式）：

\\
  • 請求率 - 使用請求數（sum（RequestCount））除以配置的CloudWatch取樣時間（1或5分鐘）。這將包括出錯的請求數。\\t
  • 出錯率 - 您應該新增三個指標：\

ELB：sum（HTTPCode_Backend_5XX），sum（HTTPCode_ELB_5XX）和sum（BackendConnectionErrors）

\\

ALB：sum（HTTPCode_Backend_5XX），sum（HTTPCode_ELB_5XX）和sum（TargetConnectionErrorCount）

\\
  • 延遲 - 使用平均值：\

ELB: average(Latency)

\\

ALB: average(TargetResponseTime)

\\
  • 飽和度 - 使用：\

ELB：max（SurgeQueueLength）和sum（SpilloverCount）

\\

ALB：sum（RejectedConnectionCount）

\\
  • 利用率 - 沒有好的方法來獲取ELB或ALB的利用率資料，因為它們不提供也沒有暴露給我們。\

Web伺服器的金色訊號

\\

從Web伺服器獲取良好訊號至關重要。不幸的是，他們通常不直接提供這些資料，當他們這樣做時，他們仍然缺乏所有伺服器的彙總資料。因此我們剩下三個選擇：

\\
  1. 使用非常有限的內建狀態報告/頁面\\t
  2. 收集並彙總Web伺服器的HTTP日誌\\t
  3. 利用上游負載均衡器每個伺服器的指標（如果可以的話）\

最後的選擇通常是最好的選擇，因為負載平衡器比Web伺服器具有更好的度量標準。請參閱上面的關於負載平衡黃金訊號的部分，以找出其中的原因。

\\

但是，並非所有系統都具有正確的負載均衡型別，並且並非所有監控系統都支援這種型別的後端資料。在這些情況下，我們必須訴諸前兩種選擇。

\\

下面的方法需不太完善，但仍值得一提，那就是使用狀態頁面和HTTP日誌從Web伺服器檢索金色訊號。我們將看看兩個流行的Web伺服器：Apache和Nginx。

\\

啟用狀態監控

\\

要獲取監控資料，首先需要啟用狀態監控：

\\

啟用日誌

\\

您還需要開啟日誌並通過編輯您的Web配置向日志新增響應時間：

\\
  • Apache - 將“％D”欄位新增到日誌定義中（通常位於httpd.conf檔案末尾），該日誌定義了響應時間（以微秒為單位）（如果在Apache V1.x上使用“％T”，但注意這僅記錄秒，而不是毫秒）。\\t
  • Nginx - 新增“$ upstream_response_time”欄位以記錄後端響應時間（通常在nginx.conf檔案中）。\

針對指標的日誌處理

\\

延遲和其他關鍵指標只能從難以讀取，解析和總結的日誌中獲得。本節介紹如何最好地為各種伺服器做到這一點。

\\

雖然HTTP日誌工具有很多，但他們都無法計算出金色訊號 - 我們需要可以讀取和彙總日誌的工具。ELK軟體棧可以做到這一點（比如Splunk、Sumologic、Logz和其他一樣就可以）有詳細的響應時間、狀態計數等彙總查詢，還有當今大多數SaaS的監控工具也可以提取這些資料，如DataDog。

\\

傳統的監視系統如Zabbix無法如此輕鬆地完成這項工作，特別是在我們需要日誌聚合指標時，而不是實際的日誌行。理想情況下，您可以找到一個本機支援Web伺服器日誌指標的監控系統或工具。

\\

對於Web伺服器，我們可以獲得標準狀態和監控統計資訊：

\\
  • 請求率 - 每秒請求數，您可以通過伺服器的狀態資訊獲取：\

Apache - Apache提供總訪問，您需要進行增量處理以獲取每秒請求數（僅為當前度量和最近一次之間的差值除以它們之間的秒數，例如（50800 - 50200）/ 60秒= 10 /秒）。不要使用Apache的“每秒請求數”，因為它涉及整個伺服器程式的生命週期，可能是幾個月或幾年，而不是我們感興趣的最近幾分鐘。

\\

Nginx - 對請求進行增量處理以每秒獲取請求。

\\
  • 錯誤率 - 計算每秒日誌的5xx錯誤。\\t
  • 延遲 - 根據日誌的平均值（或中值）平均請求和響應時間。我建議1-5分鐘但仍然有響應的取樣週期來降低噪音。\\t
  • 飽和度 - 不是很有用，因為在大多數系統中幾乎不可能使nginx飽和，因此它將始終為零，除非每天每臺伺服器執行數十億次請求。\\t
  • 利用率 - 對Nginx無用。對於Apache，您應該監視BusyWorkers與MaxRequestWorkers，MaxClients和ServerLimit中最小的比例（來自httpd.conf檔案 - 它們都相互作用，並且取得最小勝利）。還會記錄來自日誌的HTTP 503錯誤的計數和增量處理（錯誤/秒）。\

應用伺服器的黃金訊號

\\

應用程式伺服器是應用程式的主要完成工作的地方。理想情況下，您可以在應用程式伺服器上的程式碼中嵌入可觀察性指標。這對錯誤率和延遲金訊號特別有用，因為這將為您直接節省相當多的時間。特別是對於Golang、Python和Node.js語言，這是唯一的選擇。

\\

PHP

\\

PHP以Apache mod_php或PHP-FPM執行。對於mod_php，沒有好的外部訊號，就像上面的Web伺服器部分所述的Apache狀態頁面和日誌。

\\

對於PHP-FPM，我們需要能夠以JSON，XML和HTML格式啟用狀態頁面。我們還需要PHP-FPM訪問、錯誤和變慢的日誌。

\\

錯誤日誌在主PHP-FPM配置檔案中設定。訪問日誌很少使用，但將其開啟並將格式設定為包含“ ％d ”，即為請求提供服務所需的時間（這在POOL配置中完成，通常在www.conf中，而不是主php-fpm .conf檔案）。變慢的日誌也在這個檔案中設定。有關更多詳細資訊，請參閱此自助頁面。

\\

最後，你應該正確地配置你的PHP日誌。預設情況下，它們加入到Web伺服器的錯誤日誌，與404和其他HTTP錯誤混在一起，使得它們很難分析或彙總。最好在PHP-FPM池檔案（通常為www.conf）中新增一個error_log過載設定（php_admin_value [error_log]）。

\\

對於PHP-FPM，我們的訊號是：

\\
  • 請求率 - 除了讀取訪問日誌並將其聚合為每秒請求數之外，沒有可以直接實現此目的的辦法。\\t
  • 錯誤率 - 計算每秒錯誤日誌中的PHP錯誤（PHP-FPM錯誤日誌沒有任何度量標準或錯誤資訊）。\\t
  • 延遲 - 從PHP-FPM訪問日誌中獲取響應時間並對計算其平均值。\\t
  • 飽和度 - 監視“監聽佇列”，因為當沒有更多的FPM程式可用時，將會成為non-zero 。這意味著它會飽和。\\t
  • 利用率 - 使用監視系統的過程計數器監視正在使用的FPM過程（“活動過程”），並與FPM配置中配置的最大過程進行比較。\

Java

\\

對於Java，無論是在前端Web伺服器還是負載均衡器中，都可以更好地監控上游的黃金訊號。要直接監視Tomcat，我們需要配置它進行監視，這意味著確保您在應用程式程式碼中具有良好的訪問/錯誤日誌記錄，並啟用了JMX支援。在JVM級別啟用JMX並重新啟動Tomcat。出於安全原因要確保它是隻讀的，將本地計算機的訪問許可權限制為只讀使用者。

\\

Tomcat訊號是：

\\
  • 請求率 - 通過JMX，使用GlobalRequestProcessor的requestCount執行增量處理以獲取每秒請求。\\t
  • 錯誤率 - 通過JMX，使用GlobalRequestProcessor的errorCount對每秒錯誤進行增量處理。除非您按處理器過濾，否則包含非HTTP錯誤。\\t
  • 延遲 - 通過JMX獲取GlobalRequestProcessor的處理時間，但這是自重啟以來的總時間，這個時間除以requestCount會拿到長期的平均響應時間，這並不是很有用。理想情況下，您的監控系統或指令碼可以在每次抽樣時儲存這些值，然後獲取差異並將其分開。\\t
  • 飽和度 - 如果ThreadPool的currentThreadsBusy值等於maxThreads值，則Tomcat已飽和並將開始排隊。\\t
  • 利用率 - 使用JMX計算與執行緒利用率相對應的currentThreadsBusy / maxThreads。\

Ruby

\\

在Passenger下執行的Ruby提供了一個passenger-status頁面，可以查詢該頁面以獲取關鍵指標。

\\

對於Passenger或Apache mod_rails，我們的訊號是：

\\
  • 請求率 - 獲取每個“應用程式組”的“已處理”計數並進行增量處理以計算每秒請求數。\\t
  • 錯誤率 - 沒有明顯的方式來獲得這個，因為Passenger沒有單獨的錯誤日誌。\\t
  • 延遲 - 您需要從Apache / Nginx訪問日誌中獲取此資訊。以上部分請參閱Web伺服器金色訊號。\\t
  • 飽和度 - 每個“應用程式組”的“佇列中的請求”的非零值將告訴您伺服器已飽和。注意：根據文件，不要使用“頂層佇列中的請求”，因為它應該始終為零。\\t
  • 利用率 - 沒有明顯的方式來獲得這個訊號。\

Python，Node.js和Golang

\\

對於Python，Node.js和Golang，絕大多數情況下應用伺服器非常難以監控

\\

人們通過在程式碼中嵌入度量標準和/或使用特殊的包/ APM工具（如New Relic）進行監控。諸如DataDog之類的一些服務可以為你做到這一點，但你仍然需要自己編寫指標。

\\

對於Python，Django有一個可用的Prometheus模組。

\\

對於Node.js，KeyMetrics和AppMetrics提供了一個API來獲取大部分這些資料。

\\

對於Golang，有些人使用Caddy，它可以通過{latency_ms}欄位提供延遲

\\

（類似於Apache / Nginx），但不提供狀態或請求速率資料（儘管有一個Prometheus 外掛有一些指標）。

\\

如果您不使用現有的庫/工具，則可以始終直接在您的程式碼中嵌入金色訊號：

\\
  • 請求率 - 大多數程式碼是基於每個請求執行的，因此很難在全域性範圍內正確跟蹤，因為程式碼在每次請求後都會結束並丟失狀態。設定全域性請求計數器並直接傳送該請求計數器的最簡單方法。\\t
  • 錯誤率 - 與請求率類似，可能最好使用全域性計數器。\\t
  • 延遲 - 通過捕獲開始和結束時間很容易得到每個請求，但可能需要保持經過時間的計數器以按請求率劃分。\\t
  • 飽和度 - 從程式碼中很難獲得，因為您沒有簡單的全域性訪問許可權，全域性伺服器級別的服務不會跟蹤此情況。\\t
  • 利用率 - 與飽和度相同。\

資料庫的金色訊號

\\

資料庫是大多數線上系統的核心，因此他們的黃金訊號對於良好的系統監控和故障排除通常是至關重要的。特別是資料庫級別的高延遲通常是網站或應用程式問題的核心原因。

\\

MySQL的金色訊號

\\

根據您執行的版本以及您是自己執行MySQL還是使用AWS RDS或Aurora等雲服務，獲取MySQL的黃金訊號的複雜程度各不相同。

\\

下面所說的均適用於基於MySQL的AWS RDS服務，但必須要先啟用效能模式，即通過您的AWS RDS例項引數組開啟這項功能，然後重新啟動資料庫。

\\

對於AWS Aurora，CloudWatch可以提供您所需的全部內容。

\\

對於MySQL，我們的訊號是：

\\

• 請求率 - 每秒查詢數，最容易度量了，合計MySQL狀態變數com_select，com_insert，com_update，com_delete和Qcache_hits即可，

\\

然後進行差值處理以獲得每秒的查詢。

\\

這裡有一個SQL程式碼片斷，它檢索所有執行的查詢的總和：

\\

SELECT sum(variable_value)

\\

FROM information_schema.global_status

\\

WHERE variable_name IN (“com_select”, “com_update”, “com_delete”, “com_insert”, “qcache_hits”) ;

\\
  • 錯誤率 - 從效能模式中獲取全域性錯誤計數，然後執行差值處理\

這是一個檢索全域性錯誤計數的SQL程式碼片段：

\\

SELECT sum(sum_errors) AS query_count

\\

FROM performance_schema.events_statements_summary_by_user_by_event_name

\\

WHERE event_name IN (‘statement/sql/select’, ‘statement/sql/insert’, ‘statement/sql/

\\

update’, ‘statement/sql/delete’);

\\
  • 延遲 - 我們可以從效能模式中獲得延遲。為了獲得延遲，我們使用兩條語句SELECT和TRUNCATE，因為我們必須在讀取之間清空表：\

SELECT（avg_timer_wait）/ 1e9 AS avg_latency_ms FROM

\\

performance_schema.events_statements_summary_global_by_event_name

\\

WHERE event_name ='statement / sql / select';

\\

TRUNCATE TABLE

\\

performance_schema.events_statements_summary_global_by_event_name;

\\
  • 飽和度 - 這很難得到。最簡單的方法是當出現急劇增長時監視正在執行的執行緒和警報\

。這是一個即時測量，因此您應該在幾個較短的監控時間間隔內進行平均。

\\

SELECT sum(variable_value)

\\

FROM information_schema.global_status

\\

WHERE variable_name = “THREADS_RUNNING” ;

\\

如果您擁有I/O限制的工作負載，則可以監視Linux或AWS RDS上的DiskQueueDepth中的I/O利用率。

\\
  • 利用率 - 直接從作業系統監控CPU和I/O的使用情況。在AWS RDS上，您還可以從CloudWatch獲取CPU利用率。\

作業系統的金色訊號

\\

作業系統當然是任何系統的關鍵部分，因為它是所有其他服務的基礎。因此，監控CPU，RAM，網路和磁碟以確保良好和可靠的服務通常至關重要。

\\

Linux的金色訊號

\\

應用程式服務依賴於它們底層的硬體，比如CPU，RAM，網路和I/O的核心資源。因此理想情況下，我們可以從Linux或任何作業系統獲取我們的金色訊號。當上層服務對底層資源使用（特別是I / O）敏感時，這一點尤為重要。

\\

即使您沒有對這些事情發出警報，它們也會提供有關更高階別度量標準中觀察到的更改的有用詳細資訊。例如，如果MySQL延遲突然上升 - 在SQL、資料或底層I/O系統中是否有變化？

\\

對於Linux而言，我們主要對CPU和磁碟效能感興趣，因為RAM和現代網路從金色訊號的角度來看並不重要，因為它們速度很快，通常不是瓶頸。

\\

中央處理器

\\

對於CPU來說，唯一真正的訊號是利用率和飽和度，因為錯誤、延遲和請求並不十分相關：

\\
  • 飽和度 -我們想要CPU 的執行佇列長度，當程式必須等待CPU可用時，它會大於零。要獲得準確的測量結果很難。\

我們可以使用平均負載，但只有在I / O非常少的情況下才能使用，例如Linux的平均負載

\\

包括I/O處理。負載平均值高於1-（2*CPU個數）通常被認為是飽和的。真正的CPU執行佇列資料非常難以獲得，因為所有工具只能獲得相當嘈雜的瞬時測量資料。

\\

為了解決這個問題，我建立了一個名為runqstat的新開源工具（仍在開發中）。

\\

CPU閒置（steal ）比例也可以表示CPU飽和度。對於執行佇列不太精確的HAProxy或Node.js等單執行緒負載也很有用。

\\
  • 利用率 - 我們需要CPU百分比，但這也需要一些數學計算，所以您需要計算CPU百分比：\

User + Nice + System + (probably) Steal

\\

不要新增空閒時間百分比或iowait百分比。

\\

對於容器來說，測量飽和度和利用率更加複雜和困難。獲得飽和度的一個簡單方法是使用nr_throttled指標讀取每個容器的/ proc檔案系統以及cpu.stat檔案，每次容器被CPU抑制時都會增加該指標。將此值進行差值處理以得到每秒抑制數，在Docker告訴您使用的CPU太多並且受到抑制時來進行。

\\

磁碟使用情況

\\

對於磁碟使用情況，金色訊號來自iostat實用程式或直接來自/proc/diskstats（大多數監控代理都這樣做）。獲取服務資料所在磁碟的資料。

\\
  • 請求速率 - 磁碟速率是磁碟系統的每秒IO（請求合併之後），在iostat實用程式中是r/s和w/s列。\\t
  • 錯誤率 - 由於磁碟錯誤非常罕見，因此無用。\\t
  • 延遲 - 讀取和寫入時間，其中iostat是平均等待時間（等待）。它包括佇列時間，因為當磁碟飽和時，這個時間會急劇增加。如果您有I/O敏感服務，您也可以測量iostat服務時間。\\t
  • 飽和度 - 最好由每個磁碟的I/O佇列深度來衡量，它由iostat中的aqu-sz變數提供。\\t
  • 利用率 - 這對現代SSD，雲或SAN磁碟無用，因為它們並行處理IO請求。\

結論

\\

金色訊號是一個豐富而有趣的探索領域，因為許多服務仍然缺乏監測，或者他們缺乏暴露正確的指標。

\\

即使在雲端和DevOps革命中，許多主流工具仍然沒有真正提供我們有效管理和維護基礎設施所需的全部資料，但我們一直在努力使其日臻完善。

\\

關於作者

\\

6b4d6ea37d48e03cb137cf6de22b2811.jpgSteve Mushero 擁有超過 25年的IT和軟體經驗，主要擔任技術長或IT經理，從紐約到西雅圖，矽谷和上海等眾多初創公司和大公司。他目前是OpsStack.io和ChinaNetCloud的執行長，該公司是中國第一家也是最大的網際網路管理服務提供商。史蒂夫位於上海和矽谷。

\\

檢視英文原文：Monitoring SRE's Golden Signals

相關文章