【監控】數據平臺運營實戰之如何打造應用級別的監控系統

　　本文介紹瞭如何設計監控系統的客戶端包、後端服務以及存儲的解決方案。

　　傳統IT公司可能最核心的應用就是Web服務器和各類Web應用。得益於開源系統以及大數據理念的盛行，大大小小的公司逐漸造成了數據採集、存儲、計算一體化的類似而又不一樣的架構。而在這些架構之上，咱們能夠豐富本身主營業務或者產品線的各類應用，或者說，技術團隊有了這樣的平臺，咱們能夠更加方便的搭建各類應用程序。之前咱們僅僅比較關注基礎設置層面的監控(好比：服務器的load、內存使用、磁盤使用、CPU使用，像ganglia，zenoss就有這樣的監控功能)，在這些趨勢的影響下，除了基礎設施以外，咱們不得不着眼於平臺層面和各類應用的監控。

　　有人說，之前咱們也關注Web應用的QPS、PV等等，但那個時候監控更多的是本身單獨實現的幾個指標統計。今天咱們換個角度去審視監控的問題：如今咱們平臺上運行着各類各樣的應用，這些應用有本身的運維或者開發人員，平臺運維與應用運維須要各司其職，那麼問題來了：如何保證他們能夠很好的協做，又不互相干擾？

　　上面的圖就表示了平臺和應用分工的狀態。試想一下，若是應用開發者的程序出現Bug或者有性能問題就跑過來問平臺運維人員：「是否是你的服務端沒數據？」，「是否是服務器掛了？」，因而平臺運維人員就要費勁的查明真相，那一定會浪費你們的時間。因此最好的方式就是讓雙方都能瞭解本身負責的程序的狀態如何，那麼監控就是最好的方式，確切的說，是一個支持多用戶的監控平臺。

那麼，搞清楚需求，就能夠開工了。須要從何搞起呢？我先根據本身的經驗列個清單，不全的各位幫我補充。

1. 監控數據的模型
2. 採集監控數據
3. 存儲監控數據
4. 展現監控數據

咱們先一步一步來，根據需求，須要什麼信息（監控數據模型），而後在去實現如何獲取這些數據（採集），以後就是存儲，數據到手後，無論你是報表也好，曲線也好，實時預警，離線分析其實都不是問題。步步爲營，且聽我細細道來。

監控數據的模型

　　首先要考慮面向什麼？是面向應用，仍是面向用戶？如今企業裏離職率那麼高，並且工做都是以負責的應用爲準的，而且咱們YY之後監控平臺作大作強對外開放，那麼仍是面向應用吧！（一我的當五我的用的挨踢狗團隊除外！由於一我的負責那麼多應用了就只用面向人設計就好了，否則每一個應用都要記住一些信息，本身看的累。。哈哈，你們不要介意，這是自黑！）。OK，面向應用去設計這條路很對，能夠避免不少問題。那麼，若是對於一個應用來講，它須要監控什麼呢？試想一下，應用監控其實分了不一樣的角度，好比：我要監控它的性能負載，也要監控它的數據量是否有丟失，這實際上在描述兩個不一樣的關注角度。也就是說，一個應用分了多個監控場景，爲何要這麼區分呢？答：爲了之後展現起來更容易理解，並且監控指標的擴展更加方便。那麼，還須要什麼？想象一下，其實監控數據的本質是日誌，咱們之前排查問題就是看日誌的。日誌的基本行爲就是：追加 三元組（時間，地點，事件）。因此，咱們把監控數據看作是一個日誌文件，他的字段以下：

appID: 應用的惟一標識 sceneID：場景ID，應用下面的惟一標識 timestamp：時間戳 location：彙報該指標所在的位置，能夠是一個ip，也能夠是一個ip+端口，也能夠是用戶自定義的一種特定標識 dimValue：具體指標名稱，好比在負載場景下，具體指標就有：QPS，刷磁盤速率，Buffer大小等等 kpiValue：對應指標的值，能夠是速率類型的，也能夠是百分比類型的，也能夠是個絕對值大小

如此一來，你就能夠根據這些標準格式的日誌數據去排除應用程序出現的問題，固然了，若是你採集的足夠實時，徹底能夠作到預警。固然，如何展現數據，決定了你工做效率的高低，圖形曲線或者餅圖多是很是好的選擇，性能指標的走勢看起來像股市曲線同樣爽，固然不能YY太早，數據展現尚未具體分析，我將會在下文提到。

採集監控數據

　　咱們搞清楚須要什麼數據了，但數據怎麼來呢？採集，是張口就來的方案，最好的方式就是不動一行代碼就能夠抓取想要的數據。你當計算機是你肚子裏的蛔蟲呢？那不可能。不入侵原來應用的代碼，彷佛是全部開發人員的共同需求。可是既然通用就必需要有個標準，擺在你面前的只有兩條路：要麼改代碼，要麼改代碼。你此時心中必定萬匹草泥馬奔騰，但事實就是如此：要麼改代碼標準化本地log的規範，使得抓取程序能夠讀取完成統計和計數的功能；要麼入侵代碼，使用簡單的API直接調用便可完成統計和彙報數據。你選擇哪一個？後者能夠保證應用開發人員改動最小的前提下完成更多的功能。不明白嗎？我給你講一下具體怎麼實現。

 

　　具體的效果就是如上圖所示，App1使用了監控客戶端包以後，那麼它會自動的彙報一個sce_load(負載監控場景)中的qps（表明近一分鐘內平均訪問次數）指標，100機器上測得的是9120，即每秒會有9120次訪問。「QPS」徹底是用戶本身取得名字，他知道其含義，而監控的客戶端包僅僅負責彙報數據。

　　那麼看到這裏，你必定會有不少疑問：9120是什麼含義？如何讓它能計算出這個數據？彙報時隔一段時間彙報仍是一直在彙報？OK，咱們先理一下，首先，咱們既然入侵了代碼，那麼這個監控客戶端包就要老實一點，咱們的經驗是一分鐘彙報一次便可。並且，計數的代價要很是低，具體實現就應該是本地計數而已，彙報時須要異步的去讀取本地內存中的統計數據，而後在一個deamon線程裏面去發送數據。

　　數據的含義也須要標準化，其實開源的java metrics(或者瞭解一下jmx)給咱們提供了很是好的方案，它的數據統計類型僅有五種：速率、計數、絕對值、時間分佈、數值分佈。分別舉例說明：速率即便某種方法調用次數，計數就是累加唄，絕對值便是隊列大小，時間分佈便是方法調用耗時所佔總調用次數某個百分比的都在多少以上。。這個有些繞，好比吧50%以上調用都在700毫秒之下，那麼xxxx_p50 = 0.7，xxxx是你本身取得指標名稱。

　　另外，做爲一個包而言，並且要很是的易用:

MonitorClient client = MonitorClient.getInst("App1","sce_load"); public void yourVisitFunc() { client.someKindOfStat("qps") ..... ...... }

只要在你的方法中嵌入了這一行client.someKindOfStat("qps")，那麼上面的統計都可實現。具體統計方法，你要理解一下java metrics的客戶端使用才能理解。剩下的亂七八糟的就是API封裝啊，依賴包避免衝突啊，就像log4j這種你要搞成provided。

存儲監控數據

Table Rolling示意圖

　　上文提到，咱們的監控數據實際上就是日誌。日誌是怎麼定義，其實就是append，僅此而已。而且經過設計它的數據模型咱們知道，這是一張包含了六個字段的大表且非稀疏表。另外它的存儲時效可能有一些要求，由於咱們會要求分析歷史數據。查詢通常須要帶上5個字段（kpiValue字段除外）。如今的選型其實沒有什麼特別，用MySQL能夠，用Phoenix也能夠。MySQL的話須要按照時間分表，由於一張表太大了查詢寫入都會變慢。Phoenix就沒這個問題了，它基於Hbase，而且支持SQL語言，是很是理想的選型。然而咱們如何清理數據呢？這裏須要指出一個問題，大量的刪除HBase的數據會致使他在一次Major compaction的時候IO擁堵，由於他的刪除只是作了墓碑標記，都是統一作合併時才完全刪掉的。對於這個問題我多介紹一下經驗，能夠從日誌結構的特色去設計存儲結構。那就是作Table rolling，顧名思義，table就像日誌文件同樣，隨着時間rolling起來。爲何要這麼作呢？是由於咱們批量刪除的數據具有時間特徵，也就是說在Table Rolling的設計下，咱們能夠巧妙的刪除之前的一整張表，而不是刪除一張大表中的某些數據，這樣作Major Compaction的時候就不會影響當前追加表的性能了。理解Table Rolling的設計前提是理解日誌結構。

　　嚴謹的你確定以爲缺點什麼，由於直接讓全部的客戶端直接寫入HBase或者MySQL的架構是有問題的。YY一下，若是咱們的平臺應用成千上萬，這麼多的Hbase客戶端鏈接必定會搞垮整個集羣。因此，須要一個接收數據的服務端去完成任務，那就是Nginx+Webserver。定義好監控數據的報文協議，好比定義一個嵌套好的Json，Client異步的批量發送Json，而後經過Nginx轉發給無狀態的Webservers，Webserver負責解析併入庫。基本的優化思路就這些了，負載均衡，批量寫入等等，技能無他。

　　存儲這塊總結起來兩點：理解日誌的含義，適當加一些中間件。

展現監控數據

　　最最決定其意義的環節到來了，那就是如何將這些有意義的數據呈現給用戶呢？總結起來：可交互的UI+帶有分析的報表。

　　

 

　　上面的圖片即顯示了一個交互式查詢的線框。上面有時間範圍的選取、按照指標名稱仍是按照主機名稱的分組、選擇具體的指標（維度）、選擇具體的主機等等，這樣，用戶能夠查看其關注指標在時間上的走勢。這個圖其實做用很是大，開發者所關注應用的某個方法調用頻次，方法耗時，以及Buff隊列大小等等均可以觀看，另外，經過兩條曲線比較能夠作到覈對數據的功效。總之，各類應用場景待挖掘。在此推薦一下highcharts，很是好用的控件，構造麴線圖真的是分分鐘。

　　另一個比較值得關注的數據產出是表報，你能夠給你的Boss看，也能夠利用報表去了解峯值出現時段等等。只要你能寫出來的SQL，按期運行就有優質的產出。

　　另外值得一提的是，監控平臺的數據是很是有價值的，你徹底能夠定義好Server API開放給平臺用戶，讓他們本身去定製報表。這樣，省的他們成天來找你提需求。做爲一個平臺運維開發人員，不須要那麼拼的~

系統架構圖

 

　　最後回過頭來總結一下，平臺應用程序利用監控的Client包實現了應用級別的監控，靜默的吧統計信息發送到Webserver，Webserver入庫以後，用戶能夠經過交互式查詢和離線分析的方式去了解本身的應用情況，用戶也能夠經過監控數據的API服務接口定製本身的產出報表。這樣一個監控系統就搞定了，固然了，面向App的設計須要你維護一些用戶與App的關聯信息。建議你好好考慮一下ACL設計，若是你設計的足夠好，有助於你將監控平臺化，若是你不太明白，那麼就看看我後續的文章吧。