張愛華 白金峰



關鍵詞:分布式系統;鏈路監控;OpenTelemetry;Jaeger
中圖分類號:TP391 文獻標志碼:A
0 引言(Introduction)
隨著互聯網移動應用的興起,一種新的計算機應用系統服務架構-分布式架構應運而生。但是,隨著分布式架構方案的使用越來越多,該架構的缺點慢慢顯現出來,首當其沖的就是調用鏈路的問題[1]。隨著分布式系統中服務數量的增加,其相互調用的關系網絡也變得錯綜復雜,無論是系統的開發人員,還是維護人員,都因為無法追蹤一個請求的調用鏈路而犯難。
本文針對這一情況,提供了一種通用的調用鏈路監控方案,細化每一個服務接口的粒度。在本方案中,既可以通過可視化界面的方式查詢應用接口的調用流程、錯誤率、負載強度,又可以通過圖示的方式查看系統的調用結構。
通過使用本文中提供的監控方案,系統開發人員可以快速追蹤系統中任意服務的調用步驟、執行的命令或者參數,方便快速排查問題;運維人員可以實時查看系統中每一個服務接口的負載壓力與錯誤率,可以提前預判服務狀態。
1 系統需求(System requirements)
分布式鏈路監控系統的主要用戶為系統的開發人員和維護人員。圖1為系統開發人員的需求。系統開發人員希望使用該系統查看應用的調用鏈路、接口耗時、調用步驟中的應用信息、參數、環境信息等,還需要查看系統的整體調用網絡。
2 系統設計(System design)
2.1 技術路線
系統服務端采用B/S架構,前端和后端基于HTTP協議進行通信,數據格式使用JSON。前端使用的是NodeJS+React技術,通過NodeJS查詢Server端數據,然后結合React構造的模塊化頁面展示實現動態響應。
系統后端使用的是Golang語言,該語言自身的協程設計使其非常適合應用在處理高并發請求環境中,并且構建后的可執行產物體積小、啟動方便。
服務埋點以Java應用為例,使用的是Java語言本身支持的JavaAgent方案,通過JavaAgent掛載到應用本身的Java虛擬機(Java Virtual Machine,JVM)中。該方案對應用本身沒有任何的代碼侵入,業務應用不需要任何改造即可輕松集成Agent。
ElasticSearch是一款分布式的搜索和分析引擎,該引擎可以使鏈路監控的數據搜集部分與展示部分解耦[1]。Agent在應用層面搜集到的應用運行數據和日志等信息上報給ElasticSearch引擎,引擎對數據進行存儲和索引,頁面展示部分從ElasticSearch中讀取并分析數據,然后展示到頁面上。
OpenTelemetry Collector是一款設備無關性的新興采集器。在以往的分布式系統度量數據采集方案中使用的采集器一般與技術棧綁定,一旦選擇了某個技術棧中的一個工具,則后續拓展必須使用該技術棧下的其他工具。例如,在搜集應用日志時,一旦選擇了使用filebeat,則后續的日志存儲只能選擇ElasticSearch,日志展示與分析也只能選擇Kibana。OpenTelemetry Collector的出現打破了這一局限性,它支持從多個輸入端采集數據,然后通過自定義的Processor處理,處理后又可以從多個輸出端輸出數據,方便隨時替換度量數據的搜集器和分析器。
Jaeger是一款新型的鏈路分析工具,它包含Agent、Analyzer、QueryUI等組件。本文使用Jaeger的Analyzer和QueryUI組件,其中Analyzer用來分析鏈路數據和服務的網絡結構,QueryUI用來查詢和展示分析后的鏈路和調用網絡。
Prometheus是一款存儲應用度量數據的工具,它提供了一種基于時間軸的新型數據存儲和管理方案,可以很好地記錄某一指標隨著時間變化而變化的值[2];同時,它還提供一套類似于結構化查詢語言(Structured Query Language,SQL),通過使用其提供的查詢語言可以方便地從各個維度查詢度量數據。
2.2 系統架構
2.2.1 整體架構
系統的整體架構如圖 3所示,系統中存在多個業務應用(Business Application),并且每一個業務應用都掛載了一個Agent用來收集應用的度量數據和運行時的狀態數據[3]。Agent收集數據后會發送給OpenTelemetry Collector,Collector對數據進行處理后,根據不同的數據類型分別發送給Jaeger Collector 搜集器和Prometheus 數據庫。JaegerCollector對數據做篩選,加標簽處理后存入ElasticSearch中等待分析和展示,ElasticSearch中的數據會定時由Spark Job獲取并計算調用網絡,計算后的結果會再次存儲至ElasticSearch中。Jaeger Query 服務負責根據用戶的需求將數據從ElasticSearch和Prometheus中取出并通過用戶界面(UserInterface,UI)進行相應的展示。
2.2.2 高可用節點集群方案
為保證系統處于高可用狀態(如圖 4所示),系統中的OpenTelemetry Collector、Jaeger Collector和Jaeger Query等組件都可以使用集群化部署,根據系統壓力進行水平擴容[4]。
同時,開源組件ElasticSearch和Prometheus也支持高可用的集群化部署,多節點通過訪問單一存儲系統實現數據一致性,開源組件高可用方案如圖 5所示[5]。
3 系統實現(System implementation)
3.1 節點分配
如表1所示,搭建一個最小集群共需要6臺機器,可以選擇在虛擬機中創建這些機器并分配為固定IP。其中,用來部署ElasticSearch的機器需要分配足夠的內存(建議不小于8 GB)和存儲(不小于50 GB);用來部署Prometheus的機器需要分配足夠的存儲(不小于50 GB);用來部署Collector的兩臺機器需要分配足夠的CPU(不小于雙核),以滿足運算需要。
3.2 應用的配置與部署
由于開源組件ElasticSearch和Prometheus的部署方案在官網或者網絡上有很多相關資料,故在此不做贅述。OpenTelemetry Collector的部署重點是配置文件的編寫,需要配置Collector的輸入監聽、數據處理器和輸出監聽。輸入監聽使用的是Jaeger格式數據的監聽方案,數據處理器使用SpanMetrics方案將度量數據與鏈路數據進行拆分,輸出監聽分別需要Prometheus 和Jaeger Collector。配置文件的具體內容如圖 6所示。
Jaeger Collector可以使用官網上的二進制文件,然后通過命令行參數的方式直接啟動該應用即可,主要的命令行參數包括指定存儲類型、索引前綴名稱等。將下載好的二進制文件放在/opt/app/jaeger/jaeger-collector中,則可以使用圖7中的命令啟動Jaeger Collector。Jaeger Query 和Jaeger UI的啟動方式與Jaeger Collector的啟動方案類似,這里不再贅述。
3.3 業務服務Agent配置
以Java應用為例,使用Java Agent的方案進行配置[6]。該方案需要準備收集數據的Agent.jar和應用相關的參數配置文件,應用配置文件內容詳解如圖 8所示。
更新參數配置文件后,需要對業務服務的啟動命令進行改造,將agent和agent使用的應用參數配置文件加入啟動命令中,應用啟動參數的修改如圖 9所示。
4 系統測試(System testing)
4.1 服務應用Agent測試
系統采用的是Agent掛載到業務應用上的啟動方案,所以對Agent的測試可通過應用打印的啟動日志進行查看[7]。在應用啟動的過程中,可以通過觀察應用的輸出日志判斷Agent是否成功掛載到應用上。經測試,Agent已經成功掛載到應用上。
4.2 鏈路監控系統測試
對鏈路監控系統的測試,可以通過訪問應用接口和提升應用接口壓力的方案實現。通過訪問業務應用的接口,然后在本系統中查看追蹤到的鏈路即可確認鏈路上報與監控功能是否可用[8]。經測試,系統的鏈路監控功能可用,鏈路監控頁面測試結果如圖10所示。
4.3 指標展示測試
對系統的指標展示的測試,可以通過給指定應用增加訪問壓力迫使指標數據出現波動的方案實現。經測試,系統指標展示功能可用。系統指標數據頁面測試結果如圖11所示。
4.4 其他測試
除了上述幾項重要功能測試,本文還對系統的其他分支功能如鏈路步驟查詢、鏈路標簽查詢、鏈路中某一步驟參數與結果分析、鏈路對比、服務網絡分析等進行測試,測試結果均正常,各項功能均可用。
4.5 測試結果總結
系統共設計了功能性測試用例共35個,執行成功35個;設計了非功能性測試12個,成功執行了12個;設計了性能測試共3項,在單節點狀態下,服務接口成功率達99.97%,系統資源占用穩定,沒有內存泄漏和CPU占用率過高的情況。
5 結論(Conclusion)
本文提出的鏈路監控方案與傳統的鏈路監控方案相比,對業務應用的侵入幾乎可以忽略不計,對業務應用的性能影響非常小。同時,提供了更全面、詳細的各項鏈路指標,方便系統的開發和維護人員快速排查、定位問題。同時,系統的可拓展性非常強,既可以兼容現有比較主流的鏈路監控插件,也可以支持個性化的鏈路監控指標配置。
作者簡介:
張愛華(1981-),女,碩士,講師。研究領域:DevOps,網絡工程,軟件開發。
白金峰(1997-),男,本科,工程師。研究領域:Linux,分布式系統,DevOps。