前言：
很開心能夠跟大家分享 WiFi 萬能鑰匙在監(jiān)控領(lǐng)域做的一些事情，本文分享的主題是《百萬訪問量的監(jiān)控平臺如何煉成》，羅馬（Roma）項目名稱的來歷比較有意義：
1、羅馬不是一天成煉的（線上監(jiān)控目標(biāo)相關(guān)指標(biāo)需要逐步完善）；
2、條條大路通羅馬（羅馬通過多種數(shù)據(jù)采集方式收集各監(jiān)控目標(biāo)的數(shù)據(jù)）；
3、據(jù)神話記載特洛伊之戰(zhàn)后部分特洛伊人的后代鑄造了古代羅馬帝國（一個故事的延續(xù)、一個新項目的誕生）。
今天我將通過三大部分進行講解：
- 背景介紹（我們公司當(dāng)初面臨的一些問題與挑戰(zhàn)）
- 架構(gòu)設(shè)計（結(jié)合公司現(xiàn)狀談一談我們的監(jiān)控平臺是如何實現(xiàn)）
- 最佳實踐（通過項目演示談一談我們的監(jiān)控平臺實踐情況）
一、 背景介紹
隨著 WiFi 萬能鑰匙日活躍用戶大規(guī)模的增長，鑰匙團隊正進行著一場無硝煙的戰(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è)務(wù)發(fā)展。
本文將介紹萬能鑰匙是如何構(gòu)建一站式、一體化的監(jiān)控平臺，從而實現(xiàn)提升故障發(fā)現(xiàn)率、縮短故障處理周期、減少用戶投訴率等目標(biāo)。
1、產(chǎn)品介紹
始于盛大創(chuàng)新院的 WiFi 萬能鑰匙在整個過去四年中，我們就是在致力于做一件事情“連接”，我們要幫助這些用戶更快更好更安全的連上網(wǎng)。
WiFi 萬能鑰匙從原來的幫助用戶連接上網(wǎng)，發(fā)展到現(xiàn)在，在幫助連接的同時我們希望做連接后所有的服務(wù)。我們向用戶推薦更精準(zhǔn)的內(nèi)容，我們讓用戶享受在他附近的生活中的各類便捷服務(wù)，同時讓用戶在上面消費更多的內(nèi)容。
2、產(chǎn)品數(shù)據(jù)
截至到2016年底，我們總用戶量已突破9億、月活躍達5.2億，用戶分布在全球223個國家和地區(qū)，在全球可連接熱點4億，日均連接次數(shù)超過40億次。
3、用戶體驗
我們可以通過一組數(shù)據(jù)（可用性指標(biāo)）來思考每一次故障的背后對用戶帶來了哪些傷害？給公司的品牌價值、股價等帶來哪些不利影響？
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)用鏈跟蹤等）
- 多實例支撐（滿足線上應(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 日志等集中化日志搜索與管控等）
- ……
5、監(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ī)劃等）
6、參考案例
一個完美的監(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)控實施困難。
羅馬（Roma）監(jiān)控體系如圖中所示，希望能夠汲取各方優(yōu)秀的架構(gòu)設(shè)計理念，融合不同的監(jiān)控維度實現(xiàn)監(jiān)控體系的“一體化”、“全鏈路”等。
二、 架構(gòu)設(shè)計
面對每天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è)計的角度逐一進行剖析。
1、架構(gòu)原理
一個完美的監(jiān)控平臺至少需要具備數(shù)據(jù)平臺的所有功能特性。
2、 架構(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)計等）
3、業(yè)務(wù)架構(gòu)
上圖是業(yè)務(wù)架構(gòu)圖，從最下側(cè)不同的指標(biāo)數(shù)據(jù)來源，到最上面包括圖表展示、配置管理等，最左側(cè)主要是做一些離線分析、實時分析等，最右側(cè)處理一些統(tǒng)計報表、周報等。
4、應(yīng)用架構(gòu)
羅馬架構(gòu)中各個組件的功能職責(zé)、用途說明如下：
5、技術(shù)架構(gòu)
羅馬整體架構(gòu)中數(shù)據(jù)流處理的不同階段主要使用到的技術(shù)棧如上圖所示。
6、配置下發(fā)
羅馬中 client->agent->server->master 四者之間通過 TCP 協(xié)議建立連接（短連接、長連接），當(dāng)用戶在前端 web 層進行配置變更時會觸發(fā)配置下發(fā)的動作（如：日志管理中新增應(yīng)用日志目錄、調(diào)度腳本執(zhí)行策略發(fā)生變更等）。
在整個架構(gòu)設(shè)計過程中需要支撐跨機房間的配置下發(fā)，由于機房間網(wǎng)絡(luò)的不穩(wěn)定，整個配置下發(fā)的過程需要支持推和拉兩種模式（用于處理配置下發(fā)過程中的各種錯誤場景）
7、數(shù)據(jù)采集
我們可以通過對各種不同的數(shù)據(jù)采集方式進行對比分析，除了以上圖中所示的對比分析的維度，還可以從人力投入成本（人數(shù)、時間等）進行分析，只有適合自己公司現(xiàn)狀的數(shù)據(jù)采集方式才是最適合的方案。
我們的應(yīng)用內(nèi)監(jiān)控主要是通過 client 客戶端與所在機器上的 agent 建立 TCP 長連接的方式進行數(shù)據(jù)采集，agent 同時也需要具備支持腳本調(diào)度的方式獲取系統(tǒng)（網(wǎng)絡(luò)或其它組件）的性能指標(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ù)。
8、數(shù)據(jù)傳輸
數(shù)據(jù)傳輸層主要使用 TLV 協(xié)議，支持二進制、JSON、XML 等多種類型。
9、數(shù)據(jù)同步
由于我們公司產(chǎn)品用戶形態(tài)分布于國內(nèi)外223個國家，海外運營商眾多，公網(wǎng)覆蓋質(zhì)量參差不齊，再加上運營商互聯(lián)策略的不同，付出的代價將是高時延、高丟包的網(wǎng)絡(luò)質(zhì)量，鑰匙產(chǎn)品走向海外過程中，我們會對整體網(wǎng)絡(luò)質(zhì)量情況有正確的評估跟預(yù)期。
比如對于海外機房內(nèi)的應(yīng)用進行監(jiān)控則需要對監(jiān)控指標(biāo)數(shù)據(jù)建立分級處理，對于實時、準(zhǔn)實時、離線等不同需求的指標(biāo)數(shù)據(jù)采集時進行歸類劃分（控制不同需求、不同數(shù)據(jù)規(guī)模等指標(biāo)數(shù)據(jù)進行采樣策略的調(diào)整）
羅馬監(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進程。
10、數(shù)據(jù)分析
在整個數(shù)據(jù)流處理過程中，我們面臨著很多實際的困難與挑戰(zhàn)，比如對于數(shù)據(jù)過期處理的策略、數(shù)據(jù)追蹤策略等都需要有對應(yīng)的處理方案。
11、數(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ù)等）
12、報警處理
目前我們的報警處理流程主要分為實時報警、離線報警（準(zhǔn)實時）、數(shù)據(jù)驅(qū)動、任務(wù)驅(qū)動（避免沒有指標(biāo)上報時數(shù)據(jù)陰跌等），對于所有的報警處理最終都會進行歸并與收斂動作（后續(xù)會逐步建設(shè)我們的智能化監(jiān)控系統(tǒng)，完善報警處理流程）
三、最佳實踐
1、 調(diào)用鏈跟蹤
如上圖所示，我們公司目前中間件領(lǐng)域的相關(guān)項目建設(shè)、調(diào)用鏈埋點信息及注意事項。
我們的調(diào)用鏈跟蹤系統(tǒng)主要參考了 Google Dapper 論文、阿里巴巴 EagleEye。如上圖所示，在調(diào)用鏈跟蹤埋點實現(xiàn)過程中，我們在處理上下文生成、異步調(diào)用等方面的解決方案。
如上圖所示，我們在寫日志處理、數(shù)據(jù)存儲、數(shù)據(jù)分析等方面遇到的問題與應(yīng)對方案。
2、功能演示
如上圖所示，我們的調(diào)用鏈跟蹤查詢頁面（可以根據(jù) TraceId 查詢整個調(diào)用鏈樹）
如上圖所示，這是我們的應(yīng)用監(jiān)控（JVM 相關(guān)指標(biāo)圖表展示效果）
如上圖所示，我們可以方便的跟蹤線上某應(yīng)用產(chǎn)生的各種異常堆棧信息。
如上圖所示，我們可以方便的跟蹤線上 URI 請求的相關(guān)指標(biāo)數(shù)據(jù)，點擊訪問總次數(shù)可以查看當(dāng)前查詢時段內(nèi)的圖表詳情（如下圖所示）
為了支撐好研發(fā)人員線上排查故障，我們開發(fā)了統(tǒng)一日志搜索平臺，便于研發(fā)人員在海量日志中定位問題。
如下圖所示：我們可以新增日志配置信息（應(yīng)用日志路徑、日志解析表達式等），該類信息會通過配置下發(fā)的功能下發(fā)至該應(yīng)用所在的 agent 機器（agent 會依據(jù)該配置信息進行日志相關(guān)的讀取與處理）
四、未來展望
隨著 IT 新興技術(shù)的迅猛發(fā)展，羅馬監(jiān)控體系未來的演進之路：
系統(tǒng)間融合：同公司內(nèi)部系統(tǒng)進行深度融合（項目管理平臺、項目發(fā)布平臺、性能測試平臺、問題跟蹤平臺等）
容器化監(jiān)控：容器使得微服務(wù)的運維變得高效和輕量，隨著公司內(nèi)部容器化技術(shù)的落地推廣實施，我們也將需要支撐容器化監(jiān)控方面的需求。
智能化監(jiān)控：提高報警及時性、準(zhǔn)確性等避免報警風(fēng)暴（AIOps）
總結(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)梳理、依賴分析、容量評估等工作。
核心關(guān)注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊涵了豐富的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.ezxoed.cn/
本文標(biāo)題：百億訪問量的監(jiān)控平臺如何煉成？
相關(guān)文章
