聲明：本文根據阿里雲開發者社群直播整理而來。
講師：壚皓
本次分享主要圍繞以下四個方面展開：
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將其串聯起來。
本文由社區志願者整理而成，設區內容志願者火熱招募中，有好禮相贈哦。歡迎加入！戳我瞭解詳情加入！