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

傳統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設計，如果你設計的足夠好，有助于你將監控平臺化，如果你不太明白，那么就看看我后續的文章吧。

來自：http://www.cnblogs.com/colorfulkoala/p/4260568.html?utm_source=tuicool