概述

在今天這個時代，資料已經成為重要的資源，小到管理系統大到智慧AI都脫離不了資料的支援。在面對海量資料的壓力下，傳統專案不能不走上了變遷的道路。生存還是毀滅，看你自己咯。從傳統一個war包走天下，到模組化的SOA，在演變到現今火的不行的微服務。系隨著系統變得越來越輕量化，擴充套件性更強，拆分力度更細緻，就必然導致了效能測試，異常排除複雜度的升高。

典型問題有：
* 大量報錯，特別是重要的服務，排查時間可能會很久
* 異常檢視需要到機器上一個個的搜（雖然我們有elk），處理問題實際時間太長了
* 簡單錯誤的問題定位扯皮，組與組之間協調起來也是麻煩的
很多問題不了了之，因為根本不知道發生了什麼鬼，哪裡發生的，只能懷疑網路問題

雖然也有Zabbix等系統，但那畢竟是監控服務的維度和力度還是不夠的，所以開發一個分散式服務監控系統也就勢在必行了，方向就是Google Dapper這篇論文了，所以在10月我們完成了ULTRON一期。

整體設計

監控系統要求就是快速定位問題，及時發現故障，在不影響應用處理能力的情況下儘可能的收集資料。
一期目前實現以下功能：
* 全量採集：設計為服務呼叫資料全量採集
* 實時推送：服務資訊接近實時被推送到處理應用
* 異常報警：實時推送報警資訊到微信、郵件、簡訊等渠道
* 服務排行榜：可根據排行榜發現有潛在危險的應用
* 故障容忍：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資料已經取樣完畢）
* 資料儲存方案的優化
* 實現針對於使用者許可權的實現（方便各個業務線只關注自身應用）
* 流式處理資料方案的升級改造