構建適合組織的雲原生可觀測性能力
CNCF 在雲原生的定義 [1] 中，將可觀測性（Observability）明確爲一項必備要素。因此，使用雲原生應用架構，享受其帶來的效率提升時，不得不面對的是如何構建匹配的可觀測性能力。發展到今日，可觀測性在開源和商業上已經有了大量的解決方案拼圖，CNCF Cloud Native Landscape[2]中相關內容更是多達上百個。本文總結了可觀測性能力的成熟度模型，希望能爲組織選擇適合自身的可觀測性方案提供指導。
1.0 | 支柱：基礎的可觀測性
時間回到 2017 年，Peter Bourgon 一篇博文總結了可觀測性的三大支柱：指標（Metrics）、追蹤（Tracing）、日誌（Logging）[3]。此後幾年間這個觀點受到了業內的廣泛認可，發展爲對可觀測性能力的基本要求，並且每一個方面都有了衆多成熟的解決方案。例如，開源組件中就有聚焦於 Metrics 的 Prometheus、Telegraf、InfluxDB、Grafana 等，聚焦於 Tracing 的 Skywalking、Jaeger、OpenTracing 等，聚焦於 Logging 的 Logstash、Elasticsearch、Loki 等。
構建三大支柱是可觀測性能力建設的初級階段，基於開源組件很容易爲每個業務系統搭建一套開箱即用的可觀測性設施。這個階段面臨的主要問題有兩個：
1）數據孤島： 當團隊面臨一個業務故障時，可能需要頻繁跳轉於 Metrics、Tracing、Logging 系統之間，由於這些系統上的數據並沒有很好的關聯打通，整個問題排查流程高度依賴人工的信息銜接，有些時候可能還需要協調負責不同系統的不同人員參與問題排查。
2）建設冗餘： 由於觀測數據的採集依賴 StatsD 插樁、Tracing SDK 插樁、Logging SDK 插樁，處於這個階段的可觀測性能力一般以業務開發團隊爲核心驅動構建，業務部門只會構建服務於自身的觀測設施，導致在不同業務部門之間重複構建。另一方面，開箱即用的方案往往存在擴展性問題，難以成長爲面向所有業務提供的基礎服務。
2.0 | 服務：統一的可觀測性
當觀測數據的打通和觀測系統的優化在日常運維工作中越來越頻繁時，意味着我們需要準備提升可觀測性能力到下一個等級了。這個等級的可觀測性以服務爲核心，由基礎設施團隊和業務開發團隊協作。基礎設施團隊需要打造一個面向所有業務的統一可觀測性平臺，提供 Metrics、Tracing、Logging 數據的採集、存儲、檢索基礎設施，並支持將不同類型的數據進行關聯以消除孤島。業務開發團隊作爲消費方，利用統一 SDK 在此平臺上注入觀測數據。
首先我們面臨的問題是採集時如何關聯不同類型的數據，OpenTelemetry[4] 通過標準化數據的採集和傳輸期望解決此問題。遵循 OpenTelemetry 規範，我們可以看到 Metrics 可通過 Exemplars 關聯至 Trace，Trace 通過 TraceID、SpanID 關聯至 Log，Log 通過 Instance Name、Service Name 關聯至 Metrics。OpenTelemetry 社區已經完成了 Tracing 規範的 1.0 版本，並計劃在 2021 年完成 Metrics 規範、2022 年完成 Logging 規範。這是一個高速發展中的項目，但得到了業界大量的關注和認可，也能看出可觀測苦數據孤島久矣！
其次，我們還面臨着不同類型數據的存儲問題，遺憾的是這方面 OpenTelemetry 並未涉及。Metrics 和 Trace/Log 數據有着較大的區別，通常採用 TSDB（如 InfluxDB）存儲 Metrics 數據，Search Engine（如 Elasticsearch）存儲 Trace/Log 數據。爲了提供一項統一的可觀測平臺服務，系統需要具備水平擴展能力，但 TSDB 由於高基問題通常難以用於存儲精細至每個微服務、API 的指標數據，而 Search Engine 由於全文索引問題通常會帶來高昂的資源開銷。解決這兩個問題一般考慮選擇基於稀疏索引的實時數倉，例如 ClickHouse 等，並通過對象存儲機制實現冷熱數據分離。
除此之外，觀測系統成爲統一服務的更大挑戰還在於，它需要比業務系統有更強的水平擴展能力。例如，在混合雲、邊緣雲等複雜環境中，觀測系統應該能擴展至多個 Region/AZ 以及邊緣機房，使得可全鏈路監控複雜業務。
解決了數據的採集和存儲問題後，基礎設施團隊可將觀測系統作爲一項統一服務向業務開發團隊開放，但這個階段的可觀測性依然有兩個問題未能解決：
1）團隊耦合： 觀測能力作爲一項服務（Service），必須由業務開發團隊主動調用（Call），但業務保障的 KPI 由運維團隊承擔，並不直接落在開發團隊上。在雲原生架構應用的高速迭代背景下，是否每一次業務上線都能做到對觀測服務的 100% 調用？即使開發團隊能嚴守規則，整個事情的主動權也並沒有落在運維團隊手上。另外站在開發團隊的視角，業務代碼中不得不插入各式各樣的由運維團隊強制要求的 SDK 調用。
2）觀測盲點： 應用架構中涉及到的所有軟件服務並不是每一行代碼都由開發團隊編寫，因此侵入式的代碼打樁手段勢必會遇到觀測盲點。例如兩個微服務通信路徑上的 API 網關、iptables/ipvs、宿主機 vSwitch、SLB、Redis 緩存服務、MQ 消息隊列服務等，都無法通過插碼的方式植入式獲取觀測收據。
3.0 | 原力：內生的可觀測性
當開發與運維的團隊的耦合問題開始制約組織發展，當基礎服務的觀測盲點問題開始制約業務 SLO 進一步提升時，意味着我們需要再一次提升可觀測性能力等級了。
既然每一個雲原生應用都需要可觀測性能力，那麼我們能否讓基礎設施內生地提供這樣的能力，它就像原力（The Force）一樣，無處不在。因此，方向明朗了：如果業務代碼中不插入任何一行觀測代碼，我們能獲得多少可觀測能力？這個階段的主要挑戰來自於數據的採集和存儲。
如何實現基礎設施內生的應用觀測數據採集能力？一種 Green Field 的思路是通過服務網格實現。我們可以看到，無論是純正的服務網格如 Istio，還是更激進的應用運行時如 Dapr，都從設計之初就考慮了可觀測性能力。假如微服務之間的訪問路徑都經過服務網格，那麼可以從基礎設施層面解決觀測數據的採集問題。這裏的主要挑戰來自於對應用架構的改變——應用需全部遷移到服務網格架構。但即使依靠服務網格，也依然會存在中間件、數據庫、緩存、消息隊列等系統上的觀測盲點。或許等到服務網格像 TCP 一樣——變成網絡協議棧的一層時 [5]，我們能通過這種方法實現內生的可觀測性。
另一種 Brown Field 的解決思路是藉助 BPF 零侵入、無處不在的觀測能力。BPF 是一項內生於 Linux Kernel 中的觀測技術，經典 BPF（cBPF）主要聚焦於網絡流量的過濾獲取，但在 Kernel 4.X 版本中已經得到了巨大的增強（eBPF）。利用 eBPF，無需修改業務代碼、無需重啓業務進程，可端到端地觀測每一個 TCP/UDP（kprobe）、HTTP2/HTTPS（uprobe）函數調用；利用 cBPF，從網絡流量中提取每一次服務訪問的 Metrics、Tracing、Logging 觀測數據，可全鏈路地觀測服務間通信在流經虛擬機網卡、宿主機網卡、SLB 等中間設備時的性能數據。隨着 Linux Kernel 4.X 越來越廣泛的應用，我們看到雲監控泰斗 Datadog 最近剛剛發佈了基於 eBPF 的 Universal Service Monitoring（USM）零侵入監控能力 [6]，國內阿里雲 ARMS 團隊也在最近發佈了基於 eBPF 的零侵入監控產品 Kubernetes 監控 [7]，開源社區方面 Skywalking v9 也開始關注 eBPF[8]。但請注意僅僅依靠 eBPF 會存在依賴 4.X Linux 內核的問題，導致有可能退化爲一種 Green Field 方案。原力需要無處不在，網絡流量早已無處不在！
數據存儲的挑戰實際上和全鏈路監控相關。從應用代碼出發的可觀測性往往僅考慮業務和應用層面的問題，網絡、基礎設施成爲盲點。在中間路徑上（API 網關、iptables/ipvs、宿主機 vSwitch、SLB、Redis 緩存服務、MQ 消息隊列服務）採集到的觀測數據如何能與應用和業務層面的觀測數據打通，需要我們構建一個面向微服務的知識圖譜。通過與雲平臺 API、K8s apiserver 以及服務註冊中心同步資源和服務信息，爲每個微服務構建區域 / 可用區、VPC / 子網、雲服務器 / 宿主機、容器集羣 / 節點 / 工作負載、服務名 / 方法名等多維度知識圖譜信息，作爲數據標籤附加於觀測數據之上，從而打通全鏈路上各個層面的 Metrics、Tracing、Logging 數據。
當你到達第 3 級時，可觀測性已經成爲了雲基礎設施上內生的能力，像原力一樣，它蘊含在已運行的每個應用系統、以及未來會新增的每個應用系統中，是一項與生俱來的基本能力，這項能力無需依賴於在業務代碼中的 “調用” 來觸發，它就在那裏。
DeepFlow 在可觀測性 3.0 等你。May the force be with you！
參考文獻
[1] CNCF Cloud Native Definition v1.0
[2] CNCF - Cloud Native Landscape
[3] Metrics, tracing, and logging
[4] OpenTelemetry - Overview
[5] 從 SDN 到第 5 層網絡
[6] Datadog - Golden Signals in Seconds With Universal Service Monitoring
[7] 阿里雲 ARMS - Kubernetes 監控
[8] SkyWalking OAP server v9 Core
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/20fkU3doFK4WfXpe5vKtZQ