【監控】一些關於應用級別監控的總結

1. 採集多樣化的必要性，通俗的說就是把軟硬件的指標放在一塊兒去比較。

　　有時候咱們關注應用的運行狀態不單單要採集應用的各項指標，有時候還須要瞭解同一時間該應用運行環境（容器、虛擬機、硬件）的關鍵指標。然而應用層與其運行環境自己異構，因此採集工具並不相同。好比，咱們用openTSDB去監控個人一個web程序，而用ganglia去監控了它所在的服務器，其實咱們不少時候更加關注軟硬件指標在同一時刻時的表現，切來切去太不直觀了。這樣問題就來了，兩種不一樣的工具分別展現在不一樣的頁面上，能不能把Web程序的指標和服務器的CPU，內存，文件句柄等指標放在一塊兒看呢？

　　其實很容易想到分別採集，統一存儲就能夠了。如今主要作了代碼調用度量的SDK（代碼嵌入式的監控包），JMX採集（大型開源分佈式系統基本都提供），文本協議採集（redis, memcached監控端口，zk stat等），還有硬件指標採集。這些監控數據統一了數據結構，存儲在ES或者HBase之中，這樣就很容易在UI上面渲染各類異構系統的指標的時間曲線。其實這種需求的根本源於系統之間調用的關係，以及應用在環境中運行的依賴關係。

　　在統一的存儲結構中，咱們很容易定義出各類應用或系統的調用關係和依賴關係，這樣，在查詢的時候就很容易吧關聯指標找到，更容易發現問題。因此結論是，多樣化採集+集中存儲是需求的必然。

2. 對於監控，除了指標維度、時間維度、統計模型維度以外，還應該有調用依賴維度

怎麼說呢？

　　之前，咱們會關注當前服務器CPU、MEM、DISK的指標值，咱們藉助一些系統命令去查看，獲得的數據是一維的，就是一個指標的值，可以變化的是指標。

　　再進一步，咱們有一些工具，zenoss這種，能夠把帶寬消耗、CPU消耗在時間維度上投影，那麼得出了一條曲線，這樣是二維了：指標變化，時間變化。

　　再高級一些，對於一個方法的調用咱們能夠從各類角度去觀察它：調用耗時統計、調用頻次、調用計數、調用結果統計，而後打包度量，任何方法都普適的度量模型。這就是指標，時間，模型。模型表明了一套普適統計方法。好比如今頗有名的metrics模型：codahale實現的java metrics。

　　更細的觀測維度是什麼呢？對於指標之間，異構系統之間的調用每每是有關係的，因此一組異構系統指標的監測是有必要的。但這裏要注意，咱們在「1」中說的方式僅僅是把關聯的統計指標放在一塊兒去比較，但這樣粒度太粗了，真正作到關聯指標的觀測，須要着眼於調用的級別去觀測，在一次調用中，A調用了B，這樣的關係不能在時間維度上精確的體現，必須是一一對應才行。因此本質上，這是個新的觀測維度。這就是trace系統。

　　也就是說，各類被監控的系統在發生每一次調用後都有一個call id，惟一的記錄了本次調用。那麼這個call關聯了兩個系統的多個指標。這種模型下，除了定義了調用關係，統計數據是天然而然能夠作到的事情。但就實現而言，須要把他集成在通訊框架以內才能夠作到，由於每次調用是須要精確標記的。

　　其實這種思路與咱們之前高中生物課本上面的同位素標記法很類似，call id就是同位素，每次調用過程就是一次化學變化的過程。