01. 數字化轉型與可觀測的關系

在數字化轉型的浪潮中，我們面臨著將“線下業務線上化”及實現“業務快速創新迭代”的迫切需求，這也進而要求支撐業務的應用系統更加敏捷、可擴展性更高。

因而，分布式、云原生是企業應用架構的發展方向。

分布式架構下，各種IT對象如消息隊列、緩存、分布式數據庫等層出不窮，并且組件間的調用關系錯綜復雜。

此時，傳統IT監控只能提供資源層面的狀態警告，無法提供分布式應用故障診斷所需的更多有效信息，因此，一個面向應用面向故障的全棧可觀測方案越來越成為企業IT運維的迫切需求。

02. 30年過去，終迎來第二代監控——可觀測

IT監控作為IT運維之眼，是IT運維第一個建設的工具，追溯IT監控工具歷史，已有30年之久。傳統IT監控的發展，主要是在監控對象以及在監控能力（如指標、Log、Trace）的不斷擴展，發展至今，已形成眾多從IaaS到SaaS層的監控工具。據Gartner市場調研數據顯示，超過70%的中大型企業擁有10個以上的IT監控工具，以滿足各種IT監控需求。

監控工具越來越多，但每個監控工具卻只能揭示業務和應用的部分問題，且工具能力重合、工具數據互為煙囪，這導致用戶難以聯動整合所有監控，面向整個業務和應用進行全面的故障診斷。

傳統工具發展的這些瓶頸和問題在可觀測體系中得到了完美解決。

傳統監控與可觀測的主要區別如下：

簡單來講，監控主要聚焦在感知，可觀測還聚焦于問題出現之后診斷分析和隱患發現。

03. 基于四大支柱數據設計可觀測體系

要做到面向應用、面向故障的可觀測，我們需要為整個應用系統的生產運行拓撲進行建模，并將應用所有相關組件的各種觀測數據進行有機聚合，因此，可觀測體系設計的核心理念在于對Metirc、Log、Trace、Topology這四大支柱數據進行統一采集、統一治理和有機聚合。

這幾個數據之間的關系如下：

• Topology描述了一個應用包含多少個微服務、一個微服務包含多少個實例，實例運行在哪些Pod上，Pod又運行在哪些虛擬機上， 虛擬機連接了哪些存儲，服務或實例間存在什么樣的調用關系等資源配置和關聯關系數據。
• Topology提供了觀測的元數據（資源及拓撲），作為Metric、Log、Trace的資源主體。但在某些場景下，Trace中發現的應用調用關系、Log中采集和發現的一些業務交易拓撲關系，也可以成為Topology中的數據來源。
• 當一個IT對象的指標（Metric）存在告警時，我們需要基于Trace向上分析故障影響，向下追溯根因，也需要獲取該對象的Log信息進行進一步的故障診斷。
• 當一個微服務的調用（Trace）延遲或失敗時，我們可以基于Metric和Log進一步分析相關對象的關鍵健康指標和日志上下文信息。

基于上述理念，可抽象可觀測的數據模型如下：

• 面向應用系統部署情況構建從上到下（應用、微服務、實例、系統與虛擬化、硬件）的縱向分層對象模型關系；
• 基于APM調用關系構建橫向的服務間調用和實例調用關系；
• 每一個實例的狀態信息，可通過各種采集手段獲取相關的Metrix、Log、Trace監測數據。
• 當系統出現故障時，通過橫縱向的關系和Metric/Log/Trace的告警聚合信息，實現自動化告警收斂和故障診斷，從而給出相關的根因推薦。

基于此設計，我們可以自動構建應用橫縱向全景拓撲，感知應用故障點。

根據故障點實現上游故障影響分析和下游故障根因溯源。

04. 可觀測成熟度模型

可觀測既包含了傳統監控的技術，又包含了基于數據和AI的統一數據治理與智能根因分析以實現端到端的監控與分析的能力。可觀測體系的建設不是一蹴而就的，也不是將傳統監控體系推倒重來，而是一個基于科學建設路徑和方法逐步演進的過程。

可觀測成熟度模型如下：

L1【基礎可觀測】

• 補全基礎監控，以滿足分布式時代各類云、容器、分布式組件等的監控要求；
• 對各個監控工具中的告警事件進行統一告警匯聚、告警豐富、告警收斂、告警分派、告警分析、告警處置、告警復盤的全生命周期管理。

L2【應用可觀測】

• 基于數據平臺思路建設集中監控，接入企業當前已有各類監控工具，實現統一對象管理、指標管理、策略及視圖管理等；
• 補全APM能力實現應用性能監控。

L3【因果可觀測】

• 將四大支柱數據融合打通，通過各種自動構建的排障拓撲提供故障輔助定位能力。

L4【主動可觀測】

• 在L3之上，基于上下文分析能力和AI能力，實現故障的主動式定位和根因推薦；
• 基于知識庫和大模型能力，實現故障處置預案推薦，并提供監控、告警、日志小助手與運維人員進行實現緊密協同。

L5【業務可觀測】

• 基于行業特征，實現對關鍵業務交易活動和交易鏈路的監控，將業務監控與應用可觀測無縫集成以進一步保障業務穩定運行；
• 聯動ITSM、自動化等實現端到端的故障預防、發現、定位、處置與復盤改進的“1-5-10”業務連續性管理能力；
• 基于算力調度能力實現業務智能擴縮容和成本優化。

05. 可觀測平臺功能設計

可參考下圖進行可觀測平臺的功能設計：

• 以數據中臺思路建設底座，以滿足各類數據的采集清洗和各類外部監控工具數據的接入；
• 建設統一觀測能力中心，包含面向Metric、Log、Trace的各項觀測基本能力；
• 構建統一觀測場景，包含基礎集中監控、日志和APM、統一告警場景，也包含觀測融合相關全鏈路監控、故障輔助定位等場景。

06. 可觀測平臺建設過程

建設重點1——觀測元數據建模治理【Topology】

• 面向應用建立觀測元數據模型，包括描述應用的生產和災備環境，描述應用的可用區或分布式地域集群，描述組成應用的子系統或模塊（微服務）。
• 模塊（微服務）包含一組實例，實例則是運行于虛擬機或容器上。微服務之間存在調用關系，微服務也與消息隊列、數據庫等基礎組件存在訪問關聯關系。
• 觀測元數據建議使用企業統一的CMDB進行存儲。一方面可以充分利用CMDB中自動采集&手動維護的各類IT資源對象數據，另一方面基于統一對象配置數據與ITSM、自動化等運維工具聯動實現故障定位（如從ITSM獲取該對象近期的變更審批信息，從自動化平臺獲取該對象近期的操作記錄以作為輔助故障定位）和處置自動化。

建設重點2——指標體系建模治理【Metric】

• IT資源對象種類多，IT存量監控工具數量大，因此面向硬件、系統、云、OS、虛擬化、中間件、數據庫等基礎資源的集中監控能力是可觀測體系建設的基礎。
• 集中監控的關鍵前提是統一指標治理，包括對每種資源對象的指標定義、指標梳理和指標消費等。
• 集中監控的建設過程是擴展種類采集插件覆蓋各種IT對象，或提供便利的數據接入能力接入其他監控工具的數據。

建設重點3——統一日志管理【Log】

可觀測平臺需要提供統一的、豐富的日志采集、清洗、檢索與展示能力以覆蓋各類設備日志管理需求。

建設重點4——APM實現故障追蹤【Trace】

APM是分布式系統的關鍵監控能力，通過APM可以對應用的四個黃金指標進行監控，可以對服務件、服務與組件間的調用狀態進行監控，還可以實現對服務接口級、方法級的故障發現與診斷分析。

建設重點5——實現告警的全生命周期治理【Alert】

• 告警接入：通過可擴展的告警源插件完成各類告警事件的接入；
• 告警豐富：聯動CMDB完成告警豐富，包括運維人員、告警對象配置信息等；
• 告警抑制：基于多種靈活的告警收斂方法實現告警收斂，避免告警風暴；
• 告警分派：將告警事件自動分派或手動分派給相應的運維人員進行處置；
• 告警分析：基于告警對象的Log、Trace、Metric，基于告警對象的上下游關聯對象的狀態信息，基于告警對象的近期變更或運維信息進行展示分析；
• 告警處置：聯動自動化平臺進行告警的處置。

基于統一告警中心的建設，實現一條告警的全生命周期流轉閉環管控。

建設重點6——基于AI與LLM的智能可觀測【AI】

通過集成AI能力實現動態閾值、告警聚合收斂、時序預測、日志聚類分析、多維下鉆與根因定位等智能可觀測能力。

基于LLM可以構建可觀測智能小助手，如展示告警詳情：

挖掘告警相關故障信息：

獲取故障推薦和交互式故障自動化處理：

建設重點7——基于應用可觀測向上構建業務可觀測【Business】

在數字化時代，業務的穩定生產運行都會反饋到應用系統的各項運行指標上，運維的最核心目標也是保障業務的穩定生產運行。

當我們實現了應用可觀測后，基于應用可觀測能力去構建面向上層各類業務活動、業務場景的可觀測，就會水到渠成且事半功倍。

業務觀測領域中，最重要的是對各類業務交易場景以及各個應用系統的業務黃金指標進行監控，例如銀行，有各種支付、轉賬、查額、還款等場景，這些交易的交易鏈路如何自動構建，如何監測每一筆交易的效率和質量，如何在交易異常的情況下迅速找到問題點并進行解決，是業務可觀測的重點建設內容。

業界基于業務監控的有三大技術：APM的交易鏈路自動構建與黃金指標監測、應用標準化日志的交易鏈路自動構建與黃金指標監測、網絡流量鏡像分析的交易鏈路自動構建與黃金指標監測。

三者各有優劣點，如基于APM的技術面臨著全量采集給應用帶來的性能壓力、基于日志則需要應用進行標準化日志輸出的改造、基于網絡流量則面臨著網絡丟包、數據量巨大和云原生SDN架構下的流量采集技術壁壘等問題。企業需要根據自己的實際情況選擇合適的技術。

最后，業務可觀測的技術還需要能夠聯動應用可觀測，從而實現從業務指標到具體問題資源對象聯動起來的根因定位。

07. 可觀測平臺三年建設計劃建議

前面提到，可觀測不是將現有監控推倒重來，而是基于現狀進行規劃建設。對于大部分傳統企業而言，可參考以下三年建設計劃：

第一年：感知&治理

• 構建硬件、云、容器、系統、組件監控等統一基礎監控感知能力；
• 構建統一日志監控感知能力；
• 構建統一應用調用鏈監控感知能力；
• 構建告警的統一閉環治理能力。

第二年：定位&業務

• 面向應用構建故障的快速定位能力
  融合APM（Trace）、基礎監控（Metric）、日志（Log）、CMDB拓撲（Topology）進行輔助故障定位；
  構建各類可視化應用拓撲提供故障上游影響分析能力，提供故障下游溯源分析能力。
• 面向業務提供監控與故障定位能力
  實現業務指標監控與業務交易鏈路觀測；
  結合應用可觀測能力實現業務問題的故障定位。

第三年：智能&擴展

• 結合AI和大模型進一步升華可觀測能力
  基于AI實現根因定位、動態閾值、告警聚類、離群檢測、容量預測、智能擴縮容、算力調度能力；
  基于大模型與知識庫的處置預案推薦，基于自動化的故障自愈。
• 融合網絡監控工具和用戶監控工具實現全棧監控
  融合NPM、eBPF技術將網絡流量級診斷能力豐富到故障定位能力中；
  融合RUM（真實用戶監控）實現端到端的全棧可觀測能力。