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

標籤：

上古十大神器之一天機鏡：天機鏡又名崑崙鏡。昆崙山西王母所有，能洞察天機，知曉古今！

 

1. 動機

　　在業務系統開發的前期，我們往往只專註到商務邏輯，而忽略了對系統本身的監控。 對硬體資源的監控營運同學提供的ganglia以及ZENOSS 能很好的滿足我們的需求，監控機器的磁碟、cpu負載，記憶體，load，串連數等等。但是介於核心功能以及硬體指標之間的一部分監控資料目前是空白的，比如服務本身的負載，jvm使用，qps，tps，隊列大小，等等。這些資料本不屬於業務功能，但是對後續服務擴容，定位問題能夠提供良好的依據。

　　天機鏡的誕生就是為瞭解決這部分需求,我們提供一個輕量級的資料擷取介面，採集業務系統的各種指標，並將這些指標以圖表的形式展示出來， 能夠直觀清晰的顯示各個指標資訊。我們也提供了對使用者所關注的指標的即時監控和警示的功能，同時還可以為使用者提供定製報表的服務。

　　目前，天機鏡為大資料應用的上百個監控情境提供了服務，每天收集5億條監控資料，持久儲存可達30天。然而目前僅使用四個節點作為儲存，叢集依然可以再增加三倍的業務量。

2. 功能設計

　　天機鏡提供了圖形化的查詢介面，以曲線的形式呈現資料，下面是若干用例：

 

圖1 Kafka叢集全域負載平衡對比圖（上面顯示了不同ip的位元組流量）

圖2. storm應用記憶體泄露案例（曲線名稱為ip::pid，可以看出106的進程穩定，而107的進程記憶體到一定值後OOM，然後重啟，進程號改變）

　圖3. 某方法調用耗時監控（的點的意義是最近樣本池中99.9%的調用都在0.19s以下，當然可以看平均值、p50、p75、p98、p99等等）

看完是否有些感覺？這就是我們日常工作中可能會關注的一些指標。在這裡，我們給這些指標取個專業點兒的名字：“維度”，也就是觀測應用的某一個角度。一個應用存在多個被關注的指標，那麼我們就從多個維度出發，去對它進行監控。天機鏡利用了java Metrics（一個開源的度量包https://dropwizard.github.io/metrics/3.1.0/）對監控行為做了幾個分類：a. 絕對值；b.計數；c.速率；d.時間分布；e.數值結果分布；基本上任何不同類型的度量需求都會被這五種度量類型滿足。下面可以簡單的列舉一些例子：

　　絕對值：隊列大小，Buff使用（基本上是一些size類的）

　　計數：GC次數、累計時間，出現403次數，返回錯誤error1的次數

　　速率：tps，qps，function1的每秒調用次數

　　時間分布：function1調用時間50%（75%，98%，99%，99.9%）都在多少秒以下，最大耗時，平均耗時

　　數值結果分布：function1的傳回值50%（75%，98%，99%，99.9%）都在多少以下。

上面的這些執行個體性的描述，基本可以涵蓋80%的需求。實際上，我們在設計採集用戶端時，就是為了滿足這80%的需求。再這個前提下，保證常用api的default設定能夠在大部分情況下適用。

資料模型與查詢介面

　　資料模型的設計需要考慮功能與相應的存取效率，而查詢介面就要巧妙利用模型中的資料直觀多元的呈現給使用者。我們在考慮設計監控資料結構時參考了現實世界的破案現場，因為最初的設計動機就是為了快速定位系統出現的問題，實際上我們需要的就是：（人物，時間，地點，事件），再直白一點就是：（應用，時間戳記，進程唯一識別碼，維度及維度大小）。你可以回過頭去看上面OOM的例子。在視覺影像完全靠腦補的日子裡，我們只能從黑白控制台中利用醜陋的命令列去查看系統日誌。天機鏡出現以後，我們簡單的在介面上點擊幾下，他就會將當時的現場回放出來。下面是儲存表結構的細節：

 

appID: 應用的唯一標識sceneID：情境ID，應用下面的唯一標識timestamp：時間戳記location：彙報該指標所在的位置，可以是一個ip，也可以是一個ip+連接埠，也可以是使用者自訂的一種特定標識dimValue：具體指標名稱，比如在負載情境下，具體指標就有：QPS，刷磁碟速率，Buffer大小等等kpiValue：對應指標的值，可以是速率類型的，也可以是百分比類型的，也可以是個絕對值大小

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

 

採集用戶端設計

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

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

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

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

 

服務端設計

　　對於簡單表結構儲存大量資料的情境，Hbase是我們的絕佳選擇。為了滿足天機鏡的查詢需求，我們在Hbase叢集上安裝了Phoenix外掛程式。Phoenix支援了類SQL語言，很容易與前端介面整合在一起，另外對於接收伺服器，我們簡單的使用nginx+webserver的方式。對於更大的並發量，可以在接收伺服器做一些batch以及throttle。接收伺服器的好處還有一個就是解耦了採集端與儲存層，天機鏡除了支援Hbase儲存之外，還支援了mysql儲存。另外對於不同的資料來源，接收伺服器還可以支援採集jmx監控資料。

 

 

圖3 天機鏡整體架構圖 

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

 

3. 一些結論與建議

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

用戶端

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

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

　　既然是“可視化日誌”，那麼就允許丟失，同上；

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

服務端

　　做好解耦，這樣無論你因為量級升級系統，還是因為功能更新系統都有很大的好處；

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

儲存端

　　我們在使用Hbase時遇到的最大問題在於刪除資料後會導致一些IO風暴，另外在Phoenix0.4.0存在了跑死cpu的情況（0.4.2已經解決）。對於這些情況我們的解決方案是，讓表在時間上分表。換而言之就是讓table像記錄檔一樣按照時間rolling，這樣的好處是刪除老資料永遠都不會出現IO風暴，因為直接drop的表更當前寫入的表無關。單表的資料量也會因此大大減少，查詢會非常高效。但缺點就是查詢時需要做一些簡要的時間區間判斷，在跨表查詢時會十分繁瑣，需要做兩個sql的結果進行合并。

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