01. 傳統監控與可觀測差異

傳統監控體系是面向靜態資源通過主動撥測方式構建的時序監控指標視圖，其前置條件需要明確觀測對象及觀測指標，基于指標體系工程師能夠了解哪些系統是確定工作的。在云原生觀測場景下指標覆蓋不全、業務侵入性大、數據關聯性差、缺乏基于業務視角異常感知機制等問題凸顯，傳統監控能力難以適應云原生架構動態變化、服務依賴復雜、信息組織多樣的現實問題，無法從全業務流量鏈路上有效定位問題，故障處置不及時整體業務連續性遇到較大挑戰。

云原生觀測體系通過多維觀測數據鏈路trace、時序指標metric、日志明細log進行有機融合構建體系化觀測體系，通過無侵入采集動態插碼技術降低業務觀測成本。同時提供豐富的業務應用視角的觀測手段包括依賴分析、性能剖析、故障排錯及根因定位，實現從被動感知到主動觀測、從被動響應到主動觀測體系建設的思維模式轉變，從而達到了解已知、防范風險、探索未知的觀測目標。

監控可類比中醫基于脈搏時序檢測依賴人為經驗判斷，依賴經驗豐富的工程師；可觀測類比西醫，通過各種觀測手段rum、apm、日志、基礎監控構建全量觀測體系白盒診斷，讓醫生對系統實時進行全面體檢，發現問題所在。

02. 云原生時代應用可觀測問題

云原生應用架構在落地敏捷開發、快速迭代、彈性伸縮的同時將原有的單體應用拆分成多個獨立部署相互通信的組合應用，應用數量指數增長業務模塊間的依賴關系錯綜復雜，不同業務層級不同維度難以建立實時有效關聯的映射關系；同時，隨著容器頻繁啟停監控對象及其指標變化成為常態故障現場難以留存、故障問題難以有效定位。以上云原生架構的觀測難點給應用運維的故障分析、根因定位、業務連續穩定帶來嚴峻挑戰。云原生應用觀測難點概述為以下兩點：

1）信息維度復雜，難以建立多維數據關聯映射關系

云原生應用的監控度量涉及應用進程、中間件、容器編排平臺、容器進程、資源基礎設施等相關層級資源屬性和性能指標；其次，應用排障及性能剖析涉及多個服務、多個組件復雜交互關系，需根據請求鏈路依賴關系分析故障根因。

2）架構動態變化，故障現場難以留存問題難以定位

伴隨業務規模和復雜度提升需要對服務不斷進行拆分，軟件架構的變化成為常態；容器部署架構基于聲明式面向終態的設計思想，部署資源實例對象變更頻繁，服務節點飄逸成為常態。基于多維明細數據和指標數據關聯映射構建的運行時觀測分析矩陣能有效回溯歷史故障現場。

03. 云原生觀測體系核心建設路徑

1）統一觀測模型、建立觀測標準

面向云原生體系下不同的觀測組件、多維的觀測數據汗牛充棟，如何將不同的觀測組件和觀測數據進行有機融合建立統一觀測模型、構建觀測標準是建立云原生觀測體系首要解決的核心問題。Peter Bourgon 在2017年2月撰寫了一篇簡明扼要的文章， 叫 “Metrics, tracing, and logging” 首次提出可觀測的三大支柱將觀測數據按數據類型和應用場景劃分為鏈路數據 trace 、時序指標數據 metric、明細日志文本數據log 。鏈路數據trace基于特定標識提供單筆請求的全量調用路徑自動構建系統運行時軟件架構，提供清晰排障路徑。時序指標數據 metric 是用戶觀測系統狀態和變化趨勢，基于數據波動可有效發現異常，但無法用于根因定位。明細日志文本數據 log 應用運行過程的現場留存，保留完整業務執行明細，是業務排障主要來源。如何將三者進行有機統一，相互融合打造統一觀測體系，核心分為以下三點：

① 統一觀測對象建模

建立全局統一觀測對象模型（可基于CMDB），構建多維業務對象級聯關系，方便數據的定位尋址。

② 數據關聯打標

在日志明細中埋入traceid和spanid，metric指標上報埋入業務對象標簽。

③ 構建時間范圍統計關系

提供基于時間統計維度依賴對象間的下鉆分析能力

呈現效果：

2）構建以應用為中心的性能評估模型

不同維度的觀測數據統一接入后需要對數據進行清洗、關聯、聚合，構建以應用為中心將trace、metric、log多維數據融合的應用性能評價體系，從而基于業務視角統一性能評價標準主動發現性能瓶頸、快速感知故障、高效故障恢復，保障應用系統連續穩定。

3）挖掘持續觀測運維決策反饋的應用場景

以應用為中心將性能指標、運行日志、服務事件、請求鏈路進行統計聚合、關聯分析、建立服務全景觀測中樞，實現服務性能度量、預測，提供故障根因及性能分析依據。聯動標準運維能力及AI賦能加持，基于性能觀測度量結果構建清晰運維決策鏈路，聯動應用發布、故障處置、容災演練、服務治理構建持續觀測、優化改進的雙向閉環反饋機制，保障系統連續穩定。