雲原生可觀察性 - 概述篇

1.1. 概述

雲原生（Cloud Native）由 Pivotal 公司 Matt Stine 於 2013 年首次提出，它代表一種構建和運行應用程序的技術和方法論，其中 “Cloud” 表示的是應用運行在雲環境之上；“Native” 則強調的是應用從設計之初就基於雲基礎設施能力，藉助雲的優勢實現更加高效強大的技術架構；

雲原生是對傳統雲計算的拓展延伸，其核心價值不再是雲計算技術本身，而是強調以業務應用爲中心的理念，充分挖掘並釋放雲對業務應用的價值，即雲是服務業務應用的基礎設施，業務應用生於雲、長於雲，進而實現雲業融合、雲隨業動、雲驅業長的本質價值。

雲原生可觀測性是從傳統軟件監控及數據分析可視化工具中，總結出在雲原生領域中，從底層容器基礎設施、通用技術組件到業務應用系統全鏈路監控運維、運營治理等產品化體系化的能力訴求。可觀測性是雲原生技術架構的重要特徵，確切的體現了雲原生的核心理念，自提出就被廣泛的認可：

2017 年，Apple 工程師 Cindy Sridharan 在 9 月發表的博文《Monitoring and Observabbility》中，首次談到雲原生監控與可觀測性的關係；

2017 年 10 月份，Matt Stine 在接受 InfoQ 採訪時將雲原生特徵重新歸納爲六大點，分別是 Modularity(模塊化)、Observability(可觀測性)、Deployability(可部署性)、Testability(可測試性)、Disposability(可處理性)、Replaceability(可替換性)；其中就包含了 Observability 可觀測性。

1.2. 可觀測性的定義

進入雲原生時代，應用的構建部署與運行時基礎設施都發生翻天覆地的變化，技術架構微服務化、運行時環境容器化、業務系統依賴關係複雜化，運行實例生命週期短，規模大；服務自動註冊發現，監控也隨着實時動態調整，傳統預先配置再監控的方式已經無法滿足雲原生的場景。

可觀測性與監控是有本質區別的，監控更多的偏向自動化工具，可以替代人自動監控系統異常；而可觀測性不僅包含傳統監控的能力，更多的是面向業務，強調將業務全過程透明化的理念。

CNCF 雲原生生態也整合了可觀測性體系，將可觀測性的能力作爲雲原生底層基礎設施能力，從根本上解決了平臺與業務運維工具雜亂，能力層次不齊的問題。當前生態全景圖中是按照 Monitoring 監控、Logging 日誌 、Tracing 調用鏈三個維度來分類：

（一）Logging 日誌：結構化與非結構化的混合數據，應用運行過程會持續輸出日誌數據，這些日誌數據是業務系統運行狀態的各種事件及業務處理邏輯時輸出的，如果業務日誌比較完善，基本上可以還原業務流程處理的全過程。日誌服務主要就是收集並長時間保存日誌，如果出現事故或者其他審計需求，就可以藉助日誌服務隨時間查閱日誌信息。日誌服務由來已久，主要難點是解決大規模日誌數據採集，解析，存儲，實時檢索等問題，還有就是尋找低侵入的方式（Agent，Sidecar）來標準化輸出日誌，提高日誌數據的質量，降低業務系統日誌優化成本；目前業內常見的 ELK Stack 是日誌服務的大成者。ELK Stack 在雲原生場景主要是解決日誌採集適配，監聽容器運行變化，靈活穩定有效地採集容器化應用的運行時日誌即可。

（二）Tracing 調用鏈：結構化與非結構化的混合數據，盡最大可能串聯單個事務內全過程的日誌數據，通過對請求打標、透傳、串聯，最終可以還原出一次完整的請求，幫助工程師分析出請求中的各種異常點；調用鏈基本上是基於谷歌 Dapper 理論來實現的，但是對業務系統要求比較高，對業務性能是有一定的影響，在單個業務系統內比較容易實現，假如在異構應用間，尤其是串聯共有云的服務組件與業務系統，業務系統前中後臺的全流程，實現非常困難。

（三）Monitoring 監控：結構化數據，描述的是在給定時間點對系統的度量，基本上分爲四大類型，分別是 Sum、Count、Last value、Histograms，監控主要是底層基礎資源運行狀態的數據，通過多維度聚合、分析和可視化展示，幫助快速理解系統資源的運行狀態。

1.3. 可觀測性的產品體系

在 CNCF 的產品能力全景圖中，可觀測性體系產品分爲 Monitoring 監控，Tracing 調用鏈，Logging 日誌，Chaos Engineering 混沌工程四大類，其中混沌工程更多的是一種可靠性工具，而不是可觀測性，所以主要討論前三大類產品體系：

（一）Logging 日誌產品體系：在雲原生環境中，日誌收集工具與應用程序容器一起運行，並直接從應用程序收集消息，然後將消息轉發到中央日誌存儲以進行彙總和分析，Fluentd 是該領域唯一的 CNCF 項目，其它廠商也提供了相應的解決方案，例如 elastic、splunk，國內廠商有專精於日誌領域的日誌易、袋鼠雲，也有綜合雲平臺的阿里雲日誌服務、騰訊雲日誌服務、七牛雲日誌服務 (Pandora) 等。

（二）Monitoring 監控產品體系：雲原生環境中的監控和傳統應用程序的監控類似，需要跟蹤指標、日誌和事件以便了解應用的運行狀況，主要區別在於雲原生環境中的某些託管對象是臨時的（例如 POD 資源對象）。CNCF 中有許多監控工具，最主要的是 Prometheus，基本成爲雲原生監控體系通用的解決方案，配合 Grafana 進行可視化分析。

（三）Tracing 調用鏈產品體系：調用鏈是一種功能強大的追蹤工具，可以對分佈式應用程序的行爲進行故障排除，實現成本較高，涉及應用代碼適配調整。CNCF 中主要的調用鏈工具是 Jaeger。

直接基於上述三個產品體系的產品及組合，可以快速的搭建可觀測性系統，但在實際使用過程會遇到各種各樣的問題，總結起來有如下幾點：

  1. 組件繁多: 針對 Monitoring、Logging、Tracing 三種場景，往往需要搭建三套獨立的系統，涉及的組件多，維護成本高；

  2. 數據不互通：同一個應用不同類型的數據被存儲在相互獨立的系統，數據不互通，難以發揮數據的最大價值；

  3. 雲原生不友好：很多組件都成熟於雲原生之前，部分組件社區發展緩慢，對於雲原生的適配支持相對較弱，而且方案本身部署和使用代價都很高，不符合 “雲原生” 這種一鍵部署、開箱即用的使用方式。

當前在雲原生環境中，大部分的事件處理還是依賴人工來串聯 Monitoring、Logging、Tracing 三個產品能力，爲了從根本上解決這個問題，CNCF 孵化了 OpenTelemetry 開源項目。該項目雄心勃勃，旨在標準統一 Monitoring、Logging、Tracing 三種體系，實現可觀測性大一統。

1.4.OpenTelemetry 開源項目

OpenTelemetry 是 CNCF 可觀測性體系孵化項目，旨在提供可觀測性領域的標準化方案，解決可觀測性的數據模型、採集、處理、導出等的標準化問題，提供與第三方廠商無關的服務。是由 OpenTracing(CNCF) 和 OpenCensus（谷歌和微軟）兩個項目合併而成，其核心工作主要集中在以下三個部分：

  1. 規範的制定和協議的統一，規範包含數據傳輸、API 的規範，協議的統一包含 HTTP W3C 的標準支持及 GRPC 等框架的協議標準

  2. 多語言 SDK 的實現和集成，用戶可以使用 SDK 進行代碼自動注入和手動埋點，同時支持對接集成第三方（Log4j、LogBack 等）；

  3. 數據收集系統的實現，當前是基於 OpenCensus Service 的收集系統，包括 Agent 和 Collector。

OpenTelemetry 核心功能是產生、收集可觀測性數據，並支持傳輸到各種的分析軟件中，整體的架構如下圖，其中 Library 用於產生統一格式的可觀測性數據；Collector 用來接收數據，並支持把數據傳輸到各種類型的後端系統。

自 OpenTelemetry 推出以來，有越來越多的廠商開始關注和貢獻，國內的幾個公有云廠商可觀察性產品也開始適配 OpenTelemetry 標準。

對於開發者，基於 OpenTelemetry 可通過一套標準的方案進行 Metrics，Logging ，Tracing 的生成和導出，降低開發過程中對不同類型觀測數據的使用成本，也降低對接不同後端服務的成本，如開源項目 Prometheus 或第三方雲廠商的服務。

對於 SRE，基於 OpenTelemetry 可爲觀測數據提供一套標準的採集、處理、導出流程，並在處理環節根據團隊需求規範化觀測數據，便於後續採用標準化的方案使用觀測數據，如監控、告警服務。

同時，不論對於開發者還是 SRE，均可以通過社區的力量持續迭代對可觀測性問題域的理解，吸收社區的技術紅利，並將生產中產生的最佳實踐回饋社區，更好推動可觀測性領域的發展。

1.5. 總結

總的來說，雲原生可觀測性還處在發展起步階段，各個領域都有極爲成熟的大一統的產品，例如監控有 Prometheus，日誌有 ELK 或者 EFK，調用鏈有 Jaeger；   目前日誌及監控產品已經趨於規範和穩定，但是產品由於發展時間長，導致目前規範體系很難統一；調用鏈還處在實驗階段，最大的問題是在大規模分佈式場景下業務全鏈路是跨客戶端，網絡，中後臺服務，想要把真實業務全過程鏈路數據都收集串聯起來，幾乎不肯能實現，尤其是目前很多業務是跨雲跨地域場景。另一個方面就是需要大一統的可落地產品，通過統一的標準匯聚三者的數據，挖掘交叉區域的價值。

OpenTelemetry 是雲原生可觀測性體系唯一希望，尤其是協議及標準，發展中尚未大一統的領域都非常需要標準，有了標準之後就需要所有參與者放棄原有個性化的協議，遵守大一統的標準，分久必合合久必分，看似輕鬆實際非常艱鉅事情；OpenTelemetry 過於理想，演進完善還有很長的路，來日方長，未來可期。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/i86PdUUzNgeKvgr1P6D4OQ

猜你喜歡