解读云原生下的可观察性发展方向
前言
非常有幸參加了云原生社區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.
電氣工程發展了上百年，其中各個子領域的可觀察性都在進行完善和升級，例如交通工具（汽車/飛機等）也算的是可觀察性上的集大成者。拋開飛機這種超級工程不談，一輛可正常上路的小型汽車內部也有上百種的傳感器用來檢測汽車內/外部的各種狀態，以便讓汽車可以穩定、舒適、安全地的行駛。
可觀察性的未來
隨著上百年的發展，電氣工程下的可觀察性已經不僅僅用來輔助人們進行問題檢查和定位問題，我們以汽車工程來看，整個可觀察性的發展經歷了幾個過程：
自動駕駛的核心要素
作為電氣工程上可觀察性的巔峰，自動駕駛將汽車獲取到的各類內外部數據發揮到極致，總結起來主要有幾下幾個核心的要素：
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系統架構升級，包括開發模式、系統架構、部署模式、基礎設施全套的演進和迭代。
拯救者：OpenTelemetry
上述的這些問題相信很多讀者都會深有體會，而業界也針對這種情況退出了各類可觀察性相關的產品，包括開源、商業化的眾多項目。例如：
利用這些項目的組合或多或少可以解決針對性的一類或者幾類問題，但真正應用起來你會發現各種問題：
在此背景下，云原生基金會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限制
從上面的分析來看，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團隊長期招聘人才，歡迎對大數據、監控、可觀察性、前端可視化、移動端開發、機器學習等有興趣的同學前來聯系我:
- 郵箱： davidzhang.zc@alibaba-inc.com
- 微信： davidzhang-zc。
- 職位： https://cloudnative.to/job/aliyun-sls-observability/
- https://mp.weixin.qq.com/s/pTeVHMeBThKO4C7wLt-oHQ
參考：
原文鏈接：https://developer.aliyun.com/article/780609?
版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。 與50位技術專家面對面20年技術見證，附贈技術全景圖總結
以上是生活随笔為你收集整理的解读云原生下的可观察性发展方向的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Apache Flink 在实时金融数据
- 下一篇： Serverless在游戏运营行业进行数