基於系統融合的統一監控平臺設計

目前做監控廠商的產品基本上都是大雜燴，各種概念和名詞很多，強調整合或加 agent 等加層的方式去實現，和軟體工程、系統化的思想其實是相矛盾的。為了釐清統一監控平臺方案的設計思路，簡化設計實施的難度和複雜度，減少重複建設，本文將詳細討論統一監控平臺的設計。

最近聽了《業務流程重構 (BusinessProcess Reengineering) 》，感覺和我一直以來的一些體會和思路不謀而合。道理都是相通的，殊途同歸。fundamental rethinking( 徹底的重新思考 ) 、 radical redesign (根本的重新設計)、 dramatic improvement (顯著的提升)。系統融合思路就是基於徹底的思考，重新的設計，以期獲得顯著的提升。

在容器雲平臺建設的時候，我們就考慮並提出過圍繞容器雲平臺的監控方案。監控、日誌等不應該是容器雲平臺的元件而應該獨立於容器雲平臺並同時支撐容器雲平臺的獨立元件或獨立平臺。每個系統都會涉及監控、日誌等功能，所以這些功能就可以提取出來，實現複用，構建獨立的統一監控中心、集中日誌中心等，再基於這些統一監控、集中日誌等平臺構建可複用的監控、日誌等服務，建設企業級技術中臺(技術中臺服務)。

圍繞容器雲、 DevOps 、微服務等的雲原生討論也很多，通常都是隻重一個或幾個點，很少有全域性的和頂層的考慮，所以監控等也基本上沒有全域性的方案。監控能力散落於各個單體系統，從而導致了人為的部門牆。容器雲、 DevOps 、微服務等技術相輔相成，非常適合從整體上來考慮，構建企業級的平臺和中臺，從而支撐企業敏捷變化的業務需求，支撐企業業務實踐和轉型。而監控是其中必不可少的部分。所以我們一直也在考慮如何和容器雲平臺、 DevOps 融合等來透過分散式微服務架構建設統一監控平臺。

目前做監控廠商的產品基本上都是大雜燴，各種概念和名詞很多，強調整合或加 agent 等加層的方式去實現，和軟體工程、系統化的思想其實是相矛盾的。拔冗去繁，撥雲見日，監控無非就是監控資料採集和監控資料接入、監控資料處理(包括監控實時資料處理和監控歷史資料處理)、資料儲存和查詢顯示。其他的功能都是基於監控的資料的進一步擴充套件，比如鏈路跟蹤與拓撲展示、指標管理、探針管理、故障檢測、異常處理、工單流程管理、知識庫等(如 圖 1 統一監控方案思路 )。

圖 1 統一監控方案設計思路

為了釐清統一監控平臺方案的設計思路，簡化設計實施的難度和複雜度，減少重複建設，我們今天詳細討論下統一監控平臺的設計。整體思路可以考慮縱向分層、橫向分段、側向管控的方法來設計實現。把應用涉及的整個軟硬體環境當作一個整體、一個系統、一個體系來看待， 從而形成一個全域性立體體系。

一、 縱向分層

目前實際的業務應用系統，至少是 C/S 、 B/S 兩層架構，而分散式架構往往層次更多，從前端、中間服務層、資料庫或資料儲存層以及中介軟體元件、作業系統、基礎設施資源伺服器、網路裝置等，任何一個節點出現異常都有可能影響到業務應用的執行。比如說伺服器磁碟損壞，可能導致資料庫或檔案不可用，從而導致應用異常等等。既然每一層都有可能出現故障，那麼每一層都需要進行監控，並且需要把各層之間的關係串接起來，形成鏈路。透過鏈路實時展示就可以知道哪一層有異常，快速的定位和處理問題。這就是監控分層的價值。

監控分層

分散式系統帶來了運維的複雜性，特別容器化之後，靈活性更高，但層次更多，運維複雜化。如果有沒良好的監控平臺和工具，一旦容器達到一定量之後，就會超出人的管控能力，遇到異常問題就需要花費大量的時間排查問題。

監控縱向分層的思想就是把應用監控資料採集的問題簡單化，也使應用呼叫處理過程的鏈路更清晰，更好的實現鏈路跟蹤、鏈路拓撲展示，更好更快的定位問題，處理異常。當然這需要提前做整體規劃、全域性的設計。比如說日誌為監控提供了很重要的支撐，日誌的鏈路 ID 就需要全域性定義。從開啟前端頁面到中臺服務到後臺資源等，這個鏈路能夠透過全域性 ID 關聯起來。

監控分層可根據實際的業務鏈路進行劃分，比如說前端渠道、前端應用( Client )、中臺可複用服務、中介軟體、後端服務、服務部署執行平臺、資料平臺 / 資料庫、軟體基礎設施、硬體基礎設施等。分層目的是為了簡化監控資料採集，便於實現鏈路跟蹤、問題下鑽定位等能力。

鏈路跟蹤、拓撲展示

透過分層，才能更好的實現鏈路跟蹤能力。其實我們需要考慮的不止是應用服務之間的呼叫關係，也需要考慮支撐這些應用服務的元件、工具、作業系統、基礎設施資源等。這樣才能形成多個相互關聯的閉環。這也我們思考規劃建設統一監控平臺的原因。

當然業務應用的鏈路跟蹤是核心。應用部署於支撐平臺，支撐平臺執行在容器、虛擬機器、物理伺服器等中，又涉及不同的作業系統、系統配置、CPU、記憶體、網路、磁碟、儲存等眾多的資源，在出現故障的時候需要抽絲剝繭，往往需要花費大量的時間和精力來定位故障，找到root cause。比如說節點磁碟空間滿了導致某個中介軟體服務停掉，無法啟動，但異常往往是從應用曝出，從應用、日誌、中介軟體、節點、磁碟等過程定位，雖然最終可能會解決問題，但其代價卻是很高昂的。因此，監控從端到端實現分層，這樣可以明確每個層次所採集的指標和內容。透過統一的鏈路來快速定位故障，在系統融合階段將變得越來越重要。

鏈路跟蹤需要採集各個層次物件的指標，採集的指標根據監控物件的不同和監控指標的需求分別定義，每個應用從前端到後端往往經過若干個呼叫層次，可能涉及不同的物件和系統、平臺、工具等，往往比較難用統一的標準去套這些物件，這也是統一監控落地比較難的地方，但這也是非常關鍵的。如果這些指標都能抽象並對映到不同的物件，那麼統一監控平臺的建設將非常容易。

有了標準化的指標，從前端到後端實現端到端的資料採集則可以實現鏈路跟蹤，以拓撲形式展示服務 / 系統之間呼叫關係。在出現異常的情況下，可以快速下鑽到根故障點，從而快速定位故障並解決故障。

二、 橫向分段

監控資料採集

監控首先是監控資料的採集。要採集資料，需要知道從哪裡採集，採集什麼樣的資料，怎麼採集資料。這就是監控物件、監控指標、和監控資料採集方法。

1. 監控物件

監控物件就是我們監控採集資料的源端，包括眾多的應用、系統、元件、平臺、資料庫、伺服器、網路裝置等等。由於這些應用和系統眾多，需要監控的點(指標)也可能各不相同，這就可能導致我們在實施統一監控專案時有點無從下手。而廠商的監控產品是這些年的積累，五花八門，積累的時間越長，可能包含的東西就越多、越雜亂。國內大部分軟體廠商的一個重要特點是基本上都是從做專案開始的，缺乏產品的頂層規劃和設計，所以一個產品可能無所不包，什麼都有但什麼都不夠精深，所以更像是大雜燴。這麼說可能得罪很多廠商，但我們還是希望國內的軟體廠商能真正靜下心好好思考，真正的爭口氣，真正的強大起來，真正的把產品做好做強。由於目前各種應用系統架構、開發語言、介面方式等很多都不相同，這無疑增加了統一監控平臺的實施難度。所以很多人直接去部署一個agent來採集資料。這也導致了可能很多agent在執行，使運維工作複雜化。所以在考慮統一監控平臺的時候需要梳理監控物件，分層、分類進行梳理。硬體伺服器的監控和軟體應用的監控差別一定是很大的，所以首先要明確監控物件、監控目標才能確定監控指標和監控資料採集方式。

2. 監控指標和監控指標目標

每個存量應用或每套存量系統或多或少都會有相應的監控能力。首先需要梳理下這些監控物件的監控能力，確定監控採集的指標，比如請求到來時間、請求處理等待時間、 CPU 時間、響應時間計算、平均響應時間計算、最大響應時間記錄、執行緒數、程式數、 CPU 、記憶體使用等等，這就是監控物件的監控採集指標的定義。每個監控層次監控指標有一些通用性的指標，但每個監控物件都有自身的一些特定指標。通用指標和特定指標的集合反映了監控物件的執行狀況。對於新的應用和系統，要考慮透過標準化的監控採集方式採集標準化的監控指標，這在建設統一監控平臺的時候需要明確定義。這樣才能更好的基於監控資料首先更多的功能，比如鏈路跟蹤、異常定位、智慧運維等。

GoogleSRE 提出了在定義監控指標的同時要關注監控指標目標。所謂監控指標目標也就是服務質量目標，是指標的目標值或者目標範圍。透過目標值可以確定採集到的指標值是否在合理範圍內。通常確定一個合理的目標值並不容易，往往需要大量實踐總結。

3. 監控採集方式

監控物件不一樣，監控需求、監控指標和監控資料採集方式也可能會不一樣的。資料採集，首要考慮是透過應用或系統本身來提供資料，透過介面對外提供監控資料，是publish分發方式，而不是pull拉取方式。透過publish方法，所有需要這些資料的物件(接收端)都可以接收，增加接收端而不需要額外付出代價。

存量系統往往不支援這樣的方式，所以需要透過部署agent、daemonset等方式來採集資料。不管用agent或者探針、daemonset等方式，都相當於加了一層，是整合的方式，效能和效率都會受到影響，也會帶來額外的管理複雜度。所以監控資料採集最好是監控物件直接吐出需要採集的監控指標資料，而不是透過整合方式。比如容器雲平臺的執行資料直接透過容器雲平臺把資料吐出，雲管平臺的虛擬機器執行資料由雲管平臺來把資料吐出等。這樣每個層次的資料就可以實現複用。降低對接、整合工作量，降低系統建設複雜度，也降低運維難度。

我們理解很多時候為了快速上線，直接對接監控工具，比如Prometheus、Zabbix等，但這些資料有時候跟我們期望的資料會有差別。我們在容器雲平臺運維的時候，就發現透過Prometheus的資料有時間會導致誤告警，docker的執行資料和pod的執行資料以及Prometheus的監控資料會有差別，因此，最好的方式是直接由容器雲平臺提供docker和pod的執行資料，而不是再經過Prometheus等中間層。

監控資料處理

監控資料包括實時資料和歷史資料。實時資料和歷史資料的價值不一樣，其處理方式也有不同。實際的業務處理往往需要基於歷史資料經驗並結合實時資料，實現更準備的一個預判。

1. 監控實時資料處理

實時資料往往價值最高，隨著時間的推移，資料逐漸失去價值。監控的實施可以考慮分層來實現，從前端、中間服務(或中臺服務)到基礎設施平臺、資源，每個層次每個元件每個物件都需要進行監控以跟蹤其執行狀態，分析其執行情況和可能趨勢。透過實時的監控則可以實現實時風險管控和實時風險處理，避免後知後覺，造成額外的損失。

對於實時資料往往需要實現實時事件處理能力，可以建立複雜事件處理系統進行實時事件處理，結合歷史資料學習所構建的態勢感知、風險控制演算法等提升實時業務處理能力。

2. 監控歷史資料處理

歷史資料則關注歷史趨勢和統計分析。比如我們提到的基於歷史資料的態勢感知分析預測能力、風險模型等。當然對具體的客戶來說，其某個時點的歷史資料為該客戶提供了該時點的記錄，也有意義，但也僅僅檢視、對比等，可能就無法基於該資料做投資等決策。

3. 日誌

日誌是採集的一部分，由於日誌量大，所以可以單獨對日誌進行處理，但日誌的監控和資料處理結果要回歸監控平臺。也就是說，日誌儲存可以單獨儲存在檔案、資料庫、ES、或大資料平臺等，不過需要考慮實現日誌的查詢搜尋能力，支援快速日誌資料查詢和過濾，支援時間區間、關鍵字等查詢或全文查詢、模糊查詢等能力。

這些能力可以和技術中臺的搜尋中臺、訊息中臺等能力結合，實現日誌的統一處理和管控。

資料儲存

作為企業的重要資產和生產要素，資料是需要落地的，需要儲存起來以被查詢、統計、分析等之用。所有的資料需要儲存，可以根據實際選擇儲存的方式。並不一定存在一個地方。按照微服務架構的思想，資料是可以分庫存放的。監控資料量往往是很大的，但監控資料的價值隨著時間快速衰減。比如說節點資源的使用情況監控，像證券每工作日週期性的高峰流量，會導致資源使用的週期性高峰，為了檢視一段時間的資源趨勢，就可以儲存一個月、 3 個月等的資料。儲存的資料和採集的資料的時間間隔往往也是不一樣的。比如資料採集可能是每 2 秒一次，但 1 周之前的資料可能只儲存 1 分鐘一次的資料， 1 月之前可能儲存 5 分鐘一次的資料。具體的策略根據實際業務需求來定義。

資料可以存放在資料庫、或者大資料平臺，也可以是檔案、 ES 等地方，通常要基於系統架構和技術能力進行決策。沒有十全十美的方案，每種方案都會有優缺點，選擇適合自己的方案就好。

查詢展示

儲存方式的選擇很重要一點是為了便於查詢和搜尋。資料要用起來，流轉起來，才能真正體現資料的價值。監控採集的資料要能便利的展示給不同的角色人員。每個角色的許可權可能是不一樣的，所以看到的資料也可能是不一樣的。這和我們前面提到的分層思想一致，不同的人員負責不同的工作，其許可權也是不一樣的。透過授權等機制，在保障安全的前提下，可以實現故障資料的查詢展示、定位處理等，那麼資料就需要根據角色及其許可權進行展示和過濾，以確保資料的安全。

三、 側向管控

統一監控平臺本身依然可以是一個獨立的系統，同時又是企業融合系統中的一個模組或元件或子系統，所以實際應用過程依然中需要對這個子系統進行管控，比如訪問許可權的設定控制等。還有監控平臺自身物件和屬性的管理，比如指標的定義和管理、指標目標、服務協議的定義和管理、探針的管理、指令碼的管理、通用配置的管理、日誌、審計等功能。這些都是平臺需要實現的能力。

認證許可權、訪問控制管理

登入認證、許可權管理是每個系統都需要的基本功能，所以認證、許可權等能力就可以提取出來以可複用服務的形式作為中颱的能力，實現企業級共享，避免重複建設、降低成本提供效率。統一監控平臺可以直接使用身份認證中臺服務(基於認證平臺提取沉澱)和許可權管理中臺的服務(基於許可權平臺)實現認證和許可權管理就可以了，不需要再重複開發登入認證和許可權管理能力。

指標定義和管理

對於每一次的每一個監控物件定義其監控指標。比如服務的響應時間、平均響應時間、最大響應時間、最小響應時間、請求到達時間、響應回覆時間等。透過定義每個監控物件的監控指標，就可以把該物件的關注點都可以採集起來，進行後續的分析處理。比如一段時間內的響應時間就可以透過圖形的方式展現出來，看下響應時間的分佈，和我們期望的響應時間這個指標的目標是否匹配，差距有多大。這就給我們了一個最佳化和調整的參考。

探針管理

不同的物件可能需要不同的探針來採集資料。統一監控平臺需要提供不同探針的統一管理、配置等能力。這是監控平臺自我管理自我監控能力的體現。我們也提到，探針其實是一種加層整合方式，帶來便利的同時也帶來新的問題，比如說不同探針型別要管理起來不得不增加探針管理功能模組等，這也就帶來了問題的複雜性。所以，如果能夠最終都以某種標準化或規範化的方式來獲取監控資料，則可以簡化整個架構和監控處理邏輯。

自動化指令碼管理

監控該平臺往往需要管理一些自動化的指令碼，比如一些自動化巡檢任務的排程管理等。這些能力也和排程平臺相關聯，可以部署於排程平臺來統一管理。這樣就松耦合了平臺架構，減少重複的建設。

配置設定

眾多的元件和工具往往都有很多的配置引數需要調整，這些配置可以在配置中心統一來管理，這就和我們提出來的系統融合思路中“配置中心元件”融合起來，在配置中心進行配置的統一管理。

日誌和審計

統一監控平臺有自身的日誌及操作審計需求。這些日誌和審計資訊也可以傳送到日誌中心統一管理起來。然後由日誌中心提供查詢介面整合到監控平臺，這樣監控平臺的日誌、審計資料不需要自己管理，按需從日誌中心盡心查詢。這就實現了系統之間的融合。

需要注意的是，系統融合採用的是分散式微服務架構思想，可以基於雲原生容器技術實現彈性伸縮以支援需求的擴充套件和變化。它不是一個集中式的架構，但它是一個一體化可適用不同場景架構需求的分散式架構。

四、 監控功能擴充套件

基於採集到的資料可以實時或延時做故障檢測、異常處理等。多指標複雜的資料處理可以透過 AI 演算法平臺來實現，也就是智慧運維部分。可以和我們大資料平臺、機器學習平臺、資料智慧中臺等整合。在進行監控平臺架構設計時，認識到並理解系統融合的趨勢，將各個系統和模組進行無縫融合，則會在後期減少大量的重複建設工作量，從而提升效率。

1. 告警

透過規則實現自動告警和通知。如果需要人為介入，則透過自動化工單來記錄並自動分發到相應的角色，處理完畢由利益關係人進行主觀反饋評價。工單和評價反饋可以積累形成量化的工作業績資料，可以考慮作為量化績效考核的參考(這就是系統融合思想，不是單一的看待一個問題)。

2. 故障檢測、異常處理到知識庫

基於監控採集到的資料進行執行狀況分析和預測、異常處理等。隨著量的積累，可以逐步形成知識庫，反過來支援故障檢測和異常處理，使之相輔相成。

3. 工單處理

系統或應用出現異常時，需要人來介入才能解決，則需要分配工作給某個人。通常是誰負責誰來處理，不過多數時候會涉及多個系統之間、多個人員之間的協調配合。為了更好的激勵員工，公平的記錄每個人的工作，更公正的評價每個人的績效，有必要透過高效的工單流程來達到這些目標。

4. 績效統計

另外，目前提倡量化管理，每個人的工作量和工作效率可以透過相應的工單統計和成果反饋從定量和定性兩個方面進行參考，特別對於外包人員的管理和評價將會更有合理依據。

5. DevOps

將持續監控、持續反饋置於 DevOps 閉環流程之中，持續改進業務應用的質量以及環境的可用性。DevOps 是一種方法論，以閉環流程的方式實現落地。DevOps 的目的就是為了協調開發人員和運維人員之間的關係，提升研發交付質量和交付效率，提升系統的穩定性、降低運維的工作量。處理好開發和運維之間的關切和利益分配問題則比較容易理順彼此之間的矛盾，從而減少內耗，提升效率。這也和輸出(工單)、評價(績效)、故障率和故障處理效率密切相關。

五、 大屏展示

監控一個關鍵的能力是視覺化展示，能夠讓使用者一目瞭然看到核心關鍵應用、系統、元件、資源、資產、趨勢等狀況，透過在大屏上實時展示這些使用者關心的核心資訊，則能夠幫助使用者實時掌握系統執行狀況和趨勢，避免錯失重要的異常問題等。

所有實時、歷史、統計計算、分析結果可以作為輸出在大屏上實時展示，並且可以透過下鑽達到任何一層，以實現問題的快速定位和關聯查詢。

從系統融合的角度，統一監控平臺的建設需要考慮各個層次和各個系統的關係，同時要構建可行的可適應的架構來為未來的擴充套件打好基礎。無論資料、或者元件等，都需要提前考慮清楚、架構清晰。在設計建設統一監控平臺之前，就需要考慮好平臺之上的可複用中臺能力、平臺所支撐的應用能力等，這樣，才能比較順利的推進企業的系統逐步走向渾然一體，避免重複建設、推倒重來，才能在數字化轉型過程中贏得先機，支援業務順利轉型。