【51CTO.com原創(chuàng)稿件】筆者自2016年加入WiFi***鑰匙，現(xiàn)任WiFi***鑰匙高級架構(gòu)師，擁有10年互聯(lián)網(wǎng)研發(fā)經(jīng)驗，喜歡折騰技術(shù)。主要專注于：分布式監(jiān)控平臺、調(diào)用鏈跟蹤平臺、統(tǒng)一日志平臺、應(yīng)用性能管理、穩(wěn)定性保障體系建設(shè)等領(lǐng)域。

在本文中，筆者將與大家分享一下在實時監(jiān)控領(lǐng)域的一些實戰(zhàn)經(jīng)驗，介紹WiFi***鑰匙是如何構(gòu)建APM端到端的全鏈路監(jiān)控平臺，從而實現(xiàn)提升故障發(fā)現(xiàn)率、縮短故障處理周期、減少用戶投訴率、樹立公司良好品牌形象等目標(biāo)。

WiFi***鑰匙開發(fā)運維團隊的困擾

始于盛大創(chuàng)新院的WiFi***鑰匙，截至到2016年底，我們總用戶量已突破9億、月活躍達5.2億，用戶分布在全球223個國家和地區(qū)，在全球可連接熱點4億，日均連接次數(shù)超過40億次。

隨著日活躍用戶大規(guī)模的增長，WiFi***鑰匙各產(chǎn)品線服務(wù)端團隊正進行著一場無硝煙的戰(zhàn)爭。越來越多的應(yīng)用服務(wù)面臨著流量激增、架構(gòu)擴展、性能瓶頸等問題。為了應(yīng)對并支撐業(yè)務(wù)的高速發(fā)展，我們邁入了SOA、Microservice、API Gateway等組件化及服務(wù)化的時代。

伴隨著各系統(tǒng)微服務(wù)化的演進，服務(wù)數(shù)量、機器規(guī)模不斷增長，線上環(huán)境也變得日益復(fù)雜，工程師們每天都會面臨著諸多苦惱。例如：線上應(yīng)用出現(xiàn)故障問題時無法***時間感知;面對線上應(yīng)用產(chǎn)生的海量日志，排查故障問題時一籌莫展;應(yīng)用系統(tǒng)內(nèi)部及系統(tǒng)間的調(diào)用鏈路產(chǎn)生故障問題時難以定位等等。

綜上所述，線上應(yīng)用的性能問題和異常錯誤已經(jīng)成為困擾開發(fā)人員和運維人員***的挑戰(zhàn)，而排查這類問題往往需要幾個小時甚至幾天的時間，嚴(yán)重影響了效率和業(yè)務(wù)發(fā)展。WiFi***鑰匙亟需完善監(jiān)控體系，幫助開發(fā)運維人員擺脫煩惱，提升應(yīng)用性能。依據(jù)公司的產(chǎn)品形態(tài)及業(yè)務(wù)發(fā)展，我們發(fā)現(xiàn)監(jiān)控體系需要解決一系列問題：

◆面對全球多地域海量用戶的WiFi連接請求，如何保障用戶連接體驗?

◆如何通過全鏈路監(jiān)控提升用戶連接WiFi的成功率?

◆隨著微服務(wù)大規(guī)模推廣實施，鑰WiFi***鑰匙產(chǎn)品服務(wù)端系統(tǒng)越來越復(fù)雜，線上故障的發(fā)現(xiàn)、定位、處理難度也隨之增長，如何通過全鏈路監(jiān)控提升故障處理速度?

◆移動出海已經(jīng)進入深入化發(fā)展的下半場，全鏈路監(jiān)控如何應(yīng)對公司全球化的業(yè)務(wù)發(fā)展?

◆……

全鏈路監(jiān)控

早期為了快速支撐業(yè)務(wù)發(fā)展，我們主要使用了開源的監(jiān)控方案保障線上系統(tǒng)的穩(wěn)定性：Cat、Zabbix，隨著業(yè)務(wù)發(fā)展的需要，開源的解決方案已經(jīng)不能滿足我們的業(yè)務(wù)需求，我們迫切需要構(gòu)建一套滿足我們現(xiàn)狀的全鏈路監(jiān)控體系：

◆多維度監(jiān)控(系統(tǒng)監(jiān)控、業(yè)務(wù)監(jiān)控、應(yīng)用監(jiān)控、日志搜索、調(diào)用鏈跟蹤等)

◆多實例支撐(滿足線上應(yīng)用在單臺物理機上部署多個應(yīng)用實例場景需求等)

◆多語言支撐(滿足各團隊多開發(fā)語言場景的監(jiān)控支撐，Go、C++、PHP等)

◆多機房支撐(滿足國內(nèi)外多個機房內(nèi)應(yīng)用的監(jiān)控支撐，機房間數(shù)據(jù)同步等)

◆多渠道報警(滿足多渠道報警支撐、內(nèi)部系統(tǒng)對接，郵件、掌信、短信等)

◆調(diào)用鏈跟蹤(滿足應(yīng)用內(nèi)、應(yīng)用間調(diào)用鏈跟蹤需求，內(nèi)部中間件升級改造等)

◆統(tǒng)一日志搜索(實現(xiàn)線上應(yīng)用日志、Nginx日志等集中化日志搜索與管控等)

◆……

監(jiān)控目標(biāo)

從“應(yīng)用”角度我們把監(jiān)控體系劃分為：應(yīng)用外、應(yīng)用內(nèi)、應(yīng)用間。如下圖所示：

應(yīng)用外：主要是從應(yīng)用所處的運行時環(huán)境進行監(jiān)控(硬件、網(wǎng)絡(luò)、操作系統(tǒng)等)

應(yīng)用內(nèi)：主要從用戶請求至應(yīng)用內(nèi)部的不同方面(JVM、URL、Method、SQL等)

應(yīng)用間：主要是從分布式調(diào)用鏈跟蹤的視角進行監(jiān)控(依賴分析、容量規(guī)劃等)

羅馬監(jiān)控體系的誕生

根據(jù)自身的實際需求，WiFi***鑰匙研發(fā)團隊構(gòu)建了羅馬(Roma)監(jiān)控體系。之所以將監(jiān)控體系命名為羅馬，原因在于：

1、羅馬不是一天成煉的(線上監(jiān)控目標(biāo)相關(guān)指標(biāo)需要逐步完善);

2、條條大路通羅馬(羅馬通過多種數(shù)據(jù)采集方式收集各監(jiān)控目標(biāo)的數(shù)據(jù));

3、據(jù)神話記載特洛伊之戰(zhàn)后部分特洛伊人的后代鑄造了古代羅馬帝國(一個故事的延續(xù)、一個新項目的誕生)。

一個***的監(jiān)控體系會涵蓋IT領(lǐng)域內(nèi)方方面面的監(jiān)控目標(biāo)，從目前國內(nèi)外各互聯(lián)網(wǎng)公司的監(jiān)控發(fā)展來看，很多公司把不同的監(jiān)控目標(biāo)劃分了不同的研發(fā)團隊進行處理，但這樣做會帶來一些問題：人力資源浪費、系統(tǒng)重復(fù)建設(shè)、數(shù)據(jù)資產(chǎn)不統(tǒng)一、全鏈路監(jiān)控實施困難。目前，各公司在監(jiān)控領(lǐng)域采用的各解決方案，如下圖所示：

正如圖中所示，羅馬監(jiān)控體系希望能夠汲取各方優(yōu)秀的架構(gòu)設(shè)計理念，融合不同的監(jiān)控維度實現(xiàn)監(jiān)控體系的“一體化”、“全鏈路”等。

高可用架構(gòu)之道

面對每天40多億次的WiFi連接請求，每次請求都會經(jīng)歷內(nèi)部數(shù)十個微服務(wù)系統(tǒng)，每個微服務(wù)的監(jiān)控維度又都會涉及應(yīng)用外、應(yīng)用內(nèi)、應(yīng)用間等多個監(jiān)控指標(biāo)，目前羅馬監(jiān)控體系每天需要處理近千億次指標(biāo)數(shù)據(jù)、近百TB日志數(shù)據(jù)。面對海量的監(jiān)控數(shù)據(jù)羅馬(Roma)如何應(yīng)對處理?接下來，筆者帶大家從系統(tǒng)架構(gòu)設(shè)計的角度逐一進行剖析。

架構(gòu)原則

一個監(jiān)控系統(tǒng)對于接入使用方應(yīng)用而言，需要滿足如下圖中所示的五點：

• 性能影響：對業(yè)務(wù)系統(tǒng)的性能影響最小化(CPU、Load、Memory、IO等)

• 低侵入性：方便業(yè)務(wù)系統(tǒng)接入使用(無需編碼或極少編碼即可實現(xiàn)系統(tǒng)接入)

• 無內(nèi)部依賴：不依賴公司內(nèi)部核心系統(tǒng)(避免被依賴系統(tǒng)故障導(dǎo)致相互依賴)

• 單元化部署：監(jiān)控系統(tǒng)需要支撐單元化部署(支持多機房單元化部署)

• 數(shù)據(jù)集中化：監(jiān)控數(shù)據(jù)集中化處理、分析、存儲等(便于數(shù)據(jù)統(tǒng)計等)

整體架構(gòu)

Roma系統(tǒng)架構(gòu)如下圖所示：

Roma架構(gòu)中各個組件的功能職責(zé)、用途說明如下：

Roma整體架構(gòu)中劃分了不同的處理環(huán)節(jié)：數(shù)據(jù)采集、數(shù)據(jù)傳輸、數(shù)據(jù)同步、數(shù)據(jù)分析、數(shù)據(jù)存儲、數(shù)據(jù)質(zhì)量、數(shù)據(jù)展示等，數(shù)據(jù)流處理的不同階段主要使用到的技術(shù)棧如下圖所示：

數(shù)據(jù)采集

對于應(yīng)用內(nèi)監(jiān)控主要是通過client客戶端同所在機器上的agent建立TCP長連接的方式處理，agent同時也需要具備通過腳本調(diào)度的方式獲取系統(tǒng)性能指標(biāo)數(shù)據(jù)。

面對海量的監(jiān)控指標(biāo)數(shù)據(jù)，羅馬監(jiān)控通過在各層中預(yù)聚合的方式進行匯總計算，比如在客戶端中相同URL請求的指標(biāo)數(shù)據(jù)在一分鐘內(nèi)匯總計算后統(tǒng)計結(jié)果為一條記錄(分鐘內(nèi)相同請求進行累加計算，通過占用極少內(nèi)存、減少數(shù)據(jù)傳輸量)，對于一個接入并使用羅馬的系統(tǒng)，完全可以根據(jù)其實例數(shù)、指標(biāo)維度、采集頻率等進行監(jiān)控數(shù)據(jù)規(guī)模的統(tǒng)計計算。通過各層分級預(yù)聚合，減少了海量數(shù)據(jù)在網(wǎng)絡(luò)中的數(shù)據(jù)傳輸，減少了數(shù)據(jù)存儲成本，節(jié)省了網(wǎng)絡(luò)帶寬資源和磁盤存儲空間等。

應(yīng)用內(nèi)監(jiān)控的實現(xiàn)原理(如下圖所示)：主要是通過客戶端采集，在應(yīng)用內(nèi)部的各個層面進行攔截統(tǒng)計： URL、Method、Exception、SQL等不同維度的指標(biāo)數(shù)據(jù)。

應(yīng)用內(nèi)監(jiān)控各維度指標(biāo)數(shù)據(jù)采集過程如下圖所示：針對不同的監(jiān)控維度定義了不同的計數(shù)器，最終通過JMX規(guī)范進行數(shù)據(jù)采集。

數(shù)據(jù)傳輸

數(shù)據(jù)傳輸TLV協(xié)議，支持二進制、JSON、XML等多種類型。

每臺機器上都會部署agent(同客戶端建立TCP長連接)，agent的主要職責(zé)是數(shù)據(jù)轉(zhuǎn)發(fā)、數(shù)據(jù)采集(日志文件讀取、系統(tǒng)監(jiān)控指標(biāo)獲取等)，agent在獲取到性能指標(biāo)數(shù)據(jù)后會發(fā)送至kafka集群，在每個機房都會獨立部署kafka集群用于監(jiān)控指標(biāo)數(shù)據(jù)的發(fā)送緩沖，便于后端的節(jié)點進行數(shù)據(jù)消費、數(shù)據(jù)存儲等。

為了實現(xiàn)數(shù)據(jù)的高效傳輸，我們對比分析了消息處理的壓縮方式，最終選擇了高壓縮比的GZIP方式，主要是為了節(jié)省網(wǎng)絡(luò)帶寬、避免由于監(jiān)控的海量數(shù)據(jù)占用機房內(nèi)的網(wǎng)絡(luò)帶寬。針對各個節(jié)點間數(shù)據(jù)通信的時序圖如下圖所示：建立連接->讀取配置->采集調(diào)度->上報數(shù)據(jù)等。

數(shù)據(jù)同步

海外運營商眾多，公網(wǎng)覆蓋質(zhì)量參差不齊，再加上運營商互聯(lián)策略的不同，付出的代價將是高時延、高丟包的網(wǎng)絡(luò)質(zhì)量，鑰匙產(chǎn)品走向海外過程中，首先會對整體網(wǎng)絡(luò)質(zhì)量情況有正確的預(yù)期，比如如果需要對于海外機房內(nèi)的應(yīng)用進行監(jiān)控則依賴于在海外建立站點(主機房)、海外主站同國內(nèi)主站進行互聯(lián)互通，另外需要對監(jiān)控指標(biāo)數(shù)據(jù)分級處理，比如對于實時、準(zhǔn)實時、離線等不同需求的指標(biāo)數(shù)據(jù)采集時進行歸類劃分(控制不同需求、不同數(shù)據(jù)規(guī)模等指標(biāo)數(shù)據(jù)進行采樣策略的調(diào)整)

由于各產(chǎn)品線應(yīng)用部署在多個機房，為了滿足各個應(yīng)用在多個機房內(nèi)都可以被監(jiān)控的需求，羅馬監(jiān)控平臺需要支持多機房內(nèi)應(yīng)用監(jiān)控的場景，為了避免羅馬各組件在各個機房內(nèi)重復(fù)部署，同時便于監(jiān)控指標(biāo)數(shù)據(jù)的統(tǒng)一存儲、統(tǒng)一分析等，各個機房內(nèi)的監(jiān)控指標(biāo)數(shù)據(jù)最終會同步至主機房內(nèi)，最終在主機房內(nèi)進行數(shù)據(jù)分析、數(shù)據(jù)存儲等。

為了實現(xiàn)多機房間數(shù)據(jù)同步，我們主要是利用kafka跨數(shù)據(jù)中心部署的高可用方案，整體部署示意圖如下圖所示：

在對比分析了MirrorMaker、uReplicator后，我們決定基于uReplicator進行二次開發(fā)，主要是因為當(dāng)MirrorMaker節(jié)點發(fā)生故障時，數(shù)據(jù)復(fù)制延遲較大，對于動態(tài)添加topic則需要重啟進程，黑白名單管理完全靜態(tài)等。雖然uReplicator針對MirrorMaker進行了大量優(yōu)化，但在我們的大量測試之后仍遇到眾多問題，我們需要具備動態(tài)管理MirrorMaker進程的能力，同時我們也不希望每次都重啟MirrorMaker進程。

數(shù)據(jù)存儲

為了應(yīng)對不同監(jiān)控指標(biāo)數(shù)據(jù)的存儲需求，我們主要使用了HBase、OpenTSDB、Elasticsearch等數(shù)據(jù)存儲框架。

數(shù)據(jù)存儲我們踩過了很多的坑，總結(jié)下來主要有以下幾點：

• 集群劃分：依據(jù)各產(chǎn)品線應(yīng)用的數(shù)據(jù)規(guī)模，合理劃分線上存儲資源，比如我們的ES集群是按照產(chǎn)品線、核心系統(tǒng)、數(shù)據(jù)大小等進行規(guī)劃切分;

• 性能優(yōu)化：Linux系統(tǒng)層優(yōu)化、TCP優(yōu)化、存儲參數(shù)優(yōu)化等;

• 數(shù)據(jù)操作：數(shù)據(jù)批量入庫(避免單條記錄保存)，例如針對HBase數(shù)據(jù)存儲可以通過在客戶端進行數(shù)據(jù)緩存、批量提交、避免客戶端同RegionServer頻繁建立連接(減少RPC請求次數(shù))

數(shù)據(jù)質(zhì)量

我們的系統(tǒng)在持續(xù)不斷地產(chǎn)生非常多的事件、服務(wù)間的鏈路消息和應(yīng)用日志，這些數(shù)據(jù)在得到處理之前需要經(jīng)過Kafka。那么，我們的平臺是如何實時地對這些數(shù)據(jù)進行審計呢?

為了監(jiān)控Kafka數(shù)據(jù)管道的健康狀況并對流經(jīng)Kafka的每個消息進行審計，我們調(diào)研并分析了Uber開源的審計系統(tǒng)Chaperone，在經(jīng)過各種測試之后，我們決定自研來實現(xiàn)需求，主要是因為我們希望具備任意節(jié)點任意代碼塊內(nèi)的數(shù)據(jù)審計需求，同時需要結(jié)合我們自己的數(shù)據(jù)管道特點，設(shè)計和實現(xiàn)達成一系列目標(biāo)：數(shù)據(jù)完整性與時延;數(shù)據(jù)質(zhì)量監(jiān)控需要近實時;數(shù)據(jù)產(chǎn)生問題時便于快速定位(提供診斷信息幫助解決問題);監(jiān)控與審計本身高度可信;監(jiān)控平臺服務(wù)高可用、超穩(wěn)定等;

為了滿足以上目標(biāo)，數(shù)據(jù)質(zhì)量審計系統(tǒng)的實現(xiàn)原理：把審計數(shù)據(jù)按照時間窗口聚合，統(tǒng)計一定時間段內(nèi)的數(shù)據(jù)量，并盡早準(zhǔn)確地檢測出數(shù)據(jù)的丟失、延遲和重復(fù)情況。同時有相應(yīng)的邏輯處理去重，晚到以及非順序到來的數(shù)據(jù)，同時做各種容錯處理保證高可用。

數(shù)據(jù)展示

為了實現(xiàn)監(jiān)控指標(biāo)的數(shù)據(jù)可視化，我們自研了前端數(shù)據(jù)可視化項目，同時我們也整合了外部第三方開源的數(shù)據(jù)可視化組件(grafana、kibana)，在整合的過程中我們遇到的問題：權(quán)限控制問題(內(nèi)部系統(tǒng)SSO整合)主要是通過自研的權(quán)限代理系統(tǒng)解決、去除kibana官方提供的相關(guān)插件、完善并自研了ES集群監(jiān)控插件等。

核心功能及落地實踐

系統(tǒng)監(jiān)控

我們的系統(tǒng)監(jiān)控主要使用了OpenTSDB作為數(shù)據(jù)存儲、Grafana作為數(shù)據(jù)展示，TSDB數(shù)據(jù)存儲層我們通過讀寫分離的方式減輕存儲層的壓力，TSDB同Grafana整合的過程中我們也遇到了數(shù)據(jù)分組展示的問題(海量指標(biāo)數(shù)據(jù)下查詢出分組字段值，通過建立獨立的指標(biāo)項進行數(shù)據(jù)查詢)，如下圖某機器系統(tǒng)監(jiān)控效果：

應(yīng)用監(jiān)控

針對各個Java應(yīng)用，我們提供了不同的監(jiān)控類型用于應(yīng)用內(nèi)指標(biāo)數(shù)據(jù)的度量。

業(yè)務(wù)監(jiān)控

針對業(yè)務(wù)監(jiān)控，我們可以通過編碼埋點、日志輸出、HTTP接口等不同的方式進行業(yè)務(wù)監(jiān)控指標(biāo)采集，同時支持多維度數(shù)據(jù)報表展示，如下圖所示：

我們的業(yè)務(wù)監(jiān)控通過自助化的方式讓各應(yīng)用方便捷的接入，如下圖監(jiān)控項定義：

日志搜索

為了支撐好研發(fā)人員線上排查故障，我們開發(fā)了統(tǒng)一日志搜索平臺，便于研發(fā)人員在海量日志中定位問題。

未來展望

隨著IT新興技術(shù)的迅猛發(fā)展，羅馬監(jiān)控體系未來的演進之路：

• 多語言支撐：滿足多語言的監(jiān)控需求(性能監(jiān)控、業(yè)務(wù)監(jiān)控、日志搜索等)

• 智能化監(jiān)控：提高報警及時性、準(zhǔn)確性等避免報警風(fēng)暴(ITOA、AIOps)

• 容器化監(jiān)控：隨著容器化技術(shù)的驗證落地實施，容器化監(jiān)控開啟布局;

總結(jié)

羅馬(Roma)是一個能夠?qū)?yīng)用進行深度監(jiān)控的全鏈路監(jiān)控平臺，主要涵蓋了應(yīng)用外、應(yīng)用內(nèi)、應(yīng)用間等不同維度的監(jiān)控目標(biāo)，例如應(yīng)用監(jiān)控、業(yè)務(wù)監(jiān)控、系統(tǒng)監(jiān)控、中間件監(jiān)控、統(tǒng)一日志搜索、調(diào)用鏈跟蹤等。能夠幫助開發(fā)者進行快速故障診斷、性能瓶頸定位、架構(gòu)梳理、依賴分析、容量評估等工作。

【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】