《資料中心設計與營運實戰》——2.6 監控基礎設施

本節書摘來自異步社群《資料中心設計與營運實戰》一書中的第2章，第2.1節,作者： 【美】luiz andré barroso , 【美】jimmy clidaras , 【瑞士】urs hölzle 更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。

各種形式的系統内控是叢集級基礎架構軟體層的一個重要部分，因為無論是工作負載還是硬體基礎架構，其規模和複雜性都決定了監控架構應成為系統最基本組成部分，如接下來的内容所闡述的。

2.6.1 服務級儀表盤

系統操作員需要監測網際網路服務是否達到設定的服務水準。監測資訊必須是非常即時的，這樣操作員（或自動系統）才能以秒（而不是分鐘）為機關采取快速準确的反應以避免巨大的災難。幸運的是，監測隻需要有限的幾個關鍵資訊，例如延遲、使用者需求的吞吐量分析，這些都可以從前端伺服器收集到。這樣的監測系統簡單說就是一個腳本檔案，每隔幾秒收集所有前端伺服器的适當資訊，并發送到系統操作員的儀表盤上。由于大規模服務的前端資訊數量可能是很大的，而且也需要大量的資訊來驗證服務正常運作，是以需要更加成熟的和可擴充的監測支援。例如，不但收集到的資訊本身很重要，資訊随時間産生的變化也相當重要。再比如，系統也會需要監測延遲和吞吐量以外的其他特定的業務參數。監測系統可能還需要支援一種簡單的語言，讓系統操作員在監測到的基礎資訊的基礎上生成衍生參數。

最後，系統還需要根據監測到的資料和閥值進行自動報警，呼叫操作員。不過要想讓報警系統達到完美并非易事，因為如果誤報太頻繁有可能使操作員忽略了真正的報警；但如果隻在極端情況時才觸發報警，則有可能耽誤了解決問題的最佳時機。

2.6.2 性能調試工具

雖然服務級儀表盤可以使操作員快速識别服務層的問題，但卻缺乏問題的詳細資訊以了解服務變慢或者無法滿足要求的原因。運維人員和服務設計人員都需要一些工具的幫助以了解運作在數百台伺服器上的許多程式間的複雜關系，使他們能确定性能異常的根本原因，并找出瓶頸。不同于服務級儀表盤，性能調試工具不需要為線上運作産生實時資訊。可以把它看成是一個資料中心的模拟cpu分析器，用來确定哪些功能調用導緻了大部分的程式時間開銷。

分布式系統跟蹤工具可以滿足上述需要。這些工具模拟某一發起者（例如一個使用者請求），跟蹤一個分布式系統内的所有工作過程，并詳細列出所涉及的各組成部分之間的因果或時間關系。

分布式系統跟蹤工具的實作方式分兩大類：黑盒監控系統和應用/中間件儀表系統。wap5【128】和sherlock【11】系統就屬于黑盒監控工具。這種系統采用的方法包括觀測系統元件間網絡流量和通過統計推斷方法推斷因果關系。這種方法把所有系統元件（除了網絡接口）都看作為黑盒子，是以優勢在于不需要任何對應用或軟體基礎架構部件的了解或輔助就能工作。不過這種方式犧牲了資訊的準确性，因為所有的關系都是通過統計推斷出來的。收集和分析更多的消息資料可以提高準确性，但卻造成監管開銷的增加。

基于工具的跟蹤系統，例如pip 【127】、magpie 【15】和x-trace 【54】，利用顯式修改應用或中間件函數庫的能力可用來傳遞被追蹤的跨機器組資訊及機器組内跨邊界跨子產品的資訊。帶注釋的應用子產品通常也在本地硬碟記錄追蹤資訊，後續由外部的性能分析程式收集。這些系統很準确，因為它們不需要推理，但要求分布式系統的所有部件能支援通過指令收集全面的追蹤資料。google開發的dapper【141】系統就是一個基于注解的追蹤工具執行個體，通過指令關聯所有應用的一些關鍵子產品，如消息、控制流和線程庫，來對應用級軟體保持有效的透明。

基于硬體性能計數器采樣的cpu分析器已經在幫助程式員了解微架構的性能和現象方面取得了顯著的成功。google wide profiling（gwp）基礎架構【125】選擇随機一組機器來收集短期的整機和每個程序配置檔案的資料，并結合所有google二進制符号特征資訊庫，生成叢集範圍的配置檔案視圖。gwp回答了諸如“哪個程式是google最常執行的？”以及“哪個程式是記憶體的最大使用者？”等問題。

2.6.3 平台層監控

分布式系統追蹤工具和服務級儀表盤都能對應用的健康及性能進行檢測。這些工具可以推斷出一個硬體元件可能發生錯誤，但這仍然屬于間接評估。而且由于叢集級基礎架構和應用級軟體的設計都是硬體容錯的，在這個級别進行監控将錯失大量的底層硬體細節問題，可能累積至軟體容錯無法處理，導緻嚴重的服務中斷。持續和直接監測計算平台健康的工具需要能了解和分析硬體和系統軟體的故障。我們會在第7章詳細讨論這些工具以及這些工具在google基礎架構上的應用。