百億訪問量的監控平臺如何煉成？

天府雲創發表於2017-12-27

原文網址 : https://blog.csdn.net/enweitech/article/details/78909276

作者簡介：李春旭，2016年加入WiFi萬能鑰匙，現任WiFi萬能鑰匙高階架構師，十年網際網路研發經驗，喜歡折騰技術，曾供職於快錢、阿里巴巴、平安健康等公司，專注於以下領域：分散式監控平臺、呼叫鏈跟蹤平臺、統一日誌平臺、應用效能管理、穩定性保障體系建設等。

前言：

很開心能夠跟大家分享 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、應用架構

羅馬架構中各個元件的功能職責、用途說明如下：

元件名稱	功能用途	備註說明
roma-client	Java應用依賴客戶端、用於資料採集	實時採集、分鐘採集
roma-agent	資料通道、部署於各應用每臺物理機	資料通道、資料轉發
roma-transport	資料預處理、資料轉發、資料儲存	每機房獨立部署
roma-server	配置下發通道、心跳上報通道	每機房獨立部署
roma-master	叢集管理主節點、配置下發通道	僅部署於主機房
roma-analyser	資料實時分析、資料消費解析	每機房獨立部署
roma-replicator	多機房間資料同步、資料複製	僅部署於主機房
roma-storage	資料儲存（HBase、OpenTSDB等）	僅部署於主機房
roma-monitor	資料包警處理（閾值、趨勢、叢集等）	僅部署於主機房
roma-alarm	資料包警通知（簡訊、郵件、掌信等）	僅部署於主機房
roma-task	定時任務處理（狀態變更、資料清理）	僅部署於主機房
roma-web	資料視覺化（前端控制檯、管理後臺）	僅部署於主機房

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、報警處理