輕鬆構建微服務之監控平臺

微信公衆號：內核小王子
關注可瞭解更多關於數據庫，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