聽說你的監控不理想？這5個特征具備了麼

在當今以使用者為中心的IT環境中，越來越多的組織正在實施站點可靠性工程師 (SRE) 功能，以此來定義衡量系統的可用性和正常運作時間、提高釋出效率和降低故障成本。使用者需求也在不斷推動系統頻繁的變更。基于此，傳統的監控方法根本無法滿足SRE的監控期望和要求。

從本質上講，監控是觀察系統的行為。它的目的是：我的系統是否在做他們應該做的事情？

現在，越來越多的組織開始采用微服務系統架構模式，微服務中的各個服務具有很高的自由度，彈性和安全性要求，是以我們需要一種新的方法來進行監控。

成功監控政策的5個特征

要使SRE取得成功，組織需要一種全新的現代方式，來管理和監控快速擴充和快速變化的IT基礎設施，其中監控是保障服務穩定的關鍵組成部分。

那麼SRE世界中的監控應該是什麼樣的呢？成功的監控政策具有什麼特征？

1. 衡量性能以滿足服務品質要求

現在，僅僅一個Ping指令，來檢視系統它是正常運作還是停機了，已經是不夠了。Ping 指令很有用，但它不能了解服務運作情況。知道一台機器正在運作并提供給客戶的服務，才是真正的商業價值。

那麼，我們如何才能最有效地衡量這些服務的性能。答案是測量系統中每個元件之間每次互動的延遲。在這個以客戶為中心的世界中，高延遲就是新的“故障”。

Web使用者體驗的品質受到衆多微服務性能的影響。如果要完全了解性能，就需要檢查該系統中每個元件和微服務的延遲。所有這些延遲加起來決定了客戶體驗的成敗，進而決定了你的服務品質。

如果每100次資料庫查詢中就有1次運作緩慢，你的服務品質會受到影響嗎？如果每100個客戶中就有5個客戶對你的服務感到不愉快，你的業務會受到影響嗎？

但是，傳統的監視方法使SRE對這些情況并不知情。每個使用者都很重要，每個使用者的互動也很重要。而，他們的體驗直接受到每一次元件互動、每一次磁盤互動、每一次雲服務互動、每一次微服務互動和每一次API 查詢的直接影響，是以它們都應該被衡量。

想象一下，如果不衡量使用者請求的總延遲，并在子元件和微服務中出現不可接受的延遲時提醒SRE，那麼SRE就無法了解導緻Web 應用程式失敗的原因。

是以，SRE需要能夠可靠且經濟高效地測量所有資料，需要全面了解所有基礎設施和所有服務名額。這不僅有助于問題的快速解決，而且一旦你收集了這些名額，你的團隊就有可能在這海量資料中發掘出額外的商業價值（如：使用者偏好）。

2. 集中式監控平台

傳統監控，往往擁有不同的監控工具，每個工具都有特定的目的并建立資料孤島。這是一個缺乏一緻标準和流程的環境。是以，常常無法在組織内的不同團隊之間以清晰且标準的方式共享資訊。

擁有不同的監控工具通常需要更多額外的成本和資源，而且通常隻有少數人知道如何使用它們。在戰略層面，無法全面、統一地了解支撐業務的系統的運作狀況和性能。

通過将你的所有名額（應用程式、基礎設施、雲平台、網絡、容器）集中到一個可觀察性平台中，你的組織将擁有一個跨團隊和服務的一緻的标準性的監控名額。

一個統一實時呈現和關聯所有資料的集中式監控平台，整合了組織内所有團隊的監控工作，并使企業能夠從其監控工作中擷取最大價值。

3.Metrics 2.0的監控解決方案

如果使用傳統的監控流程，今天的SRE如果要從數百萬個資料流中确定性能問題的根源，可能需要數小時的工程時間。為了快速解決性能問題，SRE需要系統更多的上下文内容。

帶有上下文的名額，可以幫助SRE關聯事件，減少識别服務故障的根本原因所需的時間。

這就是為什麼SRE需要擁有符合Metrics 2.0的監控解決方案的原因。Metrics 2.0 是一組圍繞時間序列名額中繼資料的約定、标準和概念，其目标是以自我描述和标準化的格式生成名額。

Metrics 2.0 的基本前提是沒有上下文的名額，沒有多大價值。Metrics 2.0 要求使用有關正在收集的名額的關聯中繼資料或上下文标記名額。例如，在沒有上下文的情況下從一百台伺服器收集CPU使用率并不是特别有用。但是使用Metrics 2.0标簽，你會知道這個特定的CPU名額來自這個特定的伺服器。

當所有名額都以這種方式标記時，查詢和分析變得非常強大。你可以根據這些标簽進行搜尋，并且能夠以多種方式對資料進行切片和切塊，以收集有關你的營運的分析見解和情報。

4.SLO要具有靈活性

服務級别目标 (SLO) ，最近已經成為描述應用程式可靠性的流行工具。正如

谷歌SRE

書中所描述的，SLO是應用程式開發人員和SRE團隊明确捕獲應用程式風險容忍度的一種方法，通過定義可接受的失敗級别，然後根據該決策做出風險vs回報的決策。

用于建立 SLO 的基本步驟包括以下部分：

• 要測量的内容 - 請求數、存儲檢查、操作，就是要測量什麼。
• 所需比率 - 例如“50% 的成功時間”、“99.9% 的時間可以讀取”、“90% 的時間在 10ms 内傳回”。
• 時間範圍 - 要為目标使用的時間段：最後 10 分鐘、上個季度期間、30 天的滾動時間内。 SLO 多半使用滾動時間段或者月曆機關（如“一個月”）來指定，使我們可以比較不同時間段的資料。

将這些部分組合在一起，并在其中包含重要的“位置”資訊，示例 SLO 如下所示：

“據負載均衡器報告，最近 30 天内，90% 的 HTTP 請求成功。”

同樣，衡量延遲的基本 SLO 可能如下所示：

據用戶端報告，最近 30 天内，90% 的 HTTP 請求在 20 毫秒内傳回。

将這種做法引入組織時，從這種簡單的基本 SLO 開始。 之後可以根據需要建立更複雜的 SLO。

因為SLO是一種可用性和性能保證，是以它不應該圍繞識别何時出現問題而設定。相反，SLO 應該圍繞客戶感覺價值設定，因為這會直接影響你取得成功的能力。

許多組織花費大量精力嘗試正确設定他們的SLO。不幸的是，這是白費力氣。因為，很難第一次就讓你的SLO完美，這是不可能的。相反，SLO應該是一個疊代過程。你應該有一個回報循環，根據你每天得到的資訊，及時更新。是以，你的SLO要具有靈活性，需要定期重新評估它們，以確定它們不會太松也不會太緊。

5. 保留你的監測資料以降低未來風險

以前，監測資料通常被認為價值低且成本高。時代變了，與所有計算資源一樣，資料存儲的成本已經大幅下降。

更重要的是，SRE提高了長期保留這些資料的價值。當系統出錯時，SRE需要能回到過去并了解過去有關問題的原因，了解失敗是如何發生的。

資料保留，通常可以帶來有價值的學習，進而降低未來的風險。

總結

與過去相比，在當今以客戶為中心的IT環境中，SRE越來越需要更進階的監控。

當組織接受這些監控特性時，将獲得許多好處，例如更快地識别和解決問題、全面了解所有名額、更好的性能、降低成本以及對決策的準确性更有信心。

譯文連結：

https://thenewstack.io/5-monitoring-characteristics-sres-must-embrace/