在IT世界裏,和系統相關聯的有研發、測試、運維、產品、運營、客服、用戶等,咱們如何保證系統穩定運行?以前我也講過了系統高可用,其中的有一點就是監控,它能讓咱們及時發現問題,不至於被動地等着用戶來反饋。尤爲是在互聯網行業裏,系統都是7*24小時可用的。因此咱們的監控目標就是:前端
24小時守護系統java
監視運行狀態,實時控制mysql
統計數據,分析指標web
實時報警redis
那麼咱們如何設計咱們的監控系統呢? 首先咱們先肯定咱們的監控點:sql
方法性能監控:對被監控方法或代碼段的執行時間以毫秒爲單位進行統計分析,產生出統計參數指標供參考和做爲報警依據。TP指標:TP50:指在一個時間段內(如1分鐘),統計該方法每次調用所消耗的時間,並將這些時間按從小到大的順序進行排序,取第50%的那個值做爲TP50 值;配置此監控指標對應的報警閥值後,須要保證在這個時間段內該方法全部調用的消耗時間至少有50%的值要小於此閥值,不然系統將會報警。TP90,TP99,TP999與TP50值計算方式一致,它們分別表明着對方法的不一樣性能要求,TP50相對較低,TP90則比較高,TP99,TP999則對方法性能要求很高。數據庫
方法心跳監控:根據業務須要,假設被監控方法或代碼段在必定時間內必然被執行,若是未被執行則認爲此方法心跳中止,能夠在系統中設置報警。系統默認在方法有調用記錄的狀況下每間隔20秒發送一次心跳,所以在系統中配置超時閥值次數的方法是用估量的心跳超時時間(單位秒)除以20獲得的整數。
緩存
自定義監控:當應用系統根據判斷達到某種狀況須要報警時直接進行報警,主要應用於應用程序發生異常被捕獲時發送報警通知,根據業務邏輯判斷,須要報警時發出報警通知,例如某個接口調用失敗,或某個業務執行失敗等等。服務器
URL存活監控:主要針對重要的url和接口進行監控,可監控對外提供的接口或者依賴的外部服務接口是否存活、響應的內容是否符合預期。微信
端口存活監控:主要針對重要的端口存活進行監控,可監控自身系統依賴的端口(數據庫,redis,mq等)是否正常,可監控依賴服務的端口是否正常。
系統存活監控:用於監控實例進程是否存活,當進程異常退出時會發出報警。
JVM監控:用於實時監控java應用虛擬機資源使用狀況,並根據自定義的報警預警規則進行分析進行報警。監控的服務有:監控JVM的CPU,堆和非堆內存使用狀況,Full GC,Young GC狀況,JVM開啓線程數,提供實時的數據展現。
服務器性能監控:針對應用部署的服務器的基礎性能進行監控,監控服務器CPU,內存,磁盤使用狀況、服務器負載,網絡IO,TCP連接數,探活等服務
業務監控:用於監控具體的業務運行狀況,根據傳入的數據進行分析展現和報警。
下面介紹下在上個公司設計的一套監控平臺,參考京東的監控平臺,不過咱們數據量沒那麼大,設計的相對簡單些。
profiler-sdk主要爲接入監控平臺的應用提供調用接口,應用系統經過調用這些接口將分別產生預約格式的性能、心跳、自定義日誌、jvm日誌以及業務監控日誌,並分別將這些日誌信息寫入後綴爲tp.log,alive .log,business.log及jvm.log,biz.log等文件日誌文件。
用filebeat做爲日誌採集器,雖然Logstash功能強大,可是它依賴java、在數據量大的時候,Logstash進程會消耗過多的系統資源,這將嚴重影響業務系統的性能,filebeat用go語言開發,佔用系統資源少。
數據接收中心從Kafka中分類獲取各業務系統產生的日誌,對接收到的日誌信息進行解析,對於不知足格式要求的日誌則直接拋棄,jvm的報警分析在接收中心直接處理,經過web配置的閾值配置日誌進行jvm運行狀況分析,若是達到報警規則,則直接進行報警處理,存儲數據到到redis,hbase,mysql中,供接收中心和前端展現使用
任務調度中心從數據庫中取出要下發任務的詳細信息並緩存,任務調度中心從數據庫中取出要下發任務的時間頻率並緩存,根據每個任務下發的時間頻率開啓timer,每個任務timer開始執行的時間爲一個整點分鐘數,按照必定的時間頻率把任務下發到MQ中
數據分析中心從MQ中獲取任務(分析存活監控這種任務類型,其餘的相似),任務內容中包含監控點的基本信息和報警規則等信息,分解獲取的任務,開始進行訪問監控點的工做(http/socket),判斷是否符合報警規則,如符合則調用報警接口並進行報警,存儲每次訪問的數據信息到數據庫(存活監控記錄表)
業務方接入很簡單,只需引入profiler-sdk,在想要監控的方法上加一行註解便可,在web管理端,咱們能夠看下效果
方法層面的閾值設置和監控效果:
JVM層面的閾值設置和監控效果:
推薦閱讀:
想要交流的朋友能夠關注我公號,加我微信進讀者羣。