【監控】天機鏡——優土大數據平臺應用級別監控利器

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

 

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、p7五、p9八、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的結果進行合併。