解讀：雲原生下的可觀察性發展方向

前言

非常有幸參加了雲原生社群Meetup北京站，有機會和衆多業内的大牛一起讨論雲原生相關的技術和應用，本次Meetup上我和大家分享了關于雲原生下的可觀察性相關的議題，相關的視訊可以移步《

B站視訊回放：雲原生下的可觀察性

》回看，本篇文章主要是視訊的文字性總結，歡迎大家留言讨論。

可觀察性的由來

可觀察性最早來自于電氣工程領域，主要原因是随着系統發展的逐漸複雜，必須要有一套機制用來了解系統内部的運作狀态以便更好的監控和問題修複，為此工程師們設計了很多傳感器、儀表盤用于表現系統内部的狀态。

A system is said to be observable if, for any possible evolution of state and control vectors , the current state can be estimated using only the information from outputs.

電氣工程發展了上百年，其中各個子領域的可觀察性都在進行完善和更新，例如交通工具（汽車/飛機等）也算的是可觀察性上的集大成者。抛開飛機這種超級工程不談，一輛可正常上路的小型汽車内部也有上百種的傳感器用來檢測汽車内/外部的各種狀态，以便讓汽車可以穩定、舒适、安全地的行駛。

可觀察性的未來

随着上百年的發展，電氣工程下的可觀察性已經不僅僅用來輔助人們進行問題檢查和定位問題，我們以汽車工程來看，整個可觀察性的發展經曆了幾個過程：

1. 盲目：1886年1月29日德國人卡爾·本茨發明了人類史上第一輛汽車，那個時候的汽車僅僅具備行駛的最基礎能力，根本沒有任何和可觀察性相關的事情。
2. 傳感器：随着後來汽車開始正式進入市場，人們需要更好的知道汽車是不是沒油了、沒水了，是以基礎的傳感器儀表盤被發明出來。
3. 告警：為了更好的保證汽車的形式安全性，人們開始使用自檢和實時告警系統來主動向駕駛員通知一些異常資訊，比如電瓶沒電、水溫過高、胎壓低、刹車片磨損等。
4. 輔助：雖然告警能夠即時發出，但有時候人還是來不及處理或者不想處理，這時候輔助系統就派上了用場，例如定速巡航、主動安全、自主泊車等。這些輔助系統是把傳感器+自動控制進行結合，能夠部分解決駕駛員可能做不到或者不想做的事情。
5. 自動駕駛：上述這些功能最終還是要人去參與，而自動駕駛可以完全不需要人的參與，直接是可觀察性系統+控制系統就可以讓汽車自動運作起來。

自動駕駛的核心要素

作為電氣工程上可觀察性的巅峰，自動駕駛将汽車擷取到的各類内外部資料發揮到極緻，總結起來主要有幾下幾個核心的要素：

1. 豐富的資料源：汽車外圍遍布多個雷射/圖像雷達，能夠實作高幀率、360°實時觀測周圍的物體及其狀态；内部則能夠實時知道目前的車速、車輪角度、胎壓等資訊，做到知彼知己。
2. 資料集中化：相對輔助駕駛能力，自動駕駛的一個核心突破是能夠将車内外的所有資料集中到一起去處理，真正發揮出資料的價值，而不是每個子產品的資料作為孤島進行獨立運作。
3. 強大算力：集中化的資料也意味着資料量的急劇膨脹，無論哪家自動駕駛背後都有強大的晶片支撐，隻有足夠的算力才能保證在最短的時間内可以進行足夠的計算。
4. 軟體疊代：算力+算法構成了智能化的最終目标，然而算法不可能完美無瑕，我們會根據逐漸積累的自動駕駛資料不斷進行算法的更新，使軟體系統能夠不斷的更新以獲得更佳的自動駕駛效果。

IT系統的可觀察性

伴随着幾十年的發展，IT系統中的監控、問題排查也逐漸抽象為可觀察性工程。在當時，最主流的方式還是使用Metrics、Logging、Tracing的組合。

上面這幅圖詳細大家非常熟悉，這是Peter Bourgon在參加完2017 Distributed Tracing Summit後發表的一篇博文，簡潔扼要地介紹了Metrics、Tracing、Logging三者的定義和關系。這三種資料在可觀察性中都有各自的發揮空間，每種資料都沒辦法完全被其他資料代替。

以Grafana Loki中介紹中的一個典型問題排查過程來看：

1. 最開始我們通過各式各樣的預設報警發現異常（通常是Metrics/Logging）
2. 發現異常後，打開監控大盤查找異常的曲線，并通過各種查詢/統計找到異常的子產品（Metrics）
3. 對這個子產品以及關聯的日志進行查詢/統計分析，找到核心的報錯資訊（Logging）
4. 最後通過詳細的調用鍊資料定位到引起問題的代碼（Tracing）      

上述例子介紹了如何使用Metric、Tracing、Logging去聯合排查問題，當然根據不同的場景可以有不同的結合方案，例如簡單的系統可以直接通過日志的錯誤資訊去告警并直接定位問題，也可以根據調用鍊提取的基礎名額（Latency、ErrorCode）觸發告警。但整體而言，一個具有良好可觀察性的系統必須具備上述三種資料。

雲原生下的可觀察性

雲原生帶來的不僅僅是應用部署能夠部署雲上而已，其整個的定義是一套新的IT系統架構更新，包括開發模式、系統架構、部署模式、基礎設施全套的演進和疊代。

1. 效率要求更高：随着DevOps模式的普及，規劃、開發、測試、傳遞..的效率要求越來越高，而與之帶來的問題是需要更加實時的知道此次的釋出是否成功，出現了什麼問題，問題在哪裡，如何快速去解決。
2. 系統更加複雜：架構從最開始的一體化發展到分層模式，到現在的微服務模式，架構的更新帶來了開發效率、釋出效率、系統靈活性、魯棒性等優勢，但随之而來系統的複雜度将更高，問題的定位将更加難。
3. 環境動态性增強：無論是微服務的架構還是容器化的部署模式，帶來的一個特性是環境的動态性會增強，每個執行個體的生命周期會更短，出現問題後往往現場已經被破壞，登入機器排查問題的方式已經不複存在。
4. 上下遊依賴更多：問題的定位最終都會從上下遊來排查，在微服務、雲、K8s的環境中，上下遊将更加多，包括各類其他業務應用、雲上使用的各類産品、各種中間件、K8s自身、容器運作時、虛拟機等等。

拯救者：OpenTelemetry

上述的這些問題相信很多讀者都會深有體會，而業界也針對這種情況退出了各類可觀察性相關的産品，包括開源、商業化的衆多項目。例如：

1. Metrics：Zabbix、Nagios、Prometheus、InfluxDB、OpenFalcon、OpenCensus
2. Tracing：Jaeger、Zipkin、SkyWalking、OpenTracing、OpenCensus
3. Logging：ELK、Splunk、SumoLogic、Loki、Loggly

利用這些項目的組合或多或少可以解決針對性的一類或者幾類問題，但真正應用起來你會發現各種問題：

1. 多套方案交織：可能要使用至少Metrics、Logging、Tracing3種方案，維護代價巨大
2. 資料不互通：雖然是同一個業務元件，同一個系統，産生的資料由于在不同的方案中，資料難以互通，無法充分發揮資料價值
3. 廠商綁定：無論從資料采集、傳輸、存儲、計算、可視化、告警等都可能會被廠商綁定，可觀察性系統一旦上線後替換的代價講巨大無比
4. 雲原生不友好：這些方案其中很多都是針對傳統系統的，對于雲原生的支援相對較弱，而且方案本身部署和使用代價都很高，不符合“雲原生”這種一鍵部署、開箱即用的使用方式。

在此背景下，雲原生基金會CNCF下誕生了OpenTelemetry項目，旨在将Logging、Tracing、Metrics三者進行統一，實作資料的互通互操作。

Create and collect telemetry data from your services and software, then forward them to a variety of analysis tools.

OpenTelemetry最核心的功能是産生、收集可觀察性資料，并支援傳輸到各種的分析軟體中，整體的架構如下圖所屬，其中Library用于産生統一格式的可觀察性資料；Collector用來接收這些資料，并支援把資料傳輸到各種類型的後端系統。

OpenTelemetry給雲原生下帶來的革命性的進步，包括：

1. 統一協定：OpenTelemetry為我們帶來了Metric、Tracing、Logging（正在制定中，LogModel已經定義完畢）的統一标準，三者都有相同的中繼資料結構，可以輕松實作互相關聯
2. 統一Agent：使用一個Agent即可完成所有可觀察性資料的采集和傳輸，不需要為每個系統都部署各種各樣的Agent，大大降低了系統的資源占用，使整體可觀察性系統的架構也變的更加簡單
3. 雲原生友好：OpenTelemetry誕生在CNCF，對于各類的雲原生下的系統支援更加友好，此外目前衆多雲廠商已經宣布支援OpenTelemetry，未來雲上的使用會更加便捷
4. 廠商無關：此項目完全中立，不傾向于任何一家廠商，讓大家可以有充分的自由來選擇/更換适合自己的服務提供商，而不需要收到某些廠商的壟斷或者綁定
5. 相容性：OpenTelemetry得到了CNCF下各種可觀察性方案的支援，未來對于OpenTracing類、OpenCensus、Prometheus、Fluntd等都會有非常好的相容性，可以友善大家無縫遷移到OpenTelemetry方案上。

OpenTelemetry限制

從上面的分析來看，OpenTelemetry的定位是作為可觀察性的基礎設施，解決資料規範與擷取的問題，後續部分依賴各個Vendor來實作。當然最佳的方式是能夠有一個統一的引擎去存儲所有的Metrics、Logging、Tracing，有一個統一的平台去分析、展示、關聯這些資料。目前的話還沒有一個廠商能夠非常好的支援OpenTelemetry的統一後端，現在還是需要自己去使用各個廠商的産品來實作。而這個帶來的另一個問題是各個資料的關聯會更加複雜，還需要去解決每個廠商之間的資料關聯性問題。當然這個問題相信在1-2年肯定會解決掉，現在有衆多廠商開始在努力實作OpenTelemetry所有類型資料的統一方案。

可觀察性的未來方向

我們團隊從剛開始09年做飛天5K項目起，就一直在負責監控、日志、分布式鍊路追蹤等可觀察性相關的工作，中間經曆過小型機到分布式系統再到微服務、雲化的一些架構變更，相關的可觀察性方案也經曆了很多演變。我們覺得整體上可觀察性相關的發展和自動駕駛等級的設定非常吻合。

自動駕駛一共分為6級，其中0-2級主要還是靠人來進行決定，到了等級3之後就可以進行無意識駕駛，也就是手眼可以暫時性不用關注駕駛，到了等級5的話人就可以完全脫離駕駛這個枯燥的工作，在車上可以自由活動。

在IT系統的可觀察性上，也可以類似劃分6級：

• 等級0：手工分析，依靠基礎的Dashboard、告警、日志查詢、分布式鍊路追蹤等方式進行手動告警、分析，也是目前絕大部分公司使用的場景
• 等級1：智能告警，能夠自動去掃描所有的可觀察性資料，利用機器學習的方式去識别一些異常并進行自動告警，免去人工設定/調整各種基線告警的工作
• 等級2：異常關聯+統一視圖，對于自動識别的異常，能夠進行上下文的關聯，形成一個統一的業務視圖，便于快速的定位問題
• 等級3：根因分析+問題自愈，自動根據異常以及系統的CMDB資訊直接定位問題的根因，根因定位準确後那邊可以去做問題的自愈。這一階段相當于是一次質的飛躍，在某些場景下可以在人不用參與的情況下實作問題的自愈。
• 等級4：故障預測，故障發生總會有損失，是以最好的情況是避免故障的發生，是以故障預測技術可以更好的來保證系統的可靠性，利用之前積累的一些故障先兆資訊做到“未蔔先知”
• 等級5：變更影響預測，我們知道絕大部分的故障都是由變更引起的，是以如果能夠模拟出每個變更對系統帶來的影響以及可能産生的問題，我們就能夠提前評估出是否能夠允許此次變更。

  

阿裡雲SLS在可觀察性相關的工作

目前我們SLS正在開展雲原生可觀察性的工作，基于OpenTelemetry這個未來雲原生下可觀察性的标準，實作各類可觀察性資料的統一收集，覆寫各個資料源和各類資料類型，做到多語言支援、多裝置支援、類型統一；向上我們會提供能夠支援各類可觀察性資料的統一存儲和計算能力，支援PB級存儲、ETL、流計算、百億級資料秒級分析，為上層算法提供強大的算力支撐；IT系統的問題非常複雜，尤其涉及到不同的場景和架構，是以我們把算法和經驗結合起來進行異常的分析，算法包括基礎的統計學、邏輯性算法，也包括AIOp相關的算法，經驗中包括人工輸入的專家知識、網上上積累的各類問題解決方案以及外部産生的一些事件；最上層我們會提供一些輔助決策的功能，例如告警通知、資料可視化、Webhook等，此外會提供豐富的外部內建能力，例如對接三方的可視化/分析/告警系統，提供OpenAPI以便不同的應用方內建。

總結

作為CNCF下除了Kubernetes外最活躍的項目，OpenTelemetry受到了各大雲廠商以及相關解決方案公司的關注，相信未來一定會成為雲原生下可觀察性的标準。雖然目前還沒有到生産可用的程度，但是目前各個語言的SDK和Collector也基本上穩定，在2021年就能夠釋出生産可用的版本，值得大家期待。

而OpenTelemetry隻是定義了可觀察的前半部分，後面還有非常多的複雜工作需要我們去實作，任重道遠。

重點來了！！！！SLS團隊長期招聘人才，歡迎對大資料、監控、可觀察性、前端可視化、移動端開發、機器學習等有興趣的同學前來聯系我。

參考：

1. https://opentelemetry.io/
2. https://developer.aliyun.com/article/766070
3. https://aiopsworkshop.github.io/
4. https://landscape.cncf.io/
5. https://www.instana.com/blog/observability-vs-monitoring/