聲明：本文根據阿裡雲開發者社群直播整理而來。
講師：垆皓
本次分享主要圍繞以下四個方面展開：
1、可觀測性
2、基本原理
3、産品介紹
4、實戰示範
一、可觀測性
首先我們從監控談起：監控主要解決應用線上上運作遇到的一些問題，如圖所示：
在雲原生背景下，由單機服務變為分布式服務之後給監控帶來的挑戰：
在傳統的單應用隻關注單機應用的狀态，各應用之間的依賴性不是很複雜；在微服務架構下，用戶端的請求先通過網關轉發給之後對應的具體的應用，每個應用完成不同的功能，各應用的依賴性變的很複雜，這樣就會導緻問題的排查以及故障的定位難度也會變的很複雜。
接下來看容器化的部署：
K8S的對于運維的釋出帶來了許多友善之處，但實際上也引入了一些問題：比如某一個應用pod的resourse限制設定的存在不合理之處，導緻整個應用的狀态非正常狀态。
這樣的話，在K8S的狀态之下，監控不但要關注應用的狀态，同時也要關注整體所依賴的底層資源的狀态。
比如：一個pod在某一個load中運作，受其他pod的影響，發生了漂移，那麼就要關注發生漂移的原因。
二、基本原理
那麼到底什麼是雲原生的可觀測性？
在雲原生的大背景下，可觀測性是依賴于之前介紹的三種資料，在依賴的基礎之上擷取更多、更複雜的資料，不僅僅收集某個應用的Traces資料，而且會收集許多資料：包括主機，應用以及K8S等相關資料，再由這些名額資料互相關聯來發現一些問題。Trace資料之前可能是某一類應用調用的堆棧，現在可能變成上下遊竄的幾百個應用，之後通過某一次調用把互相涉及到的幾百個應用都串聯起來，事件資料可能就會引入一些類似于K8s的pod生命周期的事件或者一些别的事件。
可觀測系統基于Metrics、Traces、Logs這三種資料構造，不僅可以獲得應用的每個接口執行效率，也可以獲得底層資源，比如K8S的底層資源的運作狀态，從某一個前端到它的後端開始處理，處理完成之後到轉發、應用，整個鍊路都需要完整的被追蹤，相當于可觀測性對比與傳統的監控來說，可觀測性更強調的是分布式系統發生的所有事件都能夠被觀測，給出合理的解釋。
如果可觀測系統出現問題之後，該如何解決？
目前來說，最出名的方法是普羅米修斯，普羅米修斯側重于Metrics資料的系統。
它是通過API暴露Metrics名額，被暴露的名額通過普羅米修斯去拉的方式寫入到一個資料庫，在資料庫處理分析之後通過一個大盤展示。
接下來來看對于Tracing資料的解決方案：
OpenTracing解決方案是一種标準，它定義了整個Trace，比如過來一個請求，我們該如何記錄它？記錄這個請求的哪些屬性？然後把這個請求往下串聯起來，把它的相關資料，比如請求的辨別，通過什麼方式往下傳，傳下去的時候包括資料的格式，它的資料庫的目标位址是什麼，此時可以往這個請求上加一個“ke”和“y6”的值，打上标簽，通過上述操作，記錄了請求的相關資料。這樣的話形成了統一的一個Tracing的規範，在雲原生的背景下OpenTracing的解決方案是一個比較流行的解決方案。
三、産品介紹
1.ARMS ARMS是一款應用性能監控的工具，涵蓋了前端監控、應用監控和普羅米修斯的各類子産品，涵蓋了從浏覽器端到小程式端、手機APP、和KYS容器環境的監控，可以将全棧式的請求串聯起來，友善了問題的排查。
2.前端監控 前端監控可以把請求發出到後面處理全部串聯起來。
3.APP監控 提供了安卓和ios端的相關情況。
4.業務監控 ：如圖所示
某一個請求進入，做标記為商品購買，繼續下傳到應用B，這個标記可以持續下傳，這樣相當于給整個鍊路打上了标記，可以統計某類請求對應的數目，響應時間等，通過業務的寓意的耗時是不是比其他的耗時長，可以做出更精準的判斷。
四、實戰示範
左圖：核心在于某次請求進入之後，生成一個Trace Id，繼續調用，發送一個ATP請求，在ATP請求把TraceId帶上，這樣的話下遊應用在收到解析ATP之後也會把TraceId的在整個鍊路都記錄上。在整個分布式應用中把TraceId會沿着調用一直傳下去，調用的相關資料記錄下來，就可以把所有的鍊路串起來。
右圖：整個Trace的生成方式。調用不是同步的，是分開的。：整個Trace的生成方式。調用不是順序調用，某一個調用請求完成之
後，下一個應用就繼續開始。調用不是同步的，是分開的。這樣的話需要我們用TraceId将其串聯起來。
本文由社群志願者整理而成，設區内容志願者火熱招募中，有好禮相贈哦。歡迎加入！
戳我了解詳情加入！