介紹

系統和基礎設施監控是各種規模的運營團隊的核心職責。行業里已經開發了許多策略和工具，以幫助監控服務器，收集重要數據，并響應不同環境中的事件和不斷變化的條件。但是隨著軟件方法和基礎設施設計的發展，監控必須適應新的挑戰并在相對不熟悉的領域提供洞察力。

到目前為止，在本系列中，我們已經討論了什么是指標，監控和警報以及良好的監控系統所具備的特征。我們討論了從基礎架構和應用程序收集指標以及在整個基礎架構中監控重要的信號。在我們的上一篇指南中，我們介紹了如何通過了解各個組件和良好警報設計的標準，將指標和警報付諸實踐。

在本文中，我們將了解高度分布式架構和微服務的監控和指標收集如何變化。云計算、大數據集群和容器編排層的日益普及迫使運營專業人員重新思考如何大規模設計監控，并通過更好的儀器解決獨特的問題。我們將討論新的部署模型有什么不同以及可以使用哪些策略來滿足這些新需求。

高度分布式架構會帶來哪些挑戰？

為了模擬和鏡像它所監視的系統，監控基礎設施一直在某種程度上分布。然而，許多現代開發實踐（包括圍繞微服務，容器和可互換的短暫計算實例的設計）已經大大改變了監控環境。在許多情況下，這些變化的核心特征是使監測變得更困難的因素。讓我們花一點時間來看一下這些與傳統環境不同的方式以及它們如何影響監控。

工作與基礎資源分離

許多系統行為方式的一些最根本的變化是由于新的抽象層的爆炸式增長，軟件可以圍繞它設計。容器技術改變了已部署軟件與底層操作系統之間的關系。部署在容器中的應用程序與外部世界、其他程序和主機操作系統的關系不同于通過傳統方式部署的應用程序。內核和網絡抽象可能導致對操作環境的不同理解，具體取決于您檢查的層。

通過創建一致的部署策略，這種抽象級別在很多方面都非常有用，可以更輕松地在主機之間遷移工作，并允許開發人員對其應用程序的運行時環境進行嚴密控制。然而，這些新功能的代價是增加了復雜性，并且與為每個進程提供動力的資源建立了更為松散的關系。

增加基于網絡的通信

新架構中的一個共同點是越來越依賴內部網絡通信來協調和完成任務。以前，單個應用程序的域可能會分散在需要協調和共享信息的許多組件中。這在通信基礎設施和監控方面會產生一些影響。

首先，因為這些模型建立在小型離散服務之間的通信之上，所以網絡健康變得比以往更加重要。在傳統的，更加單一的體系結構中，協調任務、共享信息和組織結果主要是在具有常規編程邏輯的應用程序中或通過相對少量的外部通信來完成的。相反，高度分布式應用程序的邏輯流程使用網絡進行同步，檢查對等體的健康狀況并傳遞信息。網絡健康和性能直接影響比以前更多的功能，這意味著需要更密集的監控來保證正確的操作。

雖然網絡變得比以往任何時候都更加重要，但由于參與者數量和個人通信線路的增加，有效監控網絡的能力越來越具有挑戰性。不是跟蹤幾個應用程序之間的交互，而是需要在數十個，數百個或數千個不同點之間進行正確的通信，以確保相同的功能。除了考慮復雜性之外，增加的流量還會給可用的網絡資源帶來額外的壓力，進一步加劇了可靠監控的必要性。

功能和責任分配到更大程度

上面，我們提到了現代架構在許多較小的分立組件之間劃分工作和功能的趨勢。這些設計可以對監控環境產生直接影響，因為它們使清晰度和可理解性特別有價值，但卻越來越難以捉摸。

需要更強大的工具和儀器以確保良好的工作秩序。但是，由于完成任何給定任務的責任是分散的，并且在不同的工作單元（可能在許多不同的物理主機上）之間分配，因此理解責任在于性能問題或錯誤的位置可能很困難。觸及許多組件的請求和工作單元（其中許多組件是從可能的候選者池中選擇的），使用傳統機制使請求路徑可視化或根本原因分析變得不切實際。

短期和短暫的單位

適應傳統監測的進一步斗爭是合理地追蹤短期或短暫的單位。無論關注的單元是云計算實例，容器實例還是其他抽象，這些組件通常都違反了傳統監控軟件所做的一些假設。

例如，為了區分有問題的故障節點和故意銷毀的實例以縮小規模，監控系統必須對您的配置和管理層有一個比以前更必要的了解。對于許多現代系統而言，這些事件發生的頻率更高，因此每次手動調整監控域都是不切實際的。隨著這些設計，部署環境變化更快，因此監控層必須采用新策略來保持價值。

許多系統必須面對的一個問題是如何處理來自被破壞實例的數據。雖然可以快速配置和取消配置工作單元以適應不斷變化的需求，但必須決定如何處理與舊實例相關的數據。數據不一定會立即失去其價值，因為基礎工作者不再可用。當每天有數百或數千個節點來來往往時，可能很難知道如何從短期實例的碎片化數據中最好地構建關于系統整體運行狀況的敘述。

擴展監控需要哪些更改？

現在我們已經確定了分布式架構和微服務的一些獨特挑戰，我們可以討論監控系統在這些現實中的工作方式。一些解決方案涉及重新評估和隔離對不同類型的指標最有價值的內容，而其他解決方案涉及新工具或理解其所處環境的新方法。

粒度和抽樣

服務數量增加導致的總流量增加是最直接的問題之一。除了由新架構引起的傳輸數量膨脹之外，監控活動本身可能開始陷入網絡并竊取主機資源。為了最好地處理增加的數量，您可以擴展監控基礎架構或降低使用數據的分辨率。這兩種方法都值得關注，但我們將重點關注第二種方法，因為它代表了一種更具可擴展性和廣泛有用的解決方案。

更改數據采樣率可以最大限度地減少系統從主機收集的數據量。抽樣是指標集合的正常部分，表示您為指標請求新值的頻率。增加采樣間隔將減少您必須處理的數據量，但也會降低數據的分辨率 - 細節級別。雖然您必須小心并了解最低有用分辨率，但調整數據收集率會對系統可以充分服務的監控客戶端數量產生深遠影響。

為了減少由較低分辨率導致的信息丟失，一種選擇是繼續以相同的頻率在主機上收集數據，但將其編譯成更易消化的數字以便通過網絡傳輸。各個計算機可以聚合和平均度量值，并將摘要發送到監控系統。這有助于在保持準確性的同時減少網絡流量，因為仍然考慮了大量數據點。請注意，這有助于減少數據收集對網絡的影響，但本身并不能幫助解決在主機中收集這些數字所帶來的壓力。

根據多個單元聚合的數據做出決策

如上所述，傳統系統和現代架構之間的主要區別之一是分解哪些組件參與處理請求。在分布式系統和微服務中，通過某種類型的調度或仲裁層，更有可能將工作單元提供給工作池。這對您可能圍繞監控構建的許多自動化流程都有影響。

在使用可互換工作池的環境中，運行狀況檢查和警報策略可能會增長，與其監視的基礎結構之間存在復雜的關系。對個別單位進行健康檢查對于自動退役和回收有缺陷的單位非常有用。但是，如果您具有大規模自動化，則單個Web服務器在大型池中出現故障并不重要。系統將自我糾正，以確保只有健康單位在活動池中接收請求。

雖然主機運行狀況檢查可以捕獲有缺陷的單元，但檢查池本身的運行狀況更適合于警報。池滿足當前工作負載的能力對用戶體驗的影響大于任何單個工作者的能力。基于健康成員數量，池聚合延遲或池錯誤率的警報可以通知操作員更難以自動緩解并且更可能影響用戶的問題。

與供應層集成

通常，分布式系統中的監視層需要更全面地了解部署環境和配置機制。由于這些體系結構中涉及的單個單元的數量，自動化生命周期管理變得非常有價值。無論這些單元是原始容器，業務流程框架內的容器還是云環境中的計算節點，都存在一個管理層，它公開健康信息并接受命令來擴展和響應事件。

游戲中的棋子數增加了統計失敗的可能性。在所有其他因素相同的情況下，這需要更多的人為干預來回應和緩解這些問題。由于監控系統負責識別故障和服務降級，如果它可以掛鉤到平臺的控制接口，它可以緩解大量這些問題。監控軟件觸發的即時自動響應有助于維護系統的運行狀況。

監控系統和部署平臺之間的這種緊密關系在其他架構中不一定是必需的或共同的。但是，自動化分布式系統旨在實現自我調節，能夠根據預先配置的規則和觀察到的狀態進行擴展和調整。在這種情況下，監控系統在控制環境和決定何時采取行動方面發揮著核心作用。

監控系統必須了解供應層的另一個原因是處理短暫實例的副作用。在工作實例中頻繁更換的環境中，監控系統依賴來自旁道的信息來了解何時有意或無意地采取行動。例如，當服務器故意被操作員銷毀時，與服務器突然變得沒有響應而沒有相關事件時，可以從供應者讀取API事件的系統做出不同的反應。能夠區分這些事件可以幫助您的監控保持有用、準確和可信，即使底層基礎架構可能經常更改。

分布式跟蹤

高度分散的工作負載中最具挑戰性的方面之一是了解不同組件之間的相互作用，并在嘗試根本原因分析時分離責任。由于單個請求可能會觸及許多小程序來生成響應，因此很難解釋瓶頸或性能變化的來源。為了提供有關每個組件如何導致延遲和處理開銷的更好信息，出現了一種稱為分布式跟蹤的技術。

分布式跟蹤是一種檢測系統的方法，通過向每個組件添加代碼來闡明處理服務時的請求處理。每個請求都在您的基礎架構邊緣給出一個唯一標識符，該標識符在任務遍歷您的基礎結構時傳遞。然后，每個服務都使用此ID來報告錯誤，或記錄接收請求時間以及何時將其移交給下一階段的時間戳。通過使用這個ID聚合來自組件的報告，可以通過您的基礎架構跟蹤具有準確時序數據的詳細路徑。

此方法可用于了解在流程的每個部分上花費了多少時間，并清楚地識別出任何嚴重的延遲增加。這種額外的工具是一種使度量收集，適應大量處理組件的方法。當在x軸上以時間可視地映射時，生成的內容顯示不同階段之間的關系，每個進程運行的時間以及必須并行運行的事件之間的依賴關系。這對于了解如何改進系統以及如何花費時間非常有用。

提高分布式系統的運營響應能力

我們已經討論了分布式體系結構如何使錯誤原因分析和操作清晰度變得難以實現。在許多情況下，改變人類對問題的回應和調查方式是這些含糊不清的答案的一部分。設置工具以便以有條理的方式分析情況的方式公開信息，可以幫助分類可用的多個數據層。在本節中，我們將討論在解決大型分布式環境中的問題時為成功做好準備的方法。

為每一層設置四個黃金信號的警報

確保您可以響應系統中的問題的第一步是了解它們何時發生。在我們的基礎架構和應用程序收集指標的指南中，我們介紹了Google SRE團隊確定的四個黃金信號監控指標，這些指標是最重要的跟蹤指標。這四個信號是：

• 延遲
• 流量
• 錯誤率
• 飽和度

在檢測系統時，這些仍然是最佳起點，但高分布式系統通常會增加必須監視的層數。底層基礎架構，業務流程層和工作層都需要強大的監控功能，并設置周到的警報以識別重要的變化。警報條件可能在復雜性上增加，以考慮平臺內固有的短暫元素。

獲得完整的圖像

一旦您的系統發現異常情況并通知您的員工，您的團隊就需要開始收集數據。在繼續執行此步驟之前，他們應該了解受影響的組件，事件發生的時間以及觸發的特定警報條件。

開始理解事件范圍的最有用方法是從高層開始。通過檢查收集和概括整個系統信息的儀表板和可視化來開始調查。這可以幫助您快速識別相關因素并了解面臨的面向用戶的影響。在此過程中，您應該能夠覆蓋來自不同組件和主機的信息。

此階段的目標是開始創建項目的精神或物理清單，以更詳細地檢查并開始優先調查。如果您可以識別遍歷不同層的一系列相關問題，則最低層應該優先：基礎層的修復通常可以解決更高級別的癥狀。受影響的系統列表可以作為一個非正式的檢查清單，用于在部署緩解措施時驗證修復程序。

深入研究具體問題

一旦您認為自己擁有合理的事件高級視圖，請按優先級順序深入了解列表中的組件和系統。有關各個單元的詳細指標將幫助您將故障路由跟蹤到最低負責的資源。在查看更細粒度的儀表板和日志條目時，請參考受影響組件的列表，以嘗試進一步了解如何通過系統傳播作用。使用微服務，相互依賴的組件的數量意味著問題會更頻繁地蔓延到其他服務。

此階段的重點是隔離負責初始事件的服務，組件或系統，并確定正在發生的具體問題。這可能是新部署的代碼，錯誤的物理基礎架構，業務流程層中的錯誤，或者系統無法正常處理的工作負載變化。診斷正在發生的事情以及為什么允許您發現如何緩解問題并重新獲得運營狀況。了解解決此問題可能解決其他系統上報告的問題的程度可以幫助您繼續確定緩解任務的優先級。

減輕解決問題的能力

一旦確定了具體細節，您就可以解決或減輕問題。在許多情況下，通過提供更多資源，回滾或將流量重新路由到備用實現，可能會是一種明顯、快速的方法來恢復服務。在這些情況下，解決方案將分為三個階段：

• 執行操作以解決問題并恢復即時服務
• 解決潛在問題以重新獲得全部功能和運營狀況
• 全面評估失敗的原因并實施長期修復以防止再次發生

在許多分布式系統中，冗余和高可用性組件將確保快速恢復服務，但在后臺可能需要更多工作來恢復冗余或使系統退出降級狀態。您應該使用先前編譯的受影響組件列表作為衡量標準來確定您的初始緩解是否可以解決級聯服務問題。隨著監控系統的復雜性的發展，它還可以通過向配置層發送命令來啟動故障單元的新實例或循環出行為不當的單元，從而使這些更全面的恢復過程自動化。

鑒于前兩個階段可能實現自動化，運營團隊最重要的工作通常是了解事件的根本原因。從此過程中收集的知識可用于開發新的觸發器和策略，以幫助預測未來會發生的情況，并進一步自動化系統的反應。監控軟件通常會獲得響應每個事件的新功能，以防止新發現的故障情況。對于分布式系統，分布式跟蹤，日志條目，時間序列可視化以及最近部署等事件可幫助您重建事件序列并確定可以改進軟件和人員流程的位置。

由于大型分布式系統固有的特殊復雜性，將任何重要事件的解決過程視為學習和微調系統的機會非常重要。所涉及的單獨組件和通信路徑的數量迫使人們嚴重依賴自動化和工具來幫助管理復雜性。將新方法編入這些組件的響應機制和規則集（以及您的團隊遵守的操作策略）是監控系統保持團隊管理足跡的最佳方式。

結論

在本文中，我們討論了分布式體系結構和微服務設計為監視軟件引入的一些特定挑戰。構建系統的現代方法打破了傳統方法的一些假設，需要不同的方法來處理新的配置環境。我們探討了當您從單體系統轉向越來越依賴于云或基于容器的環境以及高容量網絡協調時需要考慮的調整。之后，我們討論了您的系統架構可能會影響您對事件和解決方案的響應方式的一些方法。