知識星球來自：51CTO技術棧（微訊號：blog51cto）
本文將分享我在實時監控領域的一些實戰經驗，介紹 WiFi 萬能鑰匙如何讓構建 APM 端到端的全鏈路監控平臺，實現提升故障發現率、縮短故障處理週期、減少使用者投訴率、樹立公司良好品牌形象等標的。
WiFi 萬能鑰匙開發運維團隊的困擾
始於盛大創新院的 WiFi 萬能鑰匙，截至到 2016 年底，我們總使用者量已突破 9 億、月活躍達 5.2 億，使用者分佈在全球 223 個國家和地區，在全球可連線熱點 4 億，日均連線次數超過 40 億次。
隨著日活躍使用者大規模的增長，WiFi 萬能鑰匙各產品線服務端團隊正進行著一場無硝煙的戰爭。越來越多的應用服務面臨著流量激增、架構擴充套件、效能瓶頸等問題。
為了應對並支撐業務的高速發展，我們邁入了 SOA、Microservice、API Gateway 等元件化及服務化的時代。
伴隨著各系統微服務化的演進，服務數量、機器規模不斷增長，線上環境也變得日益複雜，工程師們每天都會面臨著諸多苦惱。
例如：線上應用出現故障問題時無法第一時間感知；面對線上應用產生的海量日誌，排查故障問題時一籌莫展；應用系統內部及系統間的呼叫鏈路產生故障問題時難以定位等等。
綜上所述，線上應用的效能問題和異常錯誤已經成為困擾開發人員和運維人員最大的挑戰，而排查這類問題往往需要幾個小時甚至幾天的時間，嚴重影響了效率和業務發展。
WiFi 萬能鑰匙亟需完善監控體系，幫助開發運維人員擺脫煩惱，提升應用效能。
依據公司的產品形態及業務發展，我們發現監控體系需要解決一系列問題：
-
面對全球多地域海量使用者的 WiFi 連線請求，如何保障使用者連線體驗?
-
如何透過全鏈路監控提升使用者連線 WiFi 的成功率?
-
隨著微服務大規模推廣實施，WiFi 萬能鑰匙產品服務端系統越來越複雜，線上故障的發現、定位、處理難度也隨之增長，如何透過全鏈路監控提升故障處理速度?
-
移動出海已經進入深入化發展的下半場，全鏈路監控如何應對公司全球化的業務發展?
-
……
全鏈路監控
早期為了快速支撐業務發展，我們主要使用了開源的監控方案保障線上系統的穩定性：Cat、Zabbix。
隨著業務發展的需要，開源的解決方案已經不能滿足我們的業務需求，我們迫切需要構建一套滿足我們現狀的全鏈路監控體系：
-
多維度監控，系統監控、業務監控、應用監控、日誌搜尋、呼叫鏈跟蹤等。
-
多實體支撐，滿足線上應用在單臺物理機上部署多個應用實體場景需求等。
-
多語言支撐，滿足各團隊多開發語言場景的監控支撐，Go、C++、PHP 等。
-
多機房支撐，滿足國內外多個機房內應用的監控支撐，機房間資料同步等。
-
多渠道報警，滿足多渠道報警支撐、內部系統對接，郵件、掌信、簡訊等。
-
呼叫鏈跟蹤，滿足應用內、應用間呼叫鏈跟蹤需求，內部中介軟體升級改造等。
-
統一日誌搜尋，實現線上應用日誌、Nginx 日誌等集中化日誌搜尋與管控等。
-
……
監控標的
如上圖，從“應用”角度我們把監控體系劃分為三個層面：
-
應用外，主要是從應用所處的執行時環境進行監控，硬體、網路、作業系統等。
-
應用內，主要從使用者請求至應用內部的不同方面，JVM、URL、Method、SQL 等。
-
應用間，主要是從分散式呼叫鏈跟蹤的視角進行監控，依賴分析、容量規劃等。
羅馬監控體系的誕生
根據自身的實際需求，WiFi 萬能鑰匙研發團隊構建了羅馬(Roma)監控體系。
之所以將監控體繫命名為羅馬，原因在於：
-
羅馬不是一天煉成的，線上監控標的相關指標需要逐步完善。
-
條條大路通羅馬，羅馬透過多種資料採集方式收集各監控標的的資料。
-
據神話記載特洛伊之戰後部分特洛伊人的後代鑄造了古代羅馬帝國，一個故事的延續、一個新專案的誕生。
一個完美的監控體系會涵蓋 IT 領域內方方面面的監控標的，從目前國內外各網際網路公司的監控發展來看，很多公司把不同的監控標的劃分了不同的研發團隊進行處理。
但這樣做會帶來一些問題：人力資源浪費、系統重覆建設、資料資產不統一、全鏈路監控實施困難。
目前，各公司在監控領域採用的各解決方案，如下圖所示：
正如圖中所示，羅馬監控體系希望能夠汲取各方優秀的架構設計理念，融合不同的監控維度實現監控體系的“一體化”、“全鏈路”等。
高可用架構之道
面對每天 40 多億次的 WiFi 連線請求，每次請求都會經歷內部數十個微服務系統，每個微服務的監控維度又都會涉及應用外、應用內、應用間等多個監控指標。
目前，羅馬監控體系每天需要處理近千億次指標資料、近百 TB 日誌資料。面對海量的監控資料羅馬(Roma)如何應對處理？接下來，筆者帶大家從系統架構設計的角度逐一進行剖析。
架構原則
一個監控系統對於接入使用方應用而言，需要滿足如下圖中所示的五點：
-
效能影響，對業務系統的效能影響最小化，CPU、Load、Memory、IO 等。
-
低侵入性，方便業務系統接入使用，無需編碼或極少編碼即可實現系統接入。
-
無內部依賴，不依賴公司內部核心系統，避免被依賴系統故障導致相互依賴。
-
單元化部署，監控系統需要支撐單元化部署，支援多機房單元化部署。
-
資料集中化，監控資料集中化處理、分析、儲存等，便於資料統計等。
整體架構
Roma 系統架構如下圖所示：
Roma 架構中各個元件的功能職責、用途說明如下：
Roma 整體架構中劃分了不同的處理環節：資料採集、資料傳輸、資料同步、資料分析、資料儲存、資料質量、資料展示等，資料流處理的不同階段主要使用到的技術棧如下圖所示：
資料採集
對於應用內監控主要是透過 client 客戶端同所在機器上的 Agent 建立 TCP 長連線的方式處理，Agent 同時也需要具備透過指令碼排程的方式獲取系統效能指標資料。
面對海量的監控指標資料，羅馬監控透過在各層中預聚合的方式進行彙總計算。
比如在客戶端中相同 URL 請求的指標資料在一分鐘內彙總計算後統計結果為一條記錄(分鐘內相同請求進行累加計算，透過佔用極少記憶體、減少資料傳輸量)。
對於一個接入並使用羅馬的系統，完全可以根據其實體數、指標維度、採集頻率等進行監控資料規模的統計計算。
透過各層分級預聚合，減少了海量資料在網路中的資料傳輸，減少了資料儲存成本，節省了網路頻寬資源和磁碟儲存空間等。
應用內監控的實現原理(如下圖所示)：主要是透過客戶端採集，在應用內部的各個層面進行攔截統計： URL、Method、Exception、SQL 等不同維度的指標資料。
應用內監控各維度指標資料採集過程如下圖所示：針對不同的監控維度定義了不同的計數器，最終透過 JMX 規範進行資料採集。
資料傳輸
資料傳輸 TLV 協議，支援二進位制、JSON、XML 等多種型別。
每臺機器上都會部署 Agent(同客戶端建立 TCP 長連線)，Agent 的主要職責是資料轉發、資料採集(日誌檔案讀取、系統監控指標獲取等)。
Agent在獲取到效能指標資料後會傳送至 Kafka 叢集，在每個機房都會獨立部署 Kafka 叢集用於監控指標資料的傳送緩衝，便於後端的節點進行資料消費、資料儲存等。
為了實現資料的高效傳輸，我們對比分析了訊息處理的壓縮方式，最終選擇了高壓縮比的 GZIP 方式，主要是為了節省網路頻寬、避免由於監控的海量資料佔用機房內的網路頻寬。
針對各個節點間資料通訊的時序圖如下圖所示：建立連線->讀取配置->採集排程->上報資料等。
資料同步
海外運營商眾多，公網改寫質量參差不齊，再加上運營商互聯策略的不同，付出的代價將是高時延、高丟包的網路質量。
鑰匙產品走向海外過程中，首先會對整體網路質量情況有正確的預期，比如如果需要對於海外機房內的應用進行監控則依賴於在海外建立站點(主機房)、海外主站同國內主站進行互聯互通。
另外需要對監控指標資料分級處理，比如對於實時、準實時、離線等不同需求的指標資料採集時進行歸類劃分(控制不同需求、不同資料規模等指標資料進行取樣策略的調整)
由於各產品線應用部署在多個機房，為了滿足各個應用在多個機房內都可以被監控的需求，羅馬監控平臺需要支援多機房內應用監控的場景。
為了避免羅馬各元件在各個機房內重覆部署，同時便於監控指標資料的統一儲存、統一分析等，各個機房內的監控指標資料最終會同步至主機房內，最終在主機房內進行資料分析、資料儲存等。
為了實現多機房間資料同步，我們主要是利用 Kafka 跨資料中心部署的高可用方案，整體部署示意圖如下圖所示：
在對比分析了 MirrorMaker、uReplicator 後，我們決定基於 uReplicator 進行二次開發，主要是因為當 MirrorMaker 節點發生故障時，資料複製延遲較大，對於動態新增 topic 則需要重啟行程，黑白名單管理完全靜態等。
雖然 uReplicator 針對 MirrorMaker 進行了大量最佳化，但在我們的大量測試之後仍遇到眾多問題，我們需要具備動態管理 MirrorMaker 行程的能力，同時我們也不希望每次都重啟 MirrorMaker 行程。
資料儲存
為了應對不同監控指標資料的儲存需求，我們主要使用了 HBase、OpenTSDB、Elasticsearch 等資料儲存框架。
資料儲存我們踩過了很多的坑，總結下來主要有以下幾點：
-
叢集劃分，依據各產品線應用的資料規模，合理劃分線上儲存資源，比如我們的ES叢集是按照產品線、核心系統、資料大小等進行規劃切分。
-
效能最佳化，Linux 系統層最佳化、TCP 最佳化、儲存引數最佳化等。
-
資料操作，資料批次入庫(避免單條記錄儲存)，例如針對 HBase 資料儲存可以透過在客戶端進行資料快取、批次提交、避免客戶端同 RegionServer 頻繁建立連線，減少 RPC 請求次數。
資料質量
我們的系統在持續不斷地產生非常多的事件、服務間的鏈路訊息和應用日誌，這些資料在得到處理之前需要經過 Kafka。那麼，我們的平臺是如何實時地對這些資料進行審計呢?
為了監控 Kafka 資料管道的健康狀況並對流經 Kafka 的每個訊息進行審計，我們調研並分析了 Uber 開源的審計系統 Chaperone。
在經過各種測試之後，我們決定自研來實現需求，主要是因為我們希望具備任意節點任意程式碼塊內的資料審計需求。
同時需要結合我們自己的資料管道特點，設計和實現達成一系列標的：
-
資料完整性與時延。
-
資料質量監控需要近實時。
-
資料產生問題時便於快速定位，提供診斷資訊幫助解決問題。
-
監控與審計本身高度可信。
-
監控平臺服務高可用。
-
超穩定。
-
……
為了滿足以上標的，資料質量審計系統的實現原理：把審計資料按照時間視窗聚合，統計一定時間段內的資料量，並儘早準確地檢測出資料的丟失、延遲和重覆情況。
同時有相應的邏輯處理去重，晚到以及非順序到來的資料，同時做各種容錯處理保證高可用。
資料展示
為了實現監控指標的資料視覺化，我們自研了前端資料視覺化專案，同時我們也整合了外部第三方開源的資料視覺化元件(grafana、kibana)。
在整合的過程中我們遇到的問題：許可權控制問題(內部系統 SSO 整合)主要是透過自研的許可權代理系統解決、去除 kibana 官方提供的相關外掛、完善並自研了 ES 叢集監控外掛等。
核心功能及落地實踐
系統監控
我們的系統監控主要使用了 OpenTSDB 作為資料儲存、Grafana 作為資料展示，TSDB 資料儲存層我們透過讀寫分離的方式減輕儲存層的壓力。
TSDB 同 Grafana 整合的過程中，我們也遇到了資料分組展示的問題(海量指標資料下查詢出分組欄位值，透過建立獨立的指標項進行資料查詢)，如下圖某機器系統監控效果：
應用監控
針對各個 Java 應用，我們提供了不同的監控型別用於應用內指標資料的度量。
業務監控
針對業務監控，我們可以透過編碼埋點、日誌輸出、HTTP 介面等不同的方式進行業務監控指標採集，同時支援多維度資料報表展示，如下圖所示：
我們的業務監控透過自助化的方式讓各應用方便快捷的接入，如下圖監控項定義：
日誌搜尋
為了支撐好研發人員線上排查故障，我們開發了統一日誌搜尋平臺，便於研發人員在海量日誌中定位問題。
未來展望
隨著 IT 新興技術的迅猛發展，羅馬監控體系未來的演進之路：
-
多語言支撐，滿足多語言的監控需求，效能監控、業務監控、日誌搜尋等。
-
智慧化監控，提高報警及時性、準確性等避免報警風暴，ITOA、AIOps。
-
容器化監控，隨著容器化技術的驗證落地實施，容器化監控開啟佈局。
總結
羅馬(Roma)是一個能夠對應用進行深度監控的全鏈路監控平臺，主要涵蓋了應用外、應用內、應用間等不同維度的監控標的，例如應用監控、業務監控、系統監控、中介軟體監控、統一日誌搜尋、呼叫鏈跟蹤等。
它能夠幫助開發者進行快速故障診斷、效能瓶頸定位、架構梳理、依賴分析、容量評估等工作。
作者：李春旭
李春旭，2016 年加入 WiFi 萬能鑰匙，現任 WiFi 萬能鑰匙高階架構師，十年網際網路研發經驗，喜歡折騰技術，曾供職於快錢、阿裡巴巴、平安健康等公司，專註於以下領域：分散式監控平臺、呼叫鏈跟蹤平臺、統一日誌平臺、應用效能管理、穩定性保障體系建設等。
●本文編號147，以後想閱讀這篇文章直接輸入147即可
●輸入m獲取文章目錄
Linux學習
更多推薦《18個技術類微信公眾號》
涵蓋：程式人生、演演算法與資料結構、駭客技術與網路安全、大資料技術、前端開發、Java、Python、Web開發、安卓開發、iOS開發、C/C++、.NET、Linux、資料庫、運維等。
