監控系統說三道四

監控系統說三道四

監控系統現在已是互聯網架構中的標配系統了，不一樣的是各家公司監控的覆蓋面和顆粒度上的差別，關於運維那套監控系統ZIBBIX等不在本次說三道四範圍內，最近一直在寫監控系統的架子，就把看到的寫過的總結下。

1、爲何監控

監控系統在傳統的軟件架構下並無受到太大重視，由於可靠的硬件+軟件的保障，作的最多的就是各類中間件的配置+代碼優化，出了問題一撥IBM/MS的聯繫方式，現現在的移動互聯網架構下的軟件體系，面向的都是各類不可交付型送達，各類無狀態、冪等等操做讓客戶端和服務器端各自都須要對信息進行必定容錯處理，容錯的背後，如何讓系統知道何時在什麼地方發生了什麼事情，簡單說就是一個log，可若是還想知道是誰的log，如何及時知道發生了log，如何根據log等級作到告警，如何對這段時間內的log內容進行統計，有了監控系統，這些個未知未知就變成已知了，有和沒有的區別不在於獲得了什麼，而在於知道失去了什麼。

2、監控什麼

移動互聯網架構中的監控究竟要監控哪些，每家公司側重的都不同，但大致上都大同小異，就是將整個系統中的服務進行應用畫像，每一個參與系統的應用在整個監控體系各自的名字、互相之間的關係和應用內+應用間的狀態，這個和人的圈子是同樣同樣的，今天不舒服生病請假了，爲了保障公司任務不停頓須要有一個交接人。

3、如何監控

監控在整個應用服務畫像中原則上是一個完整的體系，可是在具體監控上仍是分而治之的策略，應用狀態自己的監控能夠經過不斷的詢問獲取，好比CPU/內存/硬盤/網絡等，相似的還有mysql、redis、es、mongo等服務器的狀態，應用處理的數據信息則是在處理數據時刻進行收集整理拿到，操做系統層面的監控能夠經過運維手段獲取，固然常規語言api也能夠獲取，服務應用能夠經過client api調用獲取，而數據信息的輸入輸出則須要對處理數據的單元進行監控，分佈式環境下則須要對整個鏈路的輸入輸出進行監控，移動環境下的信息則須要將整個鏈路擴大到移動端+服務端。

對於須要對服務定製監控的系統來講，一般監控圍繞鏈路+應用狀態監控2個層面，今天簡單總結下java環境下的鏈路監控的設計方式

4、如何設計

4.1 先假設一個如今用的比較多的移動互聯網架構下的應用服務：

• 系統類型

• app (ios/andriod)
• tomcat/jetty
• jar (flat jar/jsw)

• rpc服務

• dubbo
• grpc
• thrift

• http請求服務

• okhttp
• httpclient
• restTemplate

• db

• mysql
• es
• mongodb

先寫這麼多吧，怕是攤大餅吃不完，如何設計應該也是全部programer相對比較關心的內容

---

4.3 監控流程

• 植入
• 收集
• 傳輸
• 接收
• 落地

關於監控流程中的技術選型，借用2張圖僅做參考，通常都這個套路

4.3.1 植入

植入是我瞎編的詞，aop時候一直用的是織入

java監控和信息收集主要有如下幾種，不正確請指正

1. Agent形式，一般是用字節碼修改技術+java.lang.instrument等方式，能夠作到無侵入監控,參考pinpoint,grays,BTrace

Agent形式使用java -javaagent:agent.jar -jar xxx.jar方式運行，具體請google <b>java.lang.instrument</b>

javaagent 一般使用字節碼等技術，經常使用asm、javasist等框架執行，在性能檢測工具中使用較多，jdk6中對<b>java.lang.instrument</b>的功能加強 java attach api能夠作到運行前、運行中對java應用進行監控檢測

aspectJ是國內不少公司經常使用的織入方式，一樣使用的也是javaagent方式，AspectJ的Load Time Weaving機制，須要配置 -javaagent: [path to aspectj-weaver.jar] 。

打開aspectj-weaver.jar，能夠看到META-INF/MANIFEST裏定義了 Premain-Class: org.aspectj.weaver.loadtime.Agent

2. 過濾器、攔截器、aop等配置化方式收集，配置化植入，能夠無需修改代碼，參考zipkin+brave

和agent不同的是，這種方式是典型的分而治之的策略，使用被監控方的方法來監控對方，這種方式應該是日常開發過程當中最經常使用的方式。

3. 代碼埋點植入，須要添加植入代碼收集,參考cat、cat2

具體使用參考cat，開源了好久，沒有過多研究，很差發表評論

開發難度係數逐級遞減，接入系統難度係數逐級遞增，我想說的是監控並非任什麼時候候越細越好，凡事都是一把雙刃劍，監控畢竟和業務系統是強綁定在一塊兒運行的系統，對性能度的影響是最難以把握的。同時監控系統自己的健壯度也是第一考量的要素。

4.3.2 收集

收集是整個監控系統最大頭的一塊，不一樣類型的應用收集的方式、信息內容不盡相同，收集的內容不是拍腦殼出來的，一切都基於收集的信息在後面落到應用中的目的，收集只收集有須要的信息，不然數據倉庫變成了垃圾倉庫了，數據的關聯性+有序性是關鍵，這裏google最具表明性的Dapper論文講的太詳細，參考這裏的中文翻譯，這也是絕大部分監控 ppt 經常使用的素材地： http://bigbully.github.io/Dapper-translation/

在收集系統中有不少能夠統一收集的層，同時還有不少須要收集的埋點，能夠在某一個面上進行收集的理解爲層，必須在某個點上收集的稱爲埋點，二者的關係須要根據實際場景中進行組合仍是拆分，通常鏈路上的收集包括層+埋點，而孤立或者幾個有關係的點則須要單獨埋點進行特別關照。

4.3.3 傳輸

傳輸是對收集模塊信息pipline中的虛擬概念，如何理解徹底根據採用的架構圖設計，通常主要使用以下幾個方式：

• log方式，直接入盤，則傳輸人是log框架，好比logback log4j等
• kafka生產者，傳輸人是kafka
• http請求，傳輸人則是http請求框架，okhttp httpclient等
• 其餘存儲client，直接落入存儲 mongodb，es，hbase等，結束

4.3.4 接收

接收是相對傳輸來說的，除直接落地外，其餘的都須要整合接收功能對信息統一+持久化，具體狀況根據信息量+延遲參考：

• log方式，使用flumeng或者logstash等日誌文件讀取框架二次傳輸
• kafka消費者，接收log並持久化，有些時候這裏可能還會接Storm進行實時分析
• http服務器，服務器統一收集後再選擇二次傳輸

4.3.5 落地

落地是對收集的信息統一管理並持久化起來，一般主要考慮的是存儲的無限擴展性、高可用性，基於這個原則，經常使用的有

• Elasticsearch 直接集成搜索分析功能
• Hbase 常規選擇
• Mongodb 太多
• Cassandra 國內使用較少，3.0以後用的應該還不錯
• Hadoop 很少說，批量幹活的說

4.4 告警

告警系統是監控系統中最重要的一環，信息的落地如何對業務進行反饋完善是告警系統價值所在，沒錯，將損失下降到最低。

基礎的告警功能就是簡單的匹配，比大小等算法，當發生的事情和預期一致或者不一致時，發出警告（郵件、短信、微信等），和自動化測試的思路比較類似

高級的告警功能，（拍腦殼的時候到了），各類自監控，自反饋，智能分析反正沒有作不到只有想不到了，太遙遠，看來作好基礎告警功能纔是王道。

未開啓討論功能請往這走，😁：

歡迎star github: https://github.com/xuminwlt/j360-trace

詳見我的博客: https://www.j360.me