SRE（站點可靠度工程）是一種確保 Web 專案可用性的方法。 它被認為是 DevOps 的框架，討論如何在應用 DevOps 實踐中取得成功。 本文的翻譯 書籍 來自Google。 我自己準備了這個翻譯，並依靠自己在理解監控流程的經驗。 在電報頻道 и 我還發布了同一本書中有關服務等級目標的第 4 章的翻譯連結。
貓翻譯。 享受閱讀！
Google 的 SRE 團隊擁有創建成功的監控和通知系統的基本原則和最佳實踐。 本章提供網頁訪客可能遇到的問題以及如何解決導致網頁難以顯示的問題的指導。
確定
沒有單一的詞彙用於討論與監控相關的主題。 即使在 Google 上，以下術語也不常用，但我們將列出最常見的解釋。
監控
即時收集、處理、聚合和顯示系統的定量資料：請求數量和請求類型、錯誤數量和錯誤類型、請求處理時間和伺服器正常運行時間。
白盒監控
基於內部系統元件顯示的指標進行監控，包括日誌、Java 虛擬機器分析指標或產生內部統計資料的 HTTP 處理程序指標。
黑盒監控
從使用者的角度測試應用程式行為。
儀表板
提供服務關鍵健康指標概述的介面（通常是網頁）。 儀表板可能具有篩選器、選擇所顯示的指標的能力等。此介面被設計為識別對使用者最重要的指標。 儀表板還可以為技術支援人員顯示資訊：請求佇列、高優先級錯誤清單以及給定職責區域的指定工程師。
警報（通知）
旨在由人員透過電子郵件或其他方式接收的通知，這可能是由錯誤或請求佇列的增加觸發的。 通知分為：票證、電子郵件警報和即時通訊訊息。
根本原因
軟體缺陷或人為錯誤一旦修正就不應再發生。 問題可能有幾個主要原因：流程自動化不足、軟體缺陷、應用邏輯闡述不夠。 這些因素中的每一個都可能是根本原因，而每一個都必須被消除。
Node and machine（節點與機器）
可互換術語，指實體伺服器、虛擬機器或容器上正在執行的應用程式的單一實例。 一台機器可以承載多個服務。 服務可以是：
- 相互連接：例如快取伺服器和Web伺服器；
- 單一硬體上不相關的服務：例如，配置系統的程式碼儲存庫和精靈，例如 或 .
推
軟體配置的任何變更。
為什麼需要監控？
需要監控應用程式的原因有幾個：
長期趨勢分析
資料庫有多大以及成長速度有多快？ 每日用戶數量如何變化？
性能對比
與 Ajax DB 2.72 相比，Acme Bucket of Bytes 3.14 上的請求是否更快？ 出現附加節點後，請求快取效果會好多少？ 與上週相比，網站運行速度是否變慢？
警報（通知）
有些東西壞了，需要有人來修復它。 或者有些東西很快就會壞掉，需要有人盡快檢查。
建立儀表板
儀表板應回答基本問題並包含以下內容： ——延遲（latency）、流量（traffic）、錯誤（errors）和負載大小（saturation）。
進行回顧性分析（調試）
請求處理延遲增加了，但同時還發生了什麼事？
監控系統可作為商業智慧系統的資料來源，並有助於安全事件的分析。 由於本書重點關注 SRE 擁有專業知識的工程領域，因此我們不會在這裡討論監控技術。
監控和警報使系統可以在其已發生故障或即將發生故障時告訴您。 當系統無法自動修復時，我們希望有人分析警報，確定問題是否仍然存在，解決問題並確定根本原因。 如果您不審核系統組件，您將永遠不會因為「有些事情似乎有點奇怪」而收到警報。
讓員工承受通知的負擔是相當浪費員工時間的。 如果員工正在工作，警報會中斷工作流程。 如果員工在家，警報會打斷個人時間，甚至可能打斷睡眠。 當警報發生過於頻繁時，員工會瀏覽、延遲或忽略傳入的警報。 他們有時會忽略被噪音事件掩蓋的真正警報。 由於雜訊事件會妨礙問題的快速診斷和修正，因此服務中斷可能會持續很長時間。 有效的預警系統具有良好的訊號雜訊比。
為監控系統設定合理的期望
為複雜的應用程式設定監控本身就是一項複雜的工程任務。 即使擁有重要的收集、顯示和警報工具基礎設施，由 10-12 名成員組成的 Google SRE 團隊通常也包括一兩個人，其主要目的是建立和維護監控系統。 隨著我們整合和集中監控基礎設施，這個數字隨著時間的推移而減少，但每個 SRE 團隊通常至少有一個人專門負責監控。 我們不得不說，雖然監控系統儀表板看起來非常有趣，但 SRE 團隊小心地避免了需要有人查看螢幕來監控問題的情況。
總的來說，Google已經轉向簡單、快速的監控系統和最佳的事後分析工具。 我們避免嘗試預測閾值或自動偵測根本原因的「神奇」系統。 偵測最終使用者請求中非預期內容的感測器是唯一的反例； 只要這些感測器保持簡單，它們就可以快速檢測出嚴重異常的原因。 使用監控資料的其他格式（例如容量規劃或流量預測）則更為複雜。 以低採樣率（小時或天）進行很長一段時間（數月或數年）的觀察將揭示長期趨勢。
Google SRE 團隊在複雜的依賴層次結構方面取得了不同程度的成功。 我們很少使用「如果我發現資料庫很慢，我會收到資料庫很慢的警報，否則我會收到網站很慢的警報」之類的規則。 基於依賴關係的規則通常指的是我們系統中不可變的部分，例如用於過濾資料中心使用者流量的系統。 例如，「如果配置了資料中心的流量過濾，則不要就處理使用者請求的延遲向我發出警報」是來自資料中心的警報的一項通用規則。 Google 很少有團隊支援複雜的依賴層次結構，因為我們的基礎架構具有恆定的持續重構率。
本章中描述的一些想法仍然具有相關性：總是有機會更快地從症狀轉向根本原因，尤其是在不斷變化的系統中。 因此，雖然本章概述了監控系統的一些目標以及如何實現這些目標，但重要的是監控系統對於團隊中的每個人來說都是簡單且易於理解的。
同樣，為了保持低噪音水平和高信號水平，監控警報資產的方法必須非常簡單和可靠。 為人們發出警告的規則應該是易於理解並提出明確的問題。
症狀與原因
您的監控系統應該回答兩個問題：「什麼壞了」和「為什麼壞了」。
「什麼壞了」談論的是症狀，「為什麼壞了」談論的是原因。 下表顯示了此類連接的範例。
症狀
原因
收到 HTTP 錯誤 500 或 404
資料庫伺服器拒絕連接
伺服器響應慢
CPU 使用率高或乙太網路纜線損壞
南極洲的用戶收不到貓的 GIF
你的 CDN 討厭科學家和貓，所以一些 IP 位址最終被列入黑名單
私人內容隨處可見
新軟體版本的推出使防火牆忘記了所有 ACL，並讓每個人都可以進入
「什麼」和「為什麼」是創建具有最大訊號和最小雜訊的良好監控系統的一些最重要的構建塊。
黑盒與白盒
我們將廣泛的白盒監控與針對關鍵指標的適度黑盒監控相結合。 比較黑盒與白盒最簡單的方法是，黑盒以症狀為中心，是被動的，而不是主動監控：“系統現在無法正常工作。” 白盒依賴系統的內部驗證能力：事件日誌或網頁伺服器。 因此，白盒可讓您檢測即將發生的問題、看似重新傳輸請求的故障等。
請注意，在多層系統中，一個工程師的職責範圍內的症狀也是另一位工程師的職責範圍內的症狀。 例如，資料庫效能下降。 資料庫讀取緩慢是檢測資料庫 SRE 的症狀。 然而，對於觀察網站緩慢的前端SRE來說，同樣資料庫讀取緩慢的原因是資料庫緩慢。 因此，白盒監控有時側重於症狀，有時側重於原因，具體取決於其範圍有多大。
當收集遙測資料進行調試時，需要進行白盒監控。 如果 Web 伺服器回應資料庫查詢的速度很慢，您需要了解 Web 伺服器與資料庫通訊的速度以及回應的速度。 否則，您將無法區分緩慢的資料庫伺服器和 Web 伺服器與資料庫之間的網路問題。
發送警報時，黑盒監控具有一個關鍵優勢：當問題已經導致真正的症狀時，您可以向收件人觸發通知。 另一方面，對於尚未出現但即將出現的黑箱問題，監控是沒有用的。
四個黃金訊號
四個黃金監控訊號是延遲、流量、錯誤和飽和度。 如果您只能衡量四個使用者係統指標，請專注於這四個指標。
延遲
處理請求所需的時間。 區分成功請求和不成功請求的延遲非常重要。 例如，可以非常快速地診斷由於與資料庫或其他後端的連線遺失而導致的 HTTP 500 錯誤，但是，HTTP 500 錯誤可能表示請求失敗。 確定 500 錯誤對總體延遲的影響可能會導致錯誤的結論。 另一方面，慢速錯誤甚至是快速錯誤！ 因此，監控錯誤延遲而不是簡單地過濾掉錯誤非常重要。
交通
對系統的請求數量是透過高階系統指標來衡量的。 對於 Web 服務，此測量值通常表示每秒 HTTP 請求數除以請求的性質（例如，靜態或動態內容）。 對於音頻流系統，此測量可能側重於網路 I/O 速度或同時會話的數量。 對於鍵值儲存系統，此測量可以是每秒的交易數或搜尋結果。
錯誤
這是顯式（例如HTTP 500）、隱式（例如HTTP 200 但與無效內容組合）或策略（例如「如果您在一秒鐘內捕獲回應，則任何一秒鐘都是錯誤」）的失敗請求的比率。 如果 HTTP 回應碼不足以表達所有故障情況，則可能需要輔助（內部）協定來偵測部分故障。 監控所有此類失敗的請求可能無法提供信息，而端到端系統測試將有助於檢測您是否正在處理不正確的內容。
飽和
此指標顯示您的服務的使用強度。 這是一種系統監控措施，可識別最受限的資源（例如，在記憶體受限的系統上，顯示記憶體；在 I/O 受限的系統上，顯示 I/O 數量）。 請注意，許多系統在達到 100% 利用率之前會降低效能，因此制定利用率目標非常重要。
在複雜的系統中，飽和度可以透過更高等級的負載測量來補充：您的服務能否正確處理雙倍流量、僅處理多 10% 的流量，或處理比目前更少的流量？ 對於沒有改變請求複雜性的參數（例如，「什麼都不給我」或「我需要一個唯一的單調整數」）且很少更改配置的簡單服務，靜態負載測試值可能就足夠了。但是，如上一段所述，大多數服務必須使用間接訊號，例如CPU 使用率或網路頻寬，這些訊號具有已知的上限。 延遲增加通常是飽和度的主要指標。 在小視窗（例如一分鐘）內測量第 99 個百分位數回應時間可以提供非常早期的飽和訊號。
最後，飽和度也與即將飽和的預測有關，例如：“看起來您的資料庫將在 4 小時內填滿您的硬碟。”
如果您測量所有四個黃金訊號，並且當其中一個指標出現問題（或者在飽和的情況下，接近問題）時，您向某人發出警報，您的服務將或多或少受到監控。
擔心“尾巴”（或儀器和性能）
從頭開始創建監控系統時，人們傾向於根據平均值來開發系統：平均延遲、節點的平均 CPU 使用率或平均資料庫填充度。 最後兩個例子的危險是顯而易見的：處理器和資料庫的處理方式非常不可預測。 這同樣適用於延遲。 如果您執行平均延遲為 100 毫秒、每秒 1000 個請求的 Web 服務，則 1% 的請求可能需要 5 秒。 如果使用者依賴多個此類 Web 服務，則一個後端的 99% 很容易成為前端回應時間的中位數。
區分慢速平均請求和極慢請求尾部的最簡單方法是收集以統計資料（直方圖是一個很好的顯示工具）表示的請求測量值，而不是實際延遲：服務在0 毫秒之間處理了多少個請求和10 ms、10 ms 到30 ms 之間、30 ms 到100 ms 之間、100 ms 到300 ms 之間等。以近似指數方式擴展直方圖邊界（近似為3 倍）通常是可視化分佈的簡單方法的請求。
選擇適當的測量詳細程度
系統的不同元素必須在不同的細節層級上進行測量。 例如：
- 監控一段時間內的 CPU 使用率不會顯示導致高延遲的長期峰值。
- 另一方面，對於每年停機時間不超過 9 小時（每年正常運行時間為 99,9%）的 Web 服務來說，每分鐘檢查 HTTP 200 回應一次或兩次以上可能會過於頻繁。
- 同樣，每 99,9-1 分鐘檢查硬碟空間是否有 2% 的可用性可能沒有必要。
請注意如何建立測量的粒度。 每秒收集一次 CPU 負載可以提供有趣的數據，但這種頻繁的測量收集、儲存和分析的成本可能非常昂貴。 如果您的監控目標需要高粒度且不需要高回應能力，則可以透過在伺服器上設定指標收集，然後設定外部系統來收集和聚合這些指標來降低這些成本。 您可以...嗎：
- 每秒測量 CPU 負載。
- 將細節減少至 5%。
- 每分鐘匯總指標。
此策略將允許您以高粒度收集數據，而不會產生高分析和儲存開銷。
盡量簡單，但不簡單
不同需求的疊加可能會導致非常複雜的監控系統。 例如，您的系統可能具有以下複雜元素：
- 根據請求處理延遲的不同閾值、不同百分位、針對所有類型的不同指標發出警報。
- 編寫額外的程式碼來檢測和識別可能的原因。
- 為每個可能的問題原因建立相關的儀表板。
潛在併發症的來源永無止境。 與所有軟體系統一樣，監控可能變得非常複雜，以至於變得脆弱且難以更改和維護。
因此，設計監控系統時應盡可能簡化。 選擇追蹤內容時，請記住以下幾點：
- 最常捕捉真實事件的規則應該盡可能簡單、可預測和可靠。
- 應刪除不經常執行的資料收集、聚合和警報配置（例如，對於某些 SRE 團隊來說，少於季度一次）。
- 收集但未在任何預覽儀表板中顯示或由任何警報使用的指標是要刪除的候選指標。
在谷歌，基本指標的收集和聚合，與警報和儀表板相結合，作為一個相對獨立的系統運作良好（谷歌的監控系統實際上分為幾個子系統，但人們通常都了解這些子系統的各個方面）。 將監控與其他技術結合檢查複雜系統可能很誘人：詳細的系統分析、進程偵錯、追蹤異常或故障的詳細資訊、負載測試、日誌收集和分析或流量檢查。 雖然大多數這些東西與基本監控有共同點，但混合它們會導致太多結果並創建一個複雜而脆弱的系統。 與軟體開發的許多其他方面一樣，透過清晰、簡單、鬆散耦合的整合點支援不同的系統是最佳策略（例如，使用 Web API 以可長期保持一致的格式檢索聚合資料） ）。
將原則結合在一起
本章討論的原則可以合併為 Google SRE 團隊認可和遵循的監控和警報理念。 堅持這種監控理念是可取的，是創建或修改警報方法的良好起點，並且可以幫助您提出有關營運職能的正確問題，無論您的組織規模如何或服務或系統的複雜程度如何。
在建立監控和警報規則時，詢問以下問題可以幫助您避免誤報和不必要的警報：
- 此規則是否偵測到系統中無法偵測到的緊急狀態、號召性用語以及不可避免地影響使用者的狀態？
- 我可以忽略這個警告，因為它是良性的嗎？ 我何時以及為什麼可以忽略此警告以及如何避免這種情況？
- 此警報是否意味著用戶受到負面影響？ 是否存在使用者不會受到負面影響的情況，例如透過流量過濾或使用應過濾警報的測試系統時？
- 我可以針對此警報採取行動嗎？ 這些措施是緊急還是可以等到早上？ 可以安全地自動化操作嗎？ 這項行動是長期解決方案還是短期解決方案？
- 有些人會收到有關此問題的多個警報，那麼有沒有辦法減少警報數量？
這些問題反映了警報和警告系統的基本原理：
- 每次警報到來時，我都必須立即做出反應。 在我感到疲倦之前，我每天可以緊急反應幾次。
- 每個警報必須是相關的。
- 對警報的每次回應都必須需要人工幹預。 如果通知可以自動處理，那麼它應該不會到達。
- 警報應該是關於以前不存在的新問題或事件。
這種方法模糊了某些區別：如果警報滿足前面的四個條件，則警報是從白盒還是黑盒監控系統發送並不重要。 這種方法也強化了某些差異：最好花更多的精力來辨識症狀而不是原因； 當談到原因時，你只需要擔心不可避免的原因。
長期監測
在當今的生產力環境中，監控系統透過不斷變化的軟體架構、工作負載特徵和效能目標來監控不斷發展的生產系統。 目前難以自動化的警報可能會變得司空見慣，甚至可能值得解決。 此時，必須有人找到並消除問題的根源； 如果無法實現這種解決方案，則對警報的回應需要完全自動化。
在製定監測決策時必須考慮長期目標，這一點很重要。 今天運行的每個警報都會分散人們對明天改進系統的注意力，因此從長遠來看，生產系統的可用性或性能通常會在改進監控系統所需的時間內降低。 讓我們來看兩個例子來說明這個現象。
Bigtable SRE：過度警覺的故事
Google 的內部基礎架構通常會根據服務等級 (SLO) 進行配置和衡量。 許多年前，Bigtable 的服務 SLO 是基於模擬真實客戶端的綜合交易的平均效能。 由於 Bigtable 和儲存堆疊較低層級的問題，平均效能由「大」尾部驅動：最糟糕的 5% 的查詢通常比其餘查詢慢得多。
當接近 SLO 閾值時會發送電子郵件通知，當超過 SLO 時會發送訊息警報。 這兩種類型的警報發送的頻率都很高，耗費了大量的工程時間：團隊花了大量時間對警報進行排序，以找到少數真正相關的警報。 我們經常錯過實際影響用戶的問題，因為只有部分警報針對該特定問題。 由於基礎設施中存在可以理解的問題，許多警報並不緊急，並以標準方式處理，或者根本沒有處理。
為了解決這種情況，團隊採取了三管齊下的方法：在努力提高 Bigtable 效能的同時，我們暫時將 SLO 目標設定為查詢回應延遲的第 75 個百分點。 我們也關閉了電子郵件警報，因為它們太多了，以至於不可能花時間診斷它們。
這個策略讓我們有喘息的空間來開始解決 Bigtable 和較低層級儲存堆疊中的長期問題，而不是不斷地解決戰術問題。 工程師實際上可以完成工作，而不必一直受到警報的轟炸。 最終，暫時推遲警報處理使我們能夠提高服務品質。
Gmail：可預測的、經過演算法處理的人類回應
Gmail 最初是建立在經過修改的 Workqueue 流程管理系統之上的，該系統旨在批次處理搜尋索引的區塊。 Workqueue 適應了長期進程，隨後應用於 Gmail，但事實證明，不透明排程程式程式碼中的一些錯誤非常難以修復。
當時，Gmail 監控的結構是，當使用 Workqueue 取消單一任務時，就會觸發警報。 這種方法並不理想，因為即使在當時，Gmail 也執行了數千項任務，每項任務都提供給我們的一小部分使用者。 我們非常關心為 Gmail 用戶提供良好的用戶體驗，但處理如此多的警報卻是遙不可及。
為了解決這個問題，Gmail SRE 創建了一個工具來幫助盡可能最好地調試調度程序，以最大程度地減少對用戶的影響。 團隊就是否簡單地自動化從問題發現到修復直至找到長期解決方案的整個週期進行了一些討論，但有些人擔心這樣的解決方案會延遲實際解決問題。
這種緊張關係在團隊中很常見，並且常常反映出對自律缺乏信任：雖然有些團隊成員希望留出時間進行正確的修復，但其他人擔心最終的修復會被遺忘，而臨時修復將永遠持續下去。 這個問題值得關注，因為很容易暫時解決問題而不是使情況永久化。 管理人員和技術人員在實施長期修復、支援和優先考慮潛在的長期修復方面發揮關鍵作用，即使在最初的「痛苦」消退之後也是如此。
定期、重複的警報和演算法回應應該是一個危險信號。 您的團隊不願意自動化這些警報意味著團隊缺乏信任演算法的信心。 這是一個需要解決的嚴重問題。
長期
Bigtable 和 Gmail 範例有一個共同的主題：短期可用性和長期可用性之間的競爭。 通常，強有力的努力可以幫助脆弱的系統實現高可用性，但這條道路通常是短暫的，充滿團隊倦怠和對同一英雄團隊中少數成員的依賴。
受控的、短期的可用性降低通常是痛苦的，但對於系統的長期穩定性具有戰略意義。 重要的是不要孤立地看待每個警報，而是要考慮警報量的總體水平是否會帶來健康、可正確訪問的系統、可行的團隊和良好的預後。 我們在向管理層提交的季度報告中分析警報頻率統計數據（通常表示為每個班次的事件，其中一個事件可能包含多個相關事件），使決策者能夠持續了解警報系統負載和整體團隊健康狀況。
結論
健康監控和警報的途徑簡單明了。 它重點關注觸發警報的問題症狀，並監控原因以幫助調試問題。 儘管監視資料庫的負載和效能應該直接在資料庫本身上完成，但您控制的堆疊越高，監視症狀就越容易。 電子郵件通知的用處非常有限，而且很容易成為噪音； 相反，您應該使用儀表板來監控觸發電子郵件警報的所有當前問題。 儀表板還可以與事件日誌配對以分析歷史相關性。
從長遠來看，有必要成功地輪換有關症狀和迫在眉睫的實際問題的警報，調整目標以確保監測支持快速診斷。
感謝您將翻譯讀到最後。 訂閱我的關於監控的電報頻道 и .
來源： www.habr.com