簡介： 非常有幸參加了雲原生社區Meetup北京站，有機會和衆多業內的大牛一起討論雲原生相關的技術和應用，本次Meetup上我和大家分享了關於雲原生下的可觀察性相關的議題，本篇文章主要是視頻的文字性總結，歡迎大家留言討論。
可觀察性的由來
可觀察性最早來自於電氣工程領域，主要原因是隨着系統發展的逐步複雜，必須要有一套機制用來了解系統內部的運行狀態以便更好的監控和問題修復，爲此工程師們設計了很多傳感器、儀表盤用於表現系統內部的狀態。
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.
電氣工程發展了上百年，其中各個子領域的可觀察性都在進行完善和升級，例如交通工具（汽車/飛機等）也算的是可觀察性上的集大成者。拋開飛機這種超級工程不談，一輛可正常上路的小型汽車內部也有上百種的傳感器用來檢測汽車內/外部的各種狀態，以便讓汽車可以穩定、舒適、安全地的行駛。
可觀察性的未來
隨着上百年的發展，電氣工程下的可觀察性已經不僅僅用來輔助人們進行問題檢查和定位問題，我們以汽車工程來看，整個可觀察性的發展經歷了幾個過程：
- 盲目：1886年1月29日德國人卡爾·本茨發明了人類史上第一輛汽車，那個時候的汽車僅僅具備行駛的最基礎能力，根本沒有任何和可觀察性相關的事情。
- 傳感器：隨着後來汽車開始正式進入市場，人們需要更好的知道汽車是不是沒油了、沒水了，因此基礎的傳感器儀表盤被髮明出來。
- 告警：爲了更好的保證汽車的形式安全性，人們開始使用自檢和實時告警系統來主動向駕駛員通知一些異常信息，比如電瓶沒電、水溫過高、胎壓低、剎車片磨損等。
- 輔助：雖然告警能夠即時發出，但有時候人還是來不及處理或者不想處理，這時候輔助系統就派上了用場，例如定速巡航、主動安全、自主泊車等。這些輔助系統是把傳感器+自動控制進行結合，能夠部分解決駕駛員可能做不到或者不想做的事情。
- 自動駕駛：上述這些功能最終還是要人去參與，而自動駕駛可以完全不需要人的參與，直接是可觀察性系統+控制系統就可以讓汽車自動運行起來。
自動駕駛的核心要素
作爲電氣工程上可觀察性的巔峯，自動駕駛將汽車獲取到的各類內外部數據發揮到極致，總結起來主要有幾下幾個核心的要素：
- 豐富的數據源：汽車外圍遍佈多個激光/圖像雷達，能夠實現高幀率、360°實時觀測周圍的物體及其狀態；內部則能夠實時知道當前的車速、車輪角度、胎壓等信息，做到知彼知己。
- 數據集中化：相對輔助駕駛能力，自動駕駛的一個核心突破是能夠將車內外的所有數據集中到一起去處理，真正發揮出數據的價值，而不是每個模塊的數據作爲孤島進行獨立運作。
- 強大算力：集中化的數據也意味着數據量的急劇膨脹，無論哪家自動駕駛背後都有強大的芯片支撐，只有足夠的算力才能保證在最短的時間內可以進行足夠的計算。
- 軟件迭代：算力+算法構成了智能化的最終目標，然而算法不可能完美無瑕，我們會根據逐漸積累的自動駕駛數據不斷進行算法的升級，使軟件系統能夠不斷的升級以獲得更佳的自動駕駛效果。
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系統架構升級，包括開發模式、系統架構、部署模式、基礎設施全套的演進和迭代。
- 效率要求更高：隨着DevOps模式的普及，規劃、開發、測試、交付..的效率要求越來越高，而與之帶來的問題是需要更加實時的知道此次的發佈是否成功，出現了什麼問題，問題在哪裏，如何快速去解決。
- 系統更加複雜：架構從最開始的一體化發展到分層模式，到現在的微服務模式，架構的升級帶來了開發效率、發佈效率、系統靈活性、魯棒性等優勢，但隨之而來系統的複雜度將更高，問題的定位將更加難。
- 環境動態性增強：無論是微服務的架構還是容器化的部署模式，帶來的一個特性是環境的動態性會增強，每個實例的生命週期會更短，出現問題後往往現場已經被破壞，登錄機器排查問題的方式已經不復存在。
- 上下游依賴更多：問題的定位最終都會從上下游來排查，在微服務、雲、K8s的環境中，上下游將更加多，包括各類其他業務應用、雲上使用的各類產品、各種中間件、K8s自身、容器運行時、虛擬機等等。
拯救者：OpenTelemetry
上述的這些問題相信很多讀者都會深有體會，而業界也針對這種情況退出了各類可觀察性相關的產品，包括開源、商業化的衆多項目。例如：
- Metrics：Zabbix、Nagios、Prometheus、InfluxDB、OpenFalcon、OpenCensus
- Tracing：Jaeger、Zipkin、SkyWalking、OpenTracing、OpenCensus
- Logging：ELK、Splunk、SumoLogic、Loki、Loggly
利用這些項目的組合或多或少可以解決針對性的一類或者幾類問題，但真正應用起來你會發現各種問題：
- 多套方案交織：可能要使用至少Metrics、Logging、Tracing3種方案，維護代價巨大
- 數據不互通：雖然是同一個業務組件，同一個系統，產生的數據由於在不同的方案中，數據難以互通，無法充分發揮數據價值
- 廠商綁定：無論從數據採集、傳輸、存儲、計算、可視化、告警等都可能會被廠商綁定，可觀察性系統一旦上線後替換的代價講巨大無比
- 雲原生不友好：這些方案其中很多都是針對傳統系統的，對於雲原生的支持相對較弱，而且方案本身部署和使用代價都很高，不符合“雲原生”這種一鍵部署、開箱即用的使用方式。
在此背景下，雲原生基金會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給雲原生下帶來的革命性的進步，包括：
- 統一協議：OpenTelemetry爲我們帶來了Metric、Tracing、Logging（正在制定中，LogModel已經定義完畢）的統一標準，三者都有相同的元數據結構，可以輕鬆實現互相關聯
- 統一Agent：使用一個Agent即可完成所有可觀察性數據的採集和傳輸，不需要爲每個系統都部署各種各樣的Agent，大大降低了系統的資源佔用，使整體可觀察性系統的架構也變的更加簡單
- 雲原生友好：OpenTelemetry誕生在CNCF，對於各類的雲原生下的系統支持更加友好，此外目前衆多雲廠商已經宣佈支持OpenTelemetry，未來雲上的使用會更加便捷
- 廠商無關：此項目完全中立，不傾向於任何一家廠商，讓大家可以有充分的自由來選擇/更換適合自己的服務提供商，而不需要收到某些廠商的壟斷或者綁定
- 兼容性：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只是定義了可觀察的前半部分，後面還有非常多的複雜工作需要我們去實現，任重道遠。
作者：元乙
本文爲阿里雲原創內容，未經允許不得轉載