微信公眾號：內核小王子
關注可了解更多關於數據庫，JVM內核相關的知識;
如果你有任何疑問也可以加我pigpdong[^1]
前言
隨着微服務化,以及集群規模化,傳統的日志檢索,指標監控,調用鏈分析作為功能單一的系統,已經無法更好的幫我們分析問題,我們需要一個監控平台將他們之間的數據進行整合和分析,輸出更友好的視圖給用戶.
指標報警 -> 應用 -> 服務 -> 事物 -> 堆棧 -> 日志
以下為隨手記的監控平台的Focus架構
下圖描述了典型的三層監控體系,將基礎層,中間件層,應用層的數據進行聚合分析
-
基礎層:監控主機和底層資源,CPU,內存,網絡吞吐,硬盤IO和硬盤容量
-
中間件層:nginx redis kafka mysql tomcat
-
應用層: HTTP訪問吞吐量,響應時間,調用鏈分析,用戶行為分析
調用鏈
我們一般會遵循opentracing的接口,一個調用鏈入口,會開始一個trace,分配到一個traceid,然后緩存到調用鏈上下文,每一個分支調用都會開啟一個span,然后每一個span都會記錄自己的開始時間和結束時間,以及他的父span是誰.這樣就可以清楚的記下,每一個RPC調用,在每一個步驟分別執行了多長時間,例如調用RPC-A花了多久,RPC-A又執行sql-a花了多久,RPC-A讀取緩存花了多久等等.
我們通過調用鏈的過程可以分析出服務間的調用,進而展示出應用間的依賴topo圖,我們可以借助這個topo他再監控頁面展示核心指標的報警.
一般哪些節點需要埋點
- jdbc 我們可以借助druid進行數據采集,調用druid接口獲取統計數據發給采集器
- mybatis 在mybatis的攔截器中進行埋點
- rpc dubbo可以在filter中進行賣掉
- redis
- rocketmq
- httpclient
- springMVC
- log
- jvm監控數據
日志監控
最開始單體引用的時候我們可以直接讓運維查看服務器上的日志,或者用一個跳板機,在這個跳板機上查看多個服務器上的日志,后來數據量和請求上來了,大量的日志進行檢索的時候如果繼續使用grep,AWK這種文本工具將不能滿足需求,然后就有了ELK方案,一般在應用的日志中增加一個appender,將日志輸出到kafka,日志存儲在kafka中,然后通過logstash去kafka拉取日志,當然這個時候可以增加一些filter對日志進行過濾,然后輸出到elastic search中,然后通過kibana提供使用中視圖.
如果我們需要將日志納入統一的監控平台,我們可以將日志和調用鏈中的traceid進行綁定,然后一起存入ES中,這樣在分析某一個調用鏈的時候,可以自動展示對應的日志.
日志降噪,可以借助kafka stream流處理的工具,將相同類型的日志進行去重,例如一個用戶購買的日志,可能都是一樣,只是用戶id和購買金額不一樣,那么我們可以只存儲這個日志,分別在某個時間段出現了多少次,以及對應的用戶,這樣可以節省大量的日志空間,當然也可以提高減速效率.
指標
除了一些硬件負載,例如是否CPU使用率,線程數目,內存大小等,還有一些用戶設置的指標,例如單位時間內購買請求的失敗率等,某一個服務調用次數,日志條數等.以及服務的TOPN視圖,例如按調用量,調用耗時,單位時間內的調用量等
采集器
數據采集器一般部署在應用端,為了支持更高的並發量,我們可以借助ringbuffer這種無鎖隊列提高效率,或者直接推給KAFKA做中轉,那么這里有個選擇就是在推送前,是否需要在應用端節點做一些指標計算或者壓縮,
如果應用端有大量的CPU空余就可以選擇在應用端做,如果應用側對帶寬不敏感,CPU更敏感就將原始數據都推送過去.
有些同學覺得,監控層應該對應用無感,所以希望應用不要依賴監控的SDK,這種方式一般借助 -javaagent對應用進行字節碼增強,這種方式如果只是針對特定的攔截器增加指標,例如rpc調用,日志等,可以簡單地針對特定的類增強,如果需要用戶手工設置監控指標,則需要在用戶層的類做字節碼增強,開發會比較復雜,當然具體情況可以根據公司應用環境進行調整,例如只有用戶手工增加的指標依賴SDK,某個應用沒有指標則可以不依賴
數據存儲
由於監控數據量很大,我們可以選擇放入es中,也將一些歷史數據放入hadoop中
數據分析
可以借助kafka stream,使監控平台更輕量,不需要依賴spark straming或者 apach storm