分布式系統(tǒng)的可觀測性建設

陳根

關鍵詞：分布式系統(tǒng)；可觀測性；可視化；鏈路追蹤

1概述

隨著社會生產力的進步，社會分工細化，新的職業(yè)出現(xiàn)，新的商業(yè)模式誕生，為滿足人們的生產生活需求，信息系統(tǒng)的建設方式和架構也在與時俱進，信息系統(tǒng)處理越來越多的數(shù)據(jù)，處理速度也越來越快，同時要滿足頻繁多變的業(yè)務需求，分布式系統(tǒng)逐步浮出水面。本文不討論分布式系統(tǒng)建設方案，重點就分布式系統(tǒng)的可觀測建設展開論述。

2可觀測基礎能力建設

分布式系統(tǒng)不同于傳統(tǒng)的單體系統(tǒng)或者MIS系統(tǒng)，由于其業(yè)務量龐大、系統(tǒng)架構復雜、組件關聯(lián)密切，為運維帶來極大挑戰(zhàn)。當出現(xiàn)異常時，告警能力、故障根源分析判斷能力、故障快速處置能力就顯得非常重要，其中基礎能力從監(jiān)控數(shù)據(jù)的采集、匯聚、異常監(jiān)測和告警等階段進行闡述。

2.1采集能力

分布式系統(tǒng)的模型建設是先決條件，從分布式系統(tǒng)的特點來講，往往采用容器化部署，使用Kubernetes作為容器編排工具，可以按照Deployment-Pod-container的結構來設計。模型建設后，通過各類數(shù)據(jù)采集器獲取模型實例的運行狀態(tài)和配置數(shù)據(jù)，此時需按照統(tǒng)一的規(guī)范來完成。數(shù)據(jù)采集分為3種類型，分別是指標數(shù)據(jù)采集、日志數(shù)據(jù)采集、其他類數(shù)據(jù)采集。

2.1.1指標數(shù)據(jù)采集

對于操作系統(tǒng)以及運行在操作系統(tǒng)上的數(shù)據(jù)庫、中間件等基礎軟件，通常采集其CPU、內存、文件系統(tǒng)、磁盤10、網(wǎng)絡吞吐量等使用情況數(shù)據(jù)。操作系統(tǒng)、數(shù)據(jù)庫等IT基礎設施的指標建議通過操作系統(tǒng)文件如/proc/stat等采集，避免使用操作系統(tǒng)命令，以減少對源系統(tǒng)的資源消耗。

對于應用系統(tǒng)來說，根據(jù)Google SRE指南，包括TPS、成功率、響應時間、交易量、錯誤率等黃金指標，數(shù)字化模型建設好后的各個模型實例都可以參考這些指標，采用key-value鍵值對方式以json格式上報。

采集容器指標可通過多種框架實現(xiàn)．如sidecar模式或demonset模式，也有多種開源框架支持，如Istio等，一般采用Prometheus進行容器指標數(shù)據(jù)的采集。

應用指標也有2種實現(xiàn)方式，一是通過應用系統(tǒng)計算好指標，通過API和Socket供數(shù)。二是監(jiān)控系統(tǒng)采集應用輸出的日志經(jīng)過約定的規(guī)則計算。指標數(shù)據(jù)需覆蓋各地域、站點、單元（租戶）、集群、容器等維度，采集數(shù)據(jù)應攜帶必要的元數(shù)據(jù)信息，包括站點、單兀、IP、應用ID、集群ID等，以供后續(xù)的匯聚計算和故障定位使用。

2.1.2日志數(shù)據(jù)采集

日志包括普通文本日志、操作系統(tǒng)日志、Tracing日志等，利用文件采集器讀取日志數(shù)據(jù)，逐行讀取。Tracing日志也可以通過寫臨時文件的方式進行采集，最好是采用遠程日志方式，類似指標采集的方案供數(shù)、時效性更高，如采用log4j的RemoteLogging功能，配置SocketAppender寫到遠程服務器。

2.1.3其他數(shù)據(jù)采集

以上2種模式是主動數(shù)據(jù)采集，為了滿足其他場景需要，采集框架應該建立通用數(shù)據(jù)上報接口供其他應用或者組件調用。分布式系統(tǒng)的應用與組件應提供可用性探測接口，用于監(jiān)測其可用性。

以上3種采集功能建設的同時，還應關注非功能性要求，以降低對源系統(tǒng)或者組件的影響。采集器需具備熱加載能力，其行為可被靈活定義和配置，包括日志路徑、采集頻率、數(shù)據(jù)報送發(fā)送頻率等，同時控制對CPU、網(wǎng)絡IO等資源的消耗。采集器應具備限流能力，流量過大應進行限流，避免影響源應用，可以設置一定的采樣頻率（50%和10%等），以降低網(wǎng)絡帶寬消耗，不能因為采集器異常或者數(shù)據(jù)鏈路異?；蛘吡髁勘l(fā)而影響源端應用和業(yè)務。采集數(shù)據(jù)上報使用星型結構，如圖1所示，葉子節(jié)點部署在被采集服務器上，匯聚節(jié)點負責集中所轄的葉子節(jié)點的數(shù)據(jù)，上報至核心節(jié)點進行匯總計算和存儲。匯聚節(jié)點支持橫向擴展，采集器與匯聚節(jié)點建立控制通信機制以感知匯聚節(jié)點的動態(tài)變化，靈活選擇需要上報的匯聚節(jié)點?？山柚鷕ibbon組件或者自研算法實現(xiàn)負載均衡策略。

2.2匯聚計算和異常監(jiān)測

數(shù)據(jù)采集到匯聚節(jié)點后，根據(jù)不同數(shù)據(jù)類型采用不同計算法方法進行異常監(jiān)測和計算。指標數(shù)據(jù)較規(guī)整，尋找異常點比較方便，適合直接進行程序計算，使用Java，Python，Golang等都可以對其進行簡單編碼、實現(xiàn)流式計算模式。同時，也能對接通用算法，如單指標異常監(jiān)測、基線算法等。以計算CPU使用率是否超過閾值為例，程序開辟隊列保存接收到的KV鍵值對（Tx為采集間隔），T1時刻讀取隊列中的Ⅳ個數(shù)值來計算平均值、峰值、中位數(shù)等，T2日寸刻再讀取隊列中的Ⅳ個數(shù)字進行計算。T1，T2，N（滑動窗口）可根據(jù)應用系統(tǒng)的業(yè)務特點、交易量等設定，』7v越小越靈敏，越大越遲鈍。如果是聯(lián)機系統(tǒng)，適當減少T1，T2間隔，縮小Ⅳ。當T1*N*T2時，步進式增量計算，每次計算的數(shù)據(jù)都是新鮮數(shù)據(jù)。具體如圖2所示。

以上內容也可以采用通用的開源解決方案（如Zabbix，Prometheus等）實現(xiàn)。

除了直接計算，對于時效性有一定容忍度的指標，如數(shù)據(jù)庫表空間、業(yè)務序號、當日累計交易量等，可引入趨勢預測算法來計算，以獲得更好的監(jiān)控表現(xiàn)，進而提前發(fā)現(xiàn)異常，及日寸介入處置。

聯(lián)機系統(tǒng)監(jiān)控往往和業(yè)務模式有很大關系，參與交易的角色和渠道等因素都屬于監(jiān)控的范圍，因業(yè)務需要可設計多維度靈活可配置的監(jiān)控模型來支持。通?？梢允褂靡韵?種方案。

2.2.1預置模型的設計和實現(xiàn)

對于每筆交易，根據(jù)交易要素拆分成多個KV鍵值對，交易的成功失敗結果也保存到每個KV鍵值對。用戶根據(jù)實際需要，在管理頁面端配置需要監(jiān)控的交易角色、渠道等交易因素（維度），監(jiān)控程序按照配置統(tǒng)計這些因素組成的維度的交易量、成功率等。

比如，配置A，B，C，D四個維度作為監(jiān)控項，監(jiān)控程序對每筆交易的A，B，C，D四個維度都進行統(tǒng)計，形成統(tǒng)計結果KV鍵值對，Key可以設置為A，B，C，D，根據(jù)不同取值統(tǒng)計匯總，并按照一定的時間周期判斷是否超閾值，進而產生告警。設計維度配置時，按照一定的邏輯順序組合，四因素的Key值緩存在內存中，以快速匹配，進而提升計算效率。具體如圖3所示。

2.2.2動態(tài)計算模型的設計和實現(xiàn)

相較于預置模型，動態(tài)計算就更復雜。對交易做降維處理，減少計算量。對于N維的交易來講，全維度動態(tài)計算是海量的，也帶來一些沒有價值的估算。降維計算有助于減少干擾，聚焦在有意義的數(shù)據(jù)上。具體流程如下。

（1）計算Ⅳ維中所有一維數(shù)據(jù)的指標（TPS、成功率、響應時間、交易量）。

（2）從中尋找指標最差的維度Dx。

（3）以維度Dx為基點，統(tǒng)計其他參與交易的角色指標，并找出可疑組合。

（4）列出組合供用戶選擇。

（5）告警收斂。

往往一個異常會產生多個報警，這時需要借助一些收斂算法壓縮告警量，以減少干擾，快速定位問題?；贑MDB的關聯(lián)關系，將同一個CI的告警歸集到一個主要告警上，同時將與之關聯(lián)的上游CI告警進行關聯(lián)，以“組告警”的方式呈現(xiàn)給用戶。在IT基礎設施發(fā)生故障時，這種收斂算法能起到很好的效果。以某臺物理機故障為例，監(jiān)控系統(tǒng)產生諸多告警：硬件管理平臺監(jiān)測到硬件故障產生的告警、連通性監(jiān)測發(fā)現(xiàn)物理服務器不可達告警、虛擬化平臺或者容器管理平臺發(fā)現(xiàn)虛擬機宕機或者容器下線的告警、分布式系統(tǒng)自身的服務調用發(fā)現(xiàn)某服務不可用的告警、交易監(jiān)控系統(tǒng)發(fā)現(xiàn)瞬時的交易成功率下降后者交易響應時間變長的告警。這些告警都和物理機異常相關。告警收斂算法設定一定的時間（因分布式系統(tǒng)對基礎設施異常的敏感度不同，通過測試可以得出這個值），如3分鐘內，那么相關的告警都可以收斂到此物理服務器宕機的告警上，前提是在CMDB中建立相關的關系，即物理機與虛擬化服務器的關系、物理機與容器的關系、容器與邏輯服務的關系、交易和邏輯服務的關系（通過鏈路日志關聯(lián)）[1]。

經(jīng)過測算，此類收斂模型的有效率可達50%以上，大大降低了對信息的干擾，并可在可視化圖表上直接顯示異常點。

在Tracing日志中根據(jù)Tracingid形成鏈路，相同鏈路產生的告警也可以歸集到一起，并結合CMDB關聯(lián)到CI上，以收斂到較小的范圍。

3可視化能力建設

從分布式系統(tǒng)采集的運行數(shù)據(jù)，經(jīng)過采集匯聚和異常監(jiān)測計算，得到了分布式系統(tǒng)的運行狀態(tài)數(shù)據(jù)以及可能的異常點，通過系統(tǒng)整合和集成，建立分層次、縱向關聯(lián)的多視角觀測平臺，集中展示分布式系統(tǒng)的運行信息，從多個維度建立可視化展示配置視圖、關注性能的指標視圖、排查分析的日志視圖以及鏈路視圖等。具體如圖4所示。

配置視圖。用于展示分布式系統(tǒng)的配置數(shù)據(jù)及關聯(lián)關系，包括服務器與操作系統(tǒng)配置、應用與容器、分布式數(shù)據(jù)庫以及其他組件等。

指標視圖。用于展示分布式系統(tǒng)的應用及依賴服務／組件的指標類數(shù)據(jù)，指標視圖提供固定格式的數(shù)據(jù)，通過定制儀表盤方式實現(xiàn)個性化changing展示。

日志視圖和鏈路視圖。用于展示分布式系統(tǒng)的文本日志，包括系統(tǒng)日志、應用日志、數(shù)據(jù)庫日志，以及相關的服務與組件的文本日志，提供常規(guī)的基于時間、節(jié)點、文件名、關鍵字等條件的搜索功能，并提供基于spl語法的高級查詢功能。通過日志時間，所屬的文件、進程、容器等與鏈路日志進行關聯(lián)，以查詢tracelD的單筆鏈路數(shù)據(jù)、指定時間和節(jié)點范圍的鏈路數(shù)據(jù)清單[2]。

3.1全局健康視圖

將分布式系統(tǒng)的SLA設定核心監(jiān)控指標作為全局健康視圖的主要展示數(shù)據(jù)，健康視圖簡明扼要地顯示系統(tǒng)的狀態(tài)，其具有高度的概括性，如全局交易成功率、資源可用率、全局交易響應時間等，若指標出現(xiàn)異常，則標記為紅色，并結合其他的視圖進行下鉆分析，找到引發(fā)異常的根源。

可建立“應用全局性能指標”，以應用為中心，將Tracing，Metric，Log多維數(shù)據(jù)進行融合，從而基于業(yè)務視角，統(tǒng)一性能評價標準，主動發(fā)現(xiàn)性能瓶頸、快速感知故障、高效故障恢復，保障應用系統(tǒng)連續(xù)穩(wěn)定。

3.2部署架構視圖

綜合性視圖，將IT基礎設施到分布式系統(tǒng)的各個組件進行全面展示。構建此視圖時，可以自底向上展示網(wǎng)絡、服務器、容器、邏輯服務、交易的數(shù)據(jù)，每個節(jié)點可顯示更為詳細的具體運行數(shù)據(jù)。當出現(xiàn)故障時，部署架構視圖以紅、橙、黃等顏色進行警示，打開故障點后即可進入故障排查視圖。

3.3故障排查視圖

直接顯示故障內容，一般是告警或者收斂后的組合告警，視圖展示關聯(lián)該故障節(jié)點的交易運行情況和IT基礎設施的情況，以及鏈路視圖等，可根據(jù)展示的內容和故障染色等進一步打開故障點以分析故障。

分布式系統(tǒng)可觀測性建設是一項系統(tǒng)性、綜合性工程，其核心在于采集和匯聚計算上，利用成熟的異常監(jiān)測算法可以定位到一些故障點，結合分布式系統(tǒng)建模以及告警收斂算法，將異常點與應用、IT基礎設施的運行日志關聯(lián)起來．可有效幫助開發(fā)和運維人員全面掌握生產運行信息，快速定位故障和解決問題，從而確保分布式系統(tǒng)高效穩(wěn)定運行。