本節書摘來自異步社區《數據中心設計與運營實戰》一書中的第2章，第2.1節,作者： 【美】Luiz André Barroso , 【美】Jimmy Clidaras , 【瑞士】Urs H?lzle 更多章節內容可以訪問云棲社區“異步社區”公眾號查看。

2.6 監控基礎設施

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

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基礎架構上的應用。

總結

以上是生活随笔為你收集整理的《数据中心设计与运营实战》——2.6 监控基础设施的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。