構建適合組織的雲原生可觀測效能力

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級時，可觀測性已經成為了雲基礎設施上內生的能力，像原力一樣，它蘊含在已執行的每個應用系統、以及未來會新增的每個應用系統中，是一項與生俱來的基本能力，這項能力無需依賴於在業務程式碼中的“呼叫”來觸發，它就在那裡。

瞭解更多雲原生可觀測性技術實踐，歡迎關注雲杉網路主辦的 “雲原生可觀測性分享會” 系列直播活動。7 月 6 日晚 20:00～21:30，雲杉網路高階產品經理李倩老師將帶來《高清雲網可觀測之全鏈路追蹤實戰》主題分享。

活動報名：http://www.slidestalk.com/m/960/OSCjishuwenzhang