構建可觀測性的核心能力是什么？

云原生時代，企業從單體架構發展到分布式架構，廣泛采用微服務、容器、Serverless等部署方式，IT基礎設施變得愈發不可控。

這導致傳統的監控技術和工具很難跟蹤這些分布式架構中的通信路徑和相互依賴關系，更別提排查問題并定位根本原因了。

Gartner認為數字化轉型以業務為中心，服務和用戶體驗是關鍵目標。而IT監控以系統可用為中心，僅關注系統可用性指標對于轉型中的企業而言是一場災難。到2023年，依賴于“正常運行時間”指標的監控實踐將抑制90%的轉型計劃。

當監控無法再單獨以運維的視角、被動地解決故障為目標，而要追隨IT架構的改變和云原生技術的實踐，融入開發與業務部門的視角，具備比原有監控更廣泛、更主動的能力，“可觀測性”概念誕生了。

“可觀測性”究竟是什么？實現“可觀測性”的核心能力有哪些？

2018年，可觀測性（Observability）被引入IT領域，CNCF-Landscape率先出現了Observability的分組。自此以后，“可觀測性”逐漸取代“監控”，成為云原生技術領域最熱門的話題之一。

近兩年，可觀測性紅遍IT運維領域，火起來的導火索是CNCF在云原生定義中提到 Observerbility，并聲稱這是云原生時代的必備能力。加之包括谷歌在內的眾多大廠一擁而上，“可觀測性”正式出道。

谷歌給出可觀測性的核心價值很簡單：快速排障（troubleshooting）。

隨著系統越來越精細，越來越復雜，越來越動態，越來越龐大，潛藏的問題和風險也就越來越多。因此，任何一個軟件的成功，不僅僅要依靠軟件架構的合理設計、軟件開發的代碼質量，更要依靠軟件系統的運行維護。而運行維護的基礎，就是可觀測性，通過提前發現異常，快速定位根本原因，迅速排除或者規避故障。

因此，可觀測性是從系統內部出發，基于白盒化的思路去監測系統內部的運行情況。可觀測性貫穿應用開發的整個聲明周期，通過分析應用的指標、日志和鏈路等數據，構建完整的觀測模型，從而實現故障診斷、根因分析和快速恢復。

雖然可觀測性是由傳統監控發展而來，但是他們有著本質的不同。

傳統監控更多的是指運維自動化工具，主要用途是替代人自動監控系統運行情況，在系統發生異常時告警，最終還是需要人工去分析異常、故障診斷和根因分析。

但現代IT系統的關鍵詞是分布式、池化、大數據、零信任、彈性、容錯、云原生等，越來越龐大，越來越精細，越來越動態，同時也越來越復雜。通過人去尋找各種信息的關聯性，再根據經驗判斷和優化，顯然是不可行的，耗時耗力還無法找到問題根因。

可觀測性不僅包含傳統監控的能力，更多的是面向業務，強調將業務全過程透明化的理念，實現全景監控、智能運維和自修復能力等體系化的服務能力。

有業界專家一句話總結傳統監控與可觀測性的區別：“監控告訴我們系統的哪些部分是工作的；可觀測性告訴我們那里為什么不工作了。” 

在CNCF對于云原生的定義中，已經明確將可觀測性列為一項必備要素。

CNCF云原生生態也整合了可觀測性體系，在CNCF生態全景圖中可觀測性主要是按照 Monitoring監控指標、Logging事件日志、Tracing鏈路追蹤三個維度來分類。

 監控指標（Monitoring）

云原生監控指標可觀測產品大都是從傳統的監控產品發展而來的，傳統監控中Zabbix以其高可用和圖形化展示而廣受歡迎。

而在云原生時代，CNCF孵化的監控工具Prometheus取代了以Zabbix為代表的眾多傳統監控工具，已基本成為云原生監控體系通用的解決方案，并可以通過配合Grafana工具實現監控數據圖形化進行可視化分析。

 事件日志（Logging）

在業界中，事件日志可觀測產品也已經是一片紅海。日志管理方案大都包含日志收集、日志聚合、日志存儲與分析幾個模塊，具體過程是日志收集工具與應用程序容器一起運行，并直接從應用程序收集消息，然后將消息轉發到中央日志存儲以進行匯總和分析。

在這方面Elastic Stack日志解決方案獨占鰲頭，幾乎覆蓋了日志管理的全流程，其中一大變數是用于日志聚合、過濾等業務的Logstash效能較差，在未來可能會被CNCF孵化的Fluentd取代。

 鏈路追蹤（Tracing）

比起監控日志與事件日志，鏈路追蹤可觀測的產品競爭要相對激烈得多。其根本原因在于鏈路數據與實際業務和業務實現協議、編程語言等細粒度具體場景密切相關。

這也導致針對不同產品實現和網絡協議的鏈路追蹤產品層出不窮，但是他們在功能實現上并沒有太本質的差距，卻又受制于實現細節，彼此互斥，很難搭配工作。

傳統的工具是垂直向的，在引入一個新的組件的同時也會引入一個與之對應的觀測工具。盡管保證了數據的全面性，但丟失了數據的關聯性和分析排查的連貫性。

如果有一個統一的數據平臺，把所有數據放在一個平臺，似乎就能解決關聯性的問題。

但實際情況往往是，建立了一個觀測指標、日志、鏈路的統一平臺，數據堆在了一個地方，用的時候還是按傳統的方式各看各的，關聯性還得靠人的知識和經驗。

因此，可觀測性能力的構建，最關鍵的其實是解決數據統一和關聯的問題：把之前需要人去比對、過濾的事交給程序去處理，人的時間更多的用在判斷和決策上。

中國信通院《可觀測性技術發展白皮書》指出，可觀測平臺能力的構建，需要具備統一數據模型、統一數據處理、統一數據分析、數據編排、數據展示的能力。

那么，如何做數據統一和關聯呢？

在統一數據平臺上，由于數據是來自于各種觀測工具的，雖然在數據格式上統一了，但不同工具的元數據截然不同。如果在統一數據平臺上去梳理和映射這些元數據，將是龐雜、難維護、不可持續的。

那么該如何做呢？答案就是標準化。

只有將標準化、結構化的數據喂給觀測平臺，觀測平臺才能從中發現巨大價值。統一數據平臺只是在數據格式上進行了標準化，而要想將數據關聯還必須建立context的標準化，context就是數據的空間信息，再疊加上時間信息的關聯就可以發揮真正的觀測價值。

目前，CNCF為了統一這一亂象，推出了Open Telemetry以期實現理想狀態下的大一統：統一Logs、Trace、Metrics三種數據協議標準，使用一個Agent完成所有可觀測性數據的采集和傳輸，適配眾多云廠商，兼容CNCF上眾多的開源與商業項目。

可以說Open Telemetry是一套與平臺無關、與廠商無關、與語言無關的追蹤協議規范，意在讓鏈路追蹤可觀測更加規范化。

但遺憾是，至今未有廠商或開源項目可以統一Open Telemetry后端，三種數據源的統一存儲、展示與關聯分析仍面臨極大挑戰，而解決以上問題的前提，仍然是統一數據源（數據格式）。

總的來說，云原生可觀測性方興未艾，因為云原生的應用系統趨于規模化和復雜化，越是復雜的龐大機器越是會強調其可靠性和穩定性。

未來，云原生可觀測未來需要一個大一統的可落地產品，通過統一的標準匯聚三者的數據，挖掘交叉區域的價值。

本文來自微信公眾號 “科技云報道”（ID：ITCloud-BD），36氪經授權發布。