天機鏡—優土大資料平台應用層級監控神器

標籤：

轉自：http://chuansong.me/n/1208635

 

動機

 

在業務系統開發的初期，我們往往只關注到核心邏輯，而忽略了對系統本身的監控。營運同學提供的ZENOSS(ganglia)能很好的滿足了我們對硬體資源(IO、cpu負載、記憶體、load、串連數等)的監控。但介於核心功能與硬體指標之間的系統指標監控是空白的，如服務本身的負載，jvm狀態，qps，tps，隊列大小，等等。這些資料雖不屬業務功能，但是對後續服務擴容，定位問題能夠提供良好的依據。

 

天機鏡的設計初衷就是為解決這部分需求,提供一個輕量級的資料擷取介面，採集業務系統的各種指標，並將這些指標以圖表的形式直觀清晰的呈現出來。也支援對關鍵計量的即時監控和警示，同時還為使用者提供簡單的運營報表格服務。

 

天機鏡上線一年多，曆經數次版本迭代，當前已為集團上百個大資料應用情境提供了分鐘級指標監控服務，每天收集5億條指標資料，分鐘級監控資料可持久儲存達30天。

 

情境樣本

 

kafka全叢集負載流量(byte)對比圖

 

每個ip表示一個kafka節點,可以直觀看出流量是否均衡，是否穩定。

 

Storm應用記憶體流失

曲線名稱為ip::pid，可以看出106的進程穩定，而107的進程記憶體到一定值後OOM，然後重啟，進程號改變。

 

Web服務頁面的響應耗時分布

 

p999=0.196...的意義在於在最近的1024個樣本中，存在了1~2(0.01%)個190毫秒以上的請求。可以看出，99.9%的請求延遲基本都在毫秒層級，但偶爾會出現若干190毫秒以上的請求。你還可以根據p99,p98,p75,p50等指標進行對比。

度量

 

天機鏡參考Metrics設計了四類統計度量：

 

絕對值：隊列大小，緩衝使用量,線上使用者(通常是一些瞬間值)

計數：GC次數、出錯次數、累計時間，總銷售額等(通常是一些求和值)

速率：tps，qps，每秒上線都使用者數等(通常是一些比值)

分布:可以是時間分布，數值分布，如：某請求調用耗時需要 99.99%在100毫秒以下，通過這個指標定義響應效能。

 

監控採集的每一個指標必然屬於上面的某一類度量，或是一個值或是一個分布。此外我們還提出來一個情境的概念，不同的業務人員對同一個系統的監控指標關注點會不一樣，通過情境的概念，對指標進行分組，方便業務人員查看分析。

 

資料模型與查詢介面

 

資料模型的設計應權衡功能與存取效率，而查詢介面需要結合模型直觀多元的呈現資料。我們在設計監控資料結構時參考了現實世界的破案手段—現場複原。因為最初的設計動機就是為了快速定位系統出現的問題，尋找案發現場的蛛絲馬跡（人物，時間，地點，事件）。對應到程式問題排查就是：（應用，時間戳記，進程唯一識別碼，指標名稱 ，指標值）。

 

我們可以回過頭去看上面OOM的例子，在視覺影像完全靠腦補的日子裡，只能從黑白控制台中利用醜陋的命令列去查看系統日誌。天機鏡出現以後，在介面上簡單的點擊幾下，它就可以幫你把現場資訊回放出來。

 

儲存表：

 

查詢介面非常簡單，我們需要設定一個條件：時間區間，哪些指標，哪些進程（ip or ip+pid）。另外我們提供了多種展示方式，可以將不同來源的相同指標放在一起比較（例如：負載平衡比較），也可以將同一來源的不同指標放在一起比較 （訊息系統流入流出的流量比較，命中與未命中數量的比較）。

 

採集用戶端設計

 

採集用戶端的設計決定了監控平台的易用性，使用者往往是業務開發人員。對於他們來說，要用最小的成本換來最大的收益。所以在設計用戶端時我們從不同的角度考慮了其易用性：

 

1. 輕量化的用戶端：對於完成api層面的監控，我們首先要將採集用戶端植入宿主應用之中。這裡我們選擇在client端做輕量化的統計計算，並且開啟一個靜默線程每一分鐘把當前的計算結果發送到後端儲存，監控模組永遠都不會影響到宿主程式的運行，即使在網路不通暢的情況下，宿主用戶端也感知不到異常的存在。同步監控統計結果太頻繁不僅會導致後端儲存壓力過大，也會影響使用者應用的效能。更重要的一個前提是，對於即時性需求，1分鐘足以。

 

2. 超簡單的API：使用者最希望的是寫一行代碼就完成了監控工作，而現實中我們也的確是這麼做的。之所以能做到這一點，也正是因為我們梳理出80%的通用需求來設計API，而另外20%個性需求才需要調用較為複雜的API才可滿足。另外，有些通用監控是無需設定的，比如JVM相關的各種監控。

 

對於監控資料的收集，我們的設計目標是：歸檔時間長，允許丟失，近即時，統計量豐富。可能用一個詞彙描述監控資料比較合適：“可視化應用日誌”。

 

服務端設計

 

對於簡單表結構儲存大量資料的情境，Hbase是我們的絕佳選擇。為了滿足天機鏡的查詢需求，我們在Hbase叢集上安裝了Phoenix外掛程式。Phoenix支援了類SQL語言，很容易與前端介面整合在一起。

 

對於接收伺服器，我們簡單的使用nginx+webserver的方式。針對更大的並發量，可以在接收伺服器做一些batch以及throttle。接收伺服器組件很好的解耦了採集層與儲存層。得益於解耦的設計，天機鏡除了支援Hbase儲存之外，還支援了mysql儲存。另外對於不同的資料來源，接收伺服器還可以支援採集jmx監控資料。

 

 

豈止於監控，資料總是有用的。我們對資料平台的基礎服務層做了一定的封裝，內建了很多通用指標的監控，這樣可以對所有平台的使用者的應用做出大致的資源佔用情況監控，比如訊息系統的流量貢獻、消費與生產訊息量的核對、請求量統計、快取命中率、資料掃描量等等。天機鏡開放了資料提供者，使用者可以定製報表，平台管理員可以產生消費資源報表。另外，利用其近即時（一分鐘內）的特性做簡訊和郵件的警示等等。

 

結論與建議

 

總體而言，天機鏡的工作是把應用的作業記錄圖形化展現，並且可以根據任何時間以多元方式對比呈現，大大化簡了排查問題的難度，同時通過報表也能讓我們更直觀的瞭解程式，預警功能避免一些問題的發生。天機鏡像是一種刻畫資料平台生態鏈各環節狀態的資料引擎，當然，這需要精心設計出一個更好的互動式UI或者報表。

 

用戶端

 

需求的梳理，最簡單的api滿足最福士的需求，如果想兼顧，那麼必然會讓api更加複雜難用；

 

不需要刻意追求資料的高即時性，增大80%的成本卻提高了1%的收益這是得不償失的；

 

靜默，不要因為監控影響了自己的應用運行；

 

服務端

 

做好解耦，這樣無論你是擴容升級，還是功能更新，都易於操作；

中介軟體的資料處理策略會讓你的基礎服務更加穩定、高效、靈活。

 

儲存端

 

Phoenix on hbase可以讓你利用sql代替繁瑣的scan查詢，理解Hbase的儲存原理，有助於你設計更加高效的Phoenix庫表，原則是把查詢條件的高頻欄位放在前面。對於更大量級資料的儲存，可以採用按時分表，刪除操作與追加操作分離，這樣可以避免IO風暴。

天機鏡—優土大資料平台應用層級監控神器