概述
在今天這個時代，數據已經成爲重要的資源，小到管理系統大到智能AI都脫離不了數據的支持。在面對海量數據的壓力下，傳統項目不能不走上了變遷的道路。生存仍是毀滅，看你本身咯。從傳統一個war包走天下，到模塊化的SOA，在演變到現今火的不行的微服務。系隨着系統變得愈來愈輕量化，擴展性更強，拆分力度更細緻，就必然致使了性能測試，異常排除複雜度的升高。mysql
典型問題有：redis
大量報錯，特別是重要的服務，排查時間可能會好久sql
異常查看須要到機器上一個個的搜（雖然咱們有elk），處理問題實際時間太長了微信
簡單錯誤的問題定位扯皮，組與組之間協調起來也是麻煩的
不少問題不了了之，由於根本不知道發生了什麼鬼，哪裏發生的，只能懷疑網絡問題網絡
雖然也有Zabbix等系統，但那畢竟是監控服務的維度和力度仍是不夠的，因此開發一個分佈式服務監控系統也就勢在必行了，方向就是Google Dapper這篇論文了，因此在10月咱們完成了ULTRON一期。架構
總體設計
監控系統要求就是快速定位問題，及時發現故障，在不影響應用處理能力的狀況下儘量的收集數據。
一期目前實現如下功能：app
全量採集：設計爲服務調用數據全量採集分佈式
實時推送：服務信息接近實時被推送處處理應用模塊化
異常報警：實時推送報警信息到微信、郵件、短信等渠道微服務
服務排行榜：可根據排行榜發現有潛在危險的應用
可擴展：支持分佈式部署，可任意橫向擴展
不保證可靠性：爲了保證超強的吞吐量，容許消息丟失
低侵入性：爲了保證不影響現有業務，增長其複雜度，ULTRON採用了低侵入抓取數據
故障容忍：ULTRON自己出現問題不影響現有業務正常運轉，只是監控能力變弱
高吞吐：由於須要全方位監控服務，獲取完整信息，必須有超強的吞吐量
架構圖
實時分析
ULTRON藉助於DUBOO SPI機制對應用進行低侵入式擴展，內置集成輕量級KAFKA客戶端，實現海量數據推送，而且加強自身的故障容忍機制，在應用負載壓力高峯時期會主動下降推送數據的頻率。
ULTRON服務端對數據進行了流式處理，好比排行榜等信息皆來源於此，將來的報表等處理將接入流處理模塊進行。
存儲設計
在存儲上，一期爲了快速迭代採用Mysql HDFS Redis進行輔助數據處理，由於實時查詢數據是通過處理的，WatchDog展示的數據對現有Mysql壓力很是小。估量依照現有數據量，每日流入數據大概1000W左右，固然對於存儲咱們已經有了更好的方案，等待二期進行快速迭代。
消息ID設計
在分佈式追蹤系統中，惟一ID的設計是很是重要的，系統基本功能全是依靠於ID進行展示的。藉助於Google Dapper 阿里鷹眼系統的借鑑完成了自身ID的穿織。舉例：真正ID爲e8aaafe039ee42919b6e493fb364e356-0.1.1
頁面展現-首頁
頁面展現-服務監控
頁面展現-服務追蹤
將來
目前ULTRON系統基本完成對於服務監控的功能，但對於整個監控體系來講只是其核心的一塊，還欠缺着周邊配套的數據檢索動態報表展現等。
下面就羅列下二期準備增長的輔助功能：
應用拓撲圖完善
性能瓶頸的預測
根據當前調用比例、QPS等評估容量
對於redis 、mysql、mq線程監控數據收集（目前MQ mysql數據已經採樣完畢）
數據存儲方案的優化
實現針對於用戶權限的實現（方便各個業務線只關注自身應用）
流式處理數據方案的升級改造
本文分享自微信公衆號 - 架構技術專欄（jiagoujishu）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。