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