前言：
很開心能夠跟大家分享 WiFi 萬能鑰匙在監(jiān)控領(lǐng)域做的一些事情，本文分享的主題是《百萬訪問量的監(jiān)控平臺(tái)如何煉成》，羅馬（Roma）項(xiàng)目名稱的來歷比較有意義：
1、羅馬不是一天成煉的（線上監(jiān)控目標(biāo)相關(guān)指標(biāo)需要逐步完善）；
2、條條大路通羅馬（羅馬通過多種數(shù)據(jù)采集方式收集各監(jiān)控目標(biāo)的數(shù)據(jù)）；
3、據(jù)神話記載特洛伊之戰(zhàn)后部分特洛伊人的后代鑄造了古代羅馬帝國（一個(gè)故事的延續(xù)、一個(gè)新項(xiàng)目的誕生）。
今天我將通過三大部分進(jìn)行講解：
- 背景介紹（我們公司當(dāng)初面臨的一些問題與挑戰(zhàn)）
- 架構(gòu)設(shè)計(jì)（結(jié)合公司現(xiàn)狀談一談我們的監(jiān)控平臺(tái)是如何實(shí)現(xiàn)）
- 最佳實(shí)踐（通過項(xiàng)目演示談一談我們的監(jiān)控平臺(tái)實(shí)踐情況）
一、 背景介紹
隨著 WiFi 萬能鑰匙日活躍用戶大規(guī)模的增長，鑰匙團(tuán)隊(duì)正進(jìn)行著一場無硝煙的戰(zhàn)爭：越來越多的應(yīng)用服務(wù)面臨著流量激增、架構(gòu)擴(kuò)展、性能瓶頸等問題，為了應(yīng)對并支撐業(yè)務(wù)的高速發(fā)展，我們邁入了 SOA、Microservice、API Gateway 等組件化及服務(wù)化的時(shí)代。
伴隨著各系統(tǒng)微服務(wù)化的演進(jìn)，服務(wù)數(shù)量、機(jī)器規(guī)模不斷增長，線上環(huán)境也變得日益復(fù)雜，工程師們每天都會(huì)面臨著這些苦惱：
- 線上應(yīng)用出現(xiàn)故障問題時(shí)無法第一時(shí)間感知；
- 面對線上應(yīng)用產(chǎn)生的海量日志，排查故障問題時(shí)一籌莫展；
- 應(yīng)用系統(tǒng)內(nèi)部及系統(tǒng)間的調(diào)用鏈路產(chǎn)生故障問題時(shí)難以定位；
- ……
線上應(yīng)用的性能問題和異常錯(cuò)誤已經(jīng)成為困擾開發(fā)人員和運(yùn)維人員最大的挑戰(zhàn)，而排查這類問題往往需要幾個(gè)小時(shí)甚至幾天的時(shí)間，嚴(yán)重影響了效率和業(yè)務(wù)發(fā)展。
本文將介紹萬能鑰匙是如何構(gòu)建一站式、一體化的監(jiān)控平臺(tái)，從而實(shí)現(xiàn)提升故障發(fā)現(xiàn)率、縮短故障處理周期、減少用戶投訴率等目標(biāo)。
1、產(chǎn)品介紹
始于盛大創(chuàng)新院的 WiFi 萬能鑰匙在整個(gè)過去四年中，我們就是在致力于做一件事情“連接”，我們要幫助這些用戶更快更好更安全的連上網(wǎng)。
WiFi 萬能鑰匙從原來的幫助用戶連接上網(wǎng)，發(fā)展到現(xiàn)在，在幫助連接的同時(shí)我們希望做連接后所有的服務(wù)。我們向用戶推薦更精準(zhǔn)的內(nèi)容，我們讓用戶享受在他附近的生活中的各類便捷服務(wù)，同時(shí)讓用戶在上面消費(fèi)更多的內(nèi)容。
2、產(chǎn)品數(shù)據(jù)
截至到2016年底，我們總用戶量已突破9億、月活躍達(dá)5.2億，用戶分布在全球223個(gè)國家和地區(qū)，在全球可連接熱點(diǎn)4億，日均連接次數(shù)超過40億次。
3、用戶體驗(yàn)
我們可以通過一組數(shù)據(jù)（可用性指標(biāo)）來思考每一次故障的背后對用戶帶來了哪些傷害？給公司的品牌價(jià)值、股價(jià)等帶來哪些不利影響？
4、監(jiān)控現(xiàn)狀
早期為了快速支撐業(yè)務(wù)發(fā)展，我們主要使用了開源的監(jiān)控方案保障線上系統(tǒng)的穩(wěn)定性：某開源監(jiān)控框架、Zabbix，隨著各產(chǎn)品線業(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)用鏈跟蹤等）
- 多實(shí)例支撐（滿足線上應(yīng)用在單臺(tái)物理機(jī)上部署多個(gè)應(yīng)用實(shí)例場景需求等）
- 多語言支撐（滿足各團(tuán)隊(duì)多開發(fā)語言場景的監(jiān)控支撐，Go、C++、PHP 等）
- 多機(jī)房支撐（滿足國內(nèi)外多個(gè)機(jī)房內(nèi)應(yīng)用的監(jiān)控支撐，機(jī)房間數(shù)據(jù)同步等）
- 多渠道報(bào)警（滿足多渠道報(bào)警支撐、內(nèi)部系統(tǒng)對接，郵件、掌信、短信等）
- 調(diào)用鏈跟蹤（滿足應(yīng)用內(nèi)、應(yīng)用間調(diào)用鏈跟蹤需求，內(nèi)部中間件升級改造等）
- 統(tǒng)一日志搜索（實(shí)現(xiàn)線上應(yīng)用日志、Nginx 日志等集中化日志搜索與管控等）
- ……
5、監(jiān)控目標(biāo)
如圖所示，從“應(yīng)用”角度我們把監(jiān)控體系劃分為：應(yīng)用外、應(yīng)用內(nèi)、應(yīng)用間。
應(yīng)用外：主要是從應(yīng)用所處的運(yùn)行時(shí)環(huán)境進(jìn)行監(jiān)控（硬件、網(wǎng)絡(luò)、操作系統(tǒng)等）
應(yīng)用內(nèi)：主要從用戶請求至應(yīng)用內(nèi)部的不同方面（JVM、URL、Method、SQL 等）
應(yīng)用間：主要是從分布式調(diào)用鏈跟蹤的視角進(jìn)行監(jiān)控（依賴分析、容量規(guī)劃等）
6、參考案例
一個(gè)完美的監(jiān)控體系會(huì)涵蓋 IT 領(lǐng)域內(nèi)方方面面的監(jiān)控目標(biāo)，從目前國內(nèi)外各互聯(lián)網(wǎng)公司的監(jiān)控發(fā)展來看，很多公司把不同的監(jiān)控目標(biāo)劃分了不同的研發(fā)團(tuán)隊(duì)進(jìn)行處理，但這樣的會(huì)帶來一些問題：人力資源浪費(fèi)、系統(tǒng)重復(fù)建設(shè)、數(shù)據(jù)資產(chǎn)不統(tǒng)一、全鏈路監(jiān)控實(shí)施困難。
羅馬（Roma）監(jiān)控體系如圖中所示，希望能夠汲取各方優(yōu)秀的架構(gòu)設(shè)計(jì)理念，融合不同的監(jiān)控維度實(shí)現(xiàn)監(jiān)控體系的“一體化”、“全鏈路”等。
二、 架構(gòu)設(shè)計(jì)
面對每天40多億次的 WiFi 連接請求，每次請求都會(huì)經(jīng)歷內(nèi)部數(shù)十個(gè)微服務(wù)系統(tǒng)，每個(gè)微服務(wù)的監(jiān)控維度又都會(huì)涉及應(yīng)用外、應(yīng)用內(nèi)、應(yīng)用間等多個(gè)監(jiān)控指標(biāo)，目前羅馬監(jiān)控體系每天需要處理近千億次指標(biāo)數(shù)據(jù)、近百 TB 日志數(shù)據(jù)。面對海量的監(jiān)控?cái)?shù)據(jù)羅馬（Roma）如何應(yīng)對處理？接下來將從系統(tǒng)架構(gòu)設(shè)計(jì)的角度逐一進(jìn)行剖析。
1、架構(gòu)原理
一個(gè)完美的監(jiān)控平臺(tái)至少需要具備數(shù)據(jù)平臺(tái)的所有功能特性。
2、 架構(gòu)原則
一個(gè)監(jiān)控系統(tǒng)對于接入使用方應(yīng)用而言，需要滿足如下圖中所示的五點(diǎn)：
- 性能影響：對業(yè)務(wù)系統(tǒng)的性能影響最小化（CPU、LOAd、Memory、IO 等）
- 低侵入性：方便業(yè)務(wù)系統(tǒng)接入使用（無需編碼或極少編碼即可實(shí)現(xiàn)系統(tǒng)接入）
- 無內(nèi)部依賴：不依賴公司內(nèi)部核心系統(tǒng)（避免被依賴系統(tǒng)故障導(dǎo)致相互依賴）
- 單元化部署：監(jiān)控系統(tǒng)需要支撐單元化部署（支持多機(jī)房單元化部署）
- 數(shù)據(jù)集中化：監(jiān)控?cái)?shù)據(jù)集中化處理、分析、存儲(chǔ)等（便于數(shù)據(jù)統(tǒng)計(jì)等）
3、業(yè)務(wù)架構(gòu)
上圖是業(yè)務(wù)架構(gòu)圖，從最下側(cè)不同的指標(biāo)數(shù)據(jù)來源，到最上面包括圖表展示、配置管理等，最左側(cè)主要是做一些離線分析、實(shí)時(shí)分析等，最右側(cè)處理一些統(tǒng)計(jì)報(bào)表、周報(bào)等。
4、應(yīng)用架構(gòu)
羅馬架構(gòu)中各個(gè)組件的功能職責(zé)、用途說明如下：
5、技術(shù)架構(gòu)
羅馬整體架構(gòu)中數(shù)據(jù)流處理的不同階段主要使用到的技術(shù)棧如上圖所示。
6、配置下發(fā)
羅馬中 client->agent->server->master 四者之間通過 TCP 協(xié)議建立連接（短連接、長連接），當(dāng)用戶在前端 web 層進(jìn)行配置變更時(shí)會(huì)觸發(fā)配置下發(fā)的動(dòng)作（如：日志管理中新增應(yīng)用日志目錄、調(diào)度腳本執(zhí)行策略發(fā)生變更等）。
在整個(gè)架構(gòu)設(shè)計(jì)過程中需要支撐跨機(jī)房間的配置下發(fā)，由于機(jī)房間網(wǎng)絡(luò)的不穩(wěn)定，整個(gè)配置下發(fā)的過程需要支持推和拉兩種模式（用于處理配置下發(fā)過程中的各種錯(cuò)誤場景）
7、數(shù)據(jù)采集
我們可以通過對各種不同的數(shù)據(jù)采集方式進(jìn)行對比分析，除了以上圖中所示的對比分析的維度，還可以從人力投入成本（人數(shù)、時(shí)間等）進(jìn)行分析，只有適合自己公司現(xiàn)狀的數(shù)據(jù)采集方式才是最適合的方案。
我們的應(yīng)用內(nèi)監(jiān)控主要是通過 client 客戶端與所在機(jī)器上的 agent 建立 TCP 長連接的方式進(jìn)行數(shù)據(jù)采集，agent 同時(shí)也需要具備支持腳本調(diào)度的方式獲取系統(tǒng)（網(wǎng)絡(luò)或其它組件）的性能指標(biāo)數(shù)據(jù)。
面對海量的監(jiān)控指標(biāo)數(shù)據(jù)，羅馬監(jiān)控通過在各層中預(yù)聚合的方式進(jìn)行匯總計(jì)算，比如在客戶端中相同 URL 請求的指標(biāo)數(shù)據(jù)在一分鐘內(nèi)匯總計(jì)算后統(tǒng)計(jì)結(jié)果為一條記錄（分鐘內(nèi)相同請求進(jìn)行累加計(jì)算，通過占用極少內(nèi)存、減少數(shù)據(jù)傳輸量）。
對于一個(gè)接入并使用羅馬的系統(tǒng)，完全可以根據(jù)其實(shí)例數(shù)、指標(biāo)維度、采集頻率等進(jìn)行監(jiān)控?cái)?shù)據(jù)規(guī)模的統(tǒng)計(jì)計(jì)算。通過各層分級預(yù)聚合，減少了海量數(shù)據(jù)在網(wǎng)絡(luò)中的數(shù)據(jù)傳輸，減少了數(shù)據(jù)存儲(chǔ)成本，節(jié)省了網(wǎng)絡(luò)帶寬資源和磁盤存儲(chǔ)空間等。
應(yīng)用內(nèi)監(jiān)控的實(shí)現(xiàn)原理（如上圖所示）：主要是通過客戶端采集，在應(yīng)用內(nèi)部的各個(gè)層面進(jìn)行攔截統(tǒng)計(jì)： URL、Method、Exception、SQL 等不同維度的指標(biāo)數(shù)據(jù)。
8、數(shù)據(jù)傳輸
數(shù)據(jù)傳輸層主要使用 TLV 協(xié)議，支持二進(jìn)制、JSON、XML 等多種類型。
9、數(shù)據(jù)同步
由于我們公司產(chǎn)品用戶形態(tài)分布于國內(nèi)外223個(gè)國家，海外運(yùn)營商眾多，公網(wǎng)覆蓋質(zhì)量參差不齊，再加上運(yùn)營商互聯(lián)策略的不同，付出的代價(jià)將是高時(shí)延、高丟包的網(wǎng)絡(luò)質(zhì)量，鑰匙產(chǎn)品走向海外過程中，我們會(huì)對整體網(wǎng)絡(luò)質(zhì)量情況有正確的評估跟預(yù)期。
比如對于海外機(jī)房內(nèi)的應(yīng)用進(jìn)行監(jiān)控則需要對監(jiān)控指標(biāo)數(shù)據(jù)建立分級處理，對于實(shí)時(shí)、準(zhǔn)實(shí)時(shí)、離線等不同需求的指標(biāo)數(shù)據(jù)采集時(shí)進(jìn)行歸類劃分（控制不同需求、不同數(shù)據(jù)規(guī)模等指標(biāo)數(shù)據(jù)進(jìn)行采樣策略的調(diào)整）
羅馬監(jiān)控平臺(tái)支持多機(jī)房內(nèi)應(yīng)用監(jiān)控的場景，為了避免羅馬各組件在各個(gè)機(jī)房內(nèi)重復(fù)部署，同時(shí)便于監(jiān)控指標(biāo)數(shù)據(jù)的統(tǒng)一存儲(chǔ)、統(tǒng)一分析等，各個(gè)機(jī)房內(nèi)的監(jiān)控指標(biāo)數(shù)據(jù)最終會(huì)同步至主機(jī)房內(nèi)，最終在主機(jī)房內(nèi)進(jìn)行數(shù)據(jù)分析、數(shù)據(jù)存儲(chǔ)等。
為了實(shí)現(xiàn)多機(jī)房間數(shù)據(jù)同步，我們主要是利用 kafka 跨數(shù)據(jù)中心部署的高可用方案，在對比分析了 MirrorMaker、uReplicator 后，我們決定基于 uReplicator 進(jìn)行二次開發(fā)，主要是因?yàn)楫?dāng) MirrorMaker 節(jié)點(diǎn)發(fā)生故障時(shí)，數(shù)據(jù)復(fù)制延遲較大，對于動(dòng)態(tài)添加 topic 則需要重啟進(jìn)程、黑白名單管理完全靜態(tài)等。
雖然 uReplicator 針對 MirrorMaker 進(jìn)行了大量優(yōu)化，但在我們的大量測試之后仍遇到眾多問題，我們需要具備動(dòng)態(tài)管理 MirrorMaker 進(jìn)程的能力，同時(shí)我們也不希望每次都重啟 MirrorMaker進(jìn)程。
10、數(shù)據(jù)分析
在整個(gè)數(shù)據(jù)流處理過程中，我們面臨著很多實(shí)際的困難與挑戰(zhàn)，比如對于數(shù)據(jù)過期處理的策略、數(shù)據(jù)追蹤策略等都需要有對應(yīng)的處理方案。
11、數(shù)據(jù)存儲(chǔ)
為了應(yīng)對不同監(jiān)控指標(biāo)數(shù)據(jù)的存儲(chǔ)需求，我們主要使用了 HBase、OpenTSDB、Elasticsearch 等數(shù)據(jù)存儲(chǔ)框架。
數(shù)據(jù)存儲(chǔ)層我們踩過了很多的坑，總結(jié)下來主要有以下幾點(diǎn)：
- 集群劃分：依據(jù)各產(chǎn)品線應(yīng)用的數(shù)據(jù)規(guī)模，合理劃分線上存儲(chǔ)資源，比如我們的 ES 集群是按照產(chǎn)品線、核心系統(tǒng)、數(shù)據(jù)大小等進(jìn)行規(guī)劃切分；
- 性能優(yōu)化：Linux 系統(tǒng)層優(yōu)化、TCP 優(yōu)化、存儲(chǔ)參數(shù)優(yōu)化等；
- 數(shù)據(jù)操作：數(shù)據(jù)批量入庫（避免單條記錄保存），例如針對 HBase 數(shù)據(jù)存儲(chǔ)可以通過在客戶端進(jìn)行數(shù)據(jù)緩存、批量提交、避免客戶端同 RegionServer 頻繁建立連接（減少 RPC 請求次數(shù)等）
12、報(bào)警處理
目前我們的報(bào)警處理流程主要分為實(shí)時(shí)報(bào)警、離線報(bào)警（準(zhǔn)實(shí)時(shí)）、數(shù)據(jù)驅(qū)動(dòng)、任務(wù)驅(qū)動(dòng)（避免沒有指標(biāo)上報(bào)時(shí)數(shù)據(jù)陰跌等），對于所有的報(bào)警處理最終都會(huì)進(jìn)行歸并與收斂動(dòng)作（后續(xù)會(huì)逐步建設(shè)我們的智能化監(jiān)控系統(tǒng)，完善報(bào)警處理流程）
三、最佳實(shí)踐
1、 調(diào)用鏈跟蹤
如上圖所示，我們公司目前中間件領(lǐng)域的相關(guān)項(xiàng)目建設(shè)、調(diào)用鏈埋點(diǎn)信息及注意事項(xiàng)。
我們的調(diào)用鏈跟蹤系統(tǒng)主要參考了 Google Dapper 論文、阿里巴巴 EagleEye。如上圖所示，在調(diào)用鏈跟蹤埋點(diǎn)實(shí)現(xiàn)過程中，我們在處理上下文生成、異步調(diào)用等方面的解決方案。
如上圖所示，我們在寫日志處理、數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)分析等方面遇到的問題與應(yīng)對方案。
2、功能演示
如上圖所示，我們的調(diào)用鏈跟蹤查詢頁面（可以根據(jù) TraceId 查詢整個(gè)調(diào)用鏈樹）
如上圖所示，這是我們的應(yīng)用監(jiān)控（JVM 相關(guān)指標(biāo)圖表展示效果）
如上圖所示，我們可以方便的跟蹤線上某應(yīng)用產(chǎn)生的各種異常堆棧信息。
如上圖所示，我們可以方便的跟蹤線上 URI 請求的相關(guān)指標(biāo)數(shù)據(jù)，點(diǎn)擊訪問總次數(shù)可以查看當(dāng)前查詢時(shí)段內(nèi)的圖表詳情（如下圖所示）
為了支撐好研發(fā)人員線上排查故障，我們開發(fā)了統(tǒng)一日志搜索平臺(tái)，便于研發(fā)人員在海量日志中定位問題。
如下圖所示：我們可以新增日志配置信息（應(yīng)用日志路徑、日志解析表達(dá)式等），該類信息會(huì)通過配置下發(fā)的功能下發(fā)至該應(yīng)用所在的 agent 機(jī)器（agent 會(huì)依據(jù)該配置信息進(jìn)行日志相關(guān)的讀取與處理）
四、未來展望
隨著 IT 新興技術(shù)的迅猛發(fā)展，羅馬監(jiān)控體系未來的演進(jìn)之路：
系統(tǒng)間融合：同公司內(nèi)部系統(tǒng)進(jìn)行深度融合（項(xiàng)目管理平臺(tái)、項(xiàng)目發(fā)布平臺(tái)、性能測試平臺(tái)、問題跟蹤平臺(tái)等）
容器化監(jiān)控：容器使得微服務(wù)的運(yùn)維變得高效和輕量，隨著公司內(nèi)部容器化技術(shù)的落地推廣實(shí)施，我們也將需要支撐容器化監(jiān)控方面的需求。
智能化監(jiān)控：提高報(bào)警及時(shí)性、準(zhǔn)確性等避免報(bào)警風(fēng)暴（AIOps）
總結(jié)
羅馬（Roma）是一個(gè)能夠?qū)?yīng)用進(jìn)行深度監(jiān)控的全鏈路監(jiān)控平臺(tái)，主要涵蓋了應(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ā)者進(jìn)行快速故障診斷、性能瓶頸定位、架構(gòu)梳理、依賴分析、容量評估等工作。
核心關(guān)注：拓步ERP系統(tǒng)平臺(tái)是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊(yùn)涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。
轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://www.oesoe.com/
本文標(biāo)題：百億訪問量的監(jiān)控平臺(tái)如何煉成？
相關(guān)文章
