螞蟻金服在雲原生架構下的可觀察性的探索和實踐

本文根據 8 月 11 日 SOFA Meetup#3 廣州站 《螞蟻金服在雲原生架構下的可觀察性的探索和實踐》主題分享整理。現場回顧視頻以及 PPT 查看地址見文末連接。

前言

隨着應用架構往雲原生的方向發展，傳統監控技術已經不能知足雲原生時代運維的需求，所以，可觀察性的理念被引入了 IT 領域。

下面我將會就可觀察性在雲原生的起源，可觀察性發展動力，可觀察性與監控的關係，可觀察性的三大支柱，社區發展方向及產品現狀，以及螞蟻金服對相關問題的理解及實踐進行探討。

才疏學淺，歡迎拍磚。

爲何雲原生時代須要可觀察性

可觀察性的由來

在雲原生語境下的可觀察性這個詞，最先出現於2017年7月，Cindy Sridharan 在Medium 寫的一篇博客， "Monitoringand Observability"[1] 談到了可觀察性與雲原生監控的關係。

而在2017年10月，來自 Pivotal 公司的Matt Stine，在接受 InfoQ 採訪的時候，對雲原生的定義進行了調整，將 Cloud Native Architectures 定義爲具備如下六個特質：

• 模塊化 （Modularity） (經過微服務)
• 可觀察性 （Observability）
• 可部署性 （Deployability）
• 可測試性 （Testability）
• 可處理性 （Disposability）
• 可替換性 （Replaceability）

可見，在2017年下半年，可觀察性成爲了一個 buzzword（時髦詞），正式出如今了雲計算領域。

可觀察性的定義

雖然「可觀察性」這個詞在 IT 行業是一個新的術語，但它實際上是在上世紀60年代，由匈牙利裔工程師魯道夫·卡爾曼提出的概念[2]。

術語「可觀察性」，源於控制論，是指系統能夠由其外部輸出推斷其內部狀態的程度。

這個外部輸出，在雲原生的語境下，即 Telemetry ，遙測，一般由服務（services）產生，劃分爲三個維度或者說支柱，Tracing（跟蹤），Metrics（指標） , Logging（日誌）。

爲何雲原生須要可觀察性

近年能夠看到，雲計算對基礎架構改變甚爲巨大，不管是互聯網行業，仍是傳統行業，雲化在提高資源利用率，提升業務敏捷性的價值已經成爲了公式。而在應用層面，因爲業務特性的緣由，互聯網公司大部分已經完成雲化，應用架構也不一樣程度上，完成了從單體應用向微服務應用演進。在轉型後，總體系統複雜性大大增長，倒逼相應的工具及方法論進行升級改造，去 hold 住這麼複雜的局面。

上圖爲 Uber 展現的整體調用鏈圖。

考慮到業務多樣性及複雜度，在螞蟻金服內部，相關調用關係只會更爲複雜，用人類的智力，已經沒有辦法去理解如此複雜的調用關係。而上圖只是展現了可觀察性的鏈路調用，若是再加上指標及日誌，不對工具及方法論進行革新，是難以實現對複雜微服務架構的管控的。

微服務只是雲原生的模塊化特性的體現，再考慮到近年被普遍應用容器，Kubernetes , 以及你們關注度極高的 Service Mesh , Istio，每個新的技術的出現，在帶來了更優雅的架構、更靈活的調度、更完善的治理的同時，也帶來更多新的複雜性。

所以，可觀察性對於雲原生的應用架構，是必不可少的特性。

可觀察性和傳統監控的區別

很多同窗就會說，這個可觀察性與咱們談的最多的監控有什麼區別。雖然有很多人認爲，這詞就是個buzzword，就是趕時髦的，沒有太大的意義，可是我結合網上的討論，我的認爲可觀察性與監控，含義上雖然接近，可是也有一些理念上的差異，使得討論可觀察性這個詞，是有具備現實意義，並能真正產生相應的價值。

1. 監控更多關注的是基礎設施，更多與運維工程師相關，更強調是從外部經過各類技術手段去看內部，打開黑盒系統。
2. 可觀察性更多的是描述應用，在咱們談論具體某應用，或者是某些應用是否具有客觀性的時候，一般與開發人員相關，由於在常見的可觀察性的實踐之中，開發人員須要在應用的開發過程當中嵌入例如 statd 或者是 opentracing，或者是 opencensus 等所提供的庫，對相關的 telemetry 進行輸出，或者是俗話說的埋點。經過埋點，將服務內部的狀態白盒化，使得其在運維階段具有可觀察性。某種程度上能夠說，可觀察性遵循了 DevOps 及 SRE 的理念，即研發運維一體化，從開發側就考慮系統的可運維性。

這裏值得補充說明的是，目前市面上，有商用或者開源 APM 方案，經過入侵 JVM 或者其餘技術手段，對應用進行自動埋點的，輸出 trace 及 metrics 信息。這一樣也是一種可觀察性的實現方式，這樣作的最大的好處是，不須要對現有的應用進行改造，可是相應的 agent 對應用進行實時的監控，必然會或多或少的增長資源的佔用，例如每實例額外30+MB 內存，5~10% 的 CPU 佔用，在大規模的運行環境之中，會有很多的成本增長。

可觀察性的三大支柱及社區進展

可觀察性的三大支柱

可觀察性的三大支柱及其之間的關係，Peter Bourgon 在2017年2月撰寫了一篇簡明扼要的文章， 叫 "Metrics, tracing, and logging" [3]，有興趣的能夠去看一下，如下僅爲簡單的說起。

1. 指標數據（Metrics Data）
描述具體某個對象某個時間點的值。在 Prometheus 中，指標有四種類型，分別 Counter（計數器）、Gauge（瞬時值）、Histogram（直方圖）和 Summary （概要）， 經過這四種類型，能夠實現指標的高效傳輸和存儲。

2. 日誌數據 ( Logging Data）
描述某個對象的是離散的事情，例若有個應用出錯，拋出了NullPointerExcepction，或者是完成了一筆轉帳，我的認爲 Logging Data 大約等同於 Event Data，因此告警信息在我認爲，也是一種 Logging Data。可是也有技術團隊認爲，告警應該算是可觀察性的其中一個支柱。

3. 跟蹤數據（Tracing Data）
Tracing Data 這詞貌似如今尚未一個權威的翻譯範式，有人翻譯成跟蹤數據，有人翻譯成調用數據，我儘可能用 Tracing 這個詞。Tracing 的特色就是在單次請求的範圍內處理信息，任何的數據、元數據信息都被綁定到系統中的單個事務上。一個 Trace 有一個惟一的 Trace ID ，並由多個 Span 組成。

社區方案進展

因爲可觀察性在雲原生中，是一個很是重要的特性，所以，在開源世界中，前後出現了兩個定位都比較相似的項目，分別是源自 Google 的 OpenCensus （定位上報 Tracing + metris）和由 CNCF 孵化的 OpenTracing（定位上報 Tracing）。二者都定位於提供廠商中立的技術規範，及實現該規範各類編程語言遙測庫，使得用戶在使用了相關的庫之後，能夠將相關的遙測數據，發往不一樣廠商的後端，如 Zipkin , SignalFX，Datdog 等，從而促進雲原生的可觀察的良性發展。

因爲兩個項目的定位高度雷同，所以在2019年3月，兩個項目社區的主要領導者，決定將兩個項目進行融合，產生一個同時向下兼容 OpenCensus 及 OpenTracing 的項目，叫 Open Telemetry，將多個標準下降爲一個。

OpenTelemetry 旨在將可觀察性的三大支柱，組合成一組系統組件和特定於語言的遙測庫。項目在最初並不會支持日誌，但最終會將其合併。這個事情比較好理解，由於日誌數據量太大，也缺少相應的初始規範，社區選擇在時機成熟時再進行引入是一個很合理的策略。

簡單來講，之後在應用開發裏頭，只要使用了 Open Telemetry的類庫進行埋點，則應用就能夠經過一個協議，統一上傳指標，跟蹤日誌到不一樣廠商的後端，進行後繼的分析。

社區產品現狀及侷限

與協議層，日趨一統狀況不同，在產品層面，因爲產品的側重點不一樣，呈現出了百花齊放的局面。

可是，從某種角度來看，目前社區的產品方案有如下的侷限：

一、缺少大一統的產品，同時對三個支柱進行支撐，並進行有機的關聯
這個無需多言，只要使用過上述的產品，就會發現沒有辦法找到一個完整開源產品，可以對以上三種遙測進行同時處理。就更沒有辦法進行統一的關聯了。

二、缺少大一統的產品模型，統一展現微服務 + Mesh + Serverless
在不遠的未來，傳統微服務、Mesh 、Serverless 應用混合交互構成業務系統，將會是一個廣泛的狀況，可是目前開源的產品，並不具有對以上三種計算模型進行統一的，可識別的管理。

螞蟻金服對雲原生的可觀察性的理解及實踐

螞蟻金服在多年的分佈式系統運維過程當中，對可觀察性有着本身深刻的理解，結合用戶的特色，將其進行產品化及解決方案，並提供給金融用戶。

1. 鏈路跟蹤是可觀察性的核心，用於故障定位

在微服務及分佈式架構中，鏈路跟蹤是用戶的核心使用訴求，這裏你們都應該比較熟悉了，我也很少作展開。

2. Tracing+metirce+Log有機關聯是實現可觀察性的關鍵

鏈路與日誌關聯

鏈路與日誌關聯[4]是一個很重要的場景。在不少時候，某一個調用失敗，失敗的緣由，並不能體如今 Trace 之上，也許是發生在業務側，例如餘額不足，致使整個調用的失敗。所以，不少時候，咱們須要將鏈路和日誌關聯，幫助咱們更好的判斷究竟是什麼緣由，致使鏈路調用失敗，或者是進行進行其餘分析。

爲此，咱們提供了一個 SDK，用戶能夠根據咱們官網上的配置，對 log4j 及其餘 logger進行配置後，將 TraceId 及 RPCId 從 Tracer 中進行獲取，那麼在打印的日誌的時候，TraceId , RPCId 也會如圖上所示，在日誌中打印出來。最後，而後經過Trace view，就能在查看鏈路的同時查看關聯的日誌。

具體的配置方式或者原理，感興趣的同窗，能夠查看螞蟻金服金融科技官網。https://tech.antfin.com/

拓撲與指標關聯

除了鏈路與日誌關聯，咱們 SOFA 還提供了應用指標的上傳功能 在應用上傳 Trace 的同時，咱們將指標與調用拓撲進行了關聯，用戶能夠點擊應用拓撲中的應用，下轉查看響應的拓撲指標。

3. 按照固定採樣率進行採樣不能知足實踐使用需求

有 Tracing 相關產品使用經驗的同窗都知道，在業務量大的時候，相關的 Tracing 產生的數據量會較多，致使存儲成本以及處理成本的大幅度增長。在實際的生產中，咱們每每會對 Tracing 進行採樣，一般會採用 1/100 甚至是1/1000 的方式進行採樣。

具體的採樣方式，一般採用 Head-based 採樣，即對 TraceId 進行以 100 或者1000 來採模，採模後若是是 1 ，則 agent 對該 TraceId 進行進行採集。是否對鏈路進行採集的決定，發生在鏈路的第一跳，即TraceId 產生時，因此叫 Head-based 採樣。

這種採樣方法好處是實現很是簡單，但問題是 100 個鏈路數據中，可能有 3-5 個是運維人員關心的，一般是調用出錯的鏈路，又或者是調用緩慢的鏈路，經過這種簡單粗暴的採樣，能採集到相應鏈路的機會就會不多。大部分狀況下，用戶只能指望異常屢次發生，並在某次被採樣命中，而後進行分析。

目前，開源軟件中，採用的都是這種方案。

咱們在螞蟻金服內部，使用的是 Tail-based 的採樣方案，簡單來講，咱們會把全部的 Span 數據，都會放到內存裏，但這個時候，並不能決定具體那一條鏈路是採集仍是不採集，可是當整條鏈路閉合後，咱們就會對整條的 Trace 根據規則進行判斷，若是有調用失敗，或者整個調用中有部分 Span 是處於緩慢狀態的，系統會將會標記此鏈路爲異常鏈路，即命中採樣，永久保存。這樣就能保證運維人員可以無視採樣率，具有對異常鏈路進行查看能力。因爲對某一條鏈路數據是否採集的決定，實際上是處於鏈路的尾部（非嚴格意義）才做出的，因此叫 Tail-based 採樣。

固然以上 Tail-based 的採樣的描述是極其簡單及理想化的，在海量數據量的狀況下，以上的方法基本上沒有辦法使用，很容易就把內存給撐爆了。在實際設計中，咱們還考慮了不少的因素，進行了更多的細節處理，使得 Tail-based 採樣的資源消耗也在一個能夠接受的範圍內。

目前這個功能在內部已經落地，對外還在產品化之中。（想要了解上述更多技術細節，能夠查看參考資料[5]&[6]）

4. 統一化 微服務 + Mesh + Serverless

將來，能夠預期混合使用經典微服務、服務網格的企業必然愈來愈多。所以，如何設計一個通用的模型，對以上三部分進行統一管控， 這也是螞蟻金服目前正在實踐探索的地方，指望外來有機會向你們分享。

將來展望

綜上所述，隨着雲原生的發展， 咱們相信擁有完整的可觀察性三大支柱處理能力，並能在產品層面上對三大支柱進行靈活關聯、下轉、查看的監控產品，適用於混合的雲原生場景的監控的產品，都將會愈來愈多，幫助企業內部落地雲原生架構。

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。