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

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

因而，分布式、云原生是企業(yè)應用架構的發(fā)展方向。

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

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

02. 30年過去，終迎來第二代監(jiān)控——可觀測

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

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

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

傳統(tǒng)監(jiān)控與可觀測的主要區(qū)別如下：

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

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

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

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

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

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

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

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

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

04. 可觀測成熟度模型

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

可觀測成熟度模型如下：

L1【基礎可觀測】

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

L2【應用可觀測】

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

L3【因果可觀測】

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

L4【主動可觀測】

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

L5【業(yè)務可觀測】

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

05. 可觀測平臺功能設計

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

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

06. 可觀測平臺建設過程

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

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

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

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

建設重點3——統(tǒng)一日志管理【Log】

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

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

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

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

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

基于統(tǒng)一告警中心的建設，實現一條告警的全生命周期流轉閉環(huán)管控。

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

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

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

挖掘告警相關故障信息：

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

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

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

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

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

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

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

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

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

前面提到，可觀測不是將現有監(jiān)控推倒重來，而是基于現狀進行規(guī)劃建設。對于大部分傳統(tǒng)企業(yè)而言，可參考以下三年建設計劃：

第一年：感知&治理

• 構建硬件、云、容器、系統(tǒng)、組件監(jiān)控等統(tǒng)一基礎監(jiān)控感知能力；
• 構建統(tǒng)一日志監(jiān)控感知能力；
• 構建統(tǒng)一應用調用鏈監(jiān)控感知能力；
• 構建告警的統(tǒng)一閉環(huán)治理能力。

第二年：定位&業(yè)務

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

第三年：智能&擴展

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