本文根據 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的類庫進行埋點，則應用就可以通過一個協議，統一上傳指標，跟蹤日誌到不同廠商的後端，進行後繼的分析。
社區產品現狀及侷限
與協議層，日趨一統情況不一樣，在產品層面，由於產品的側重點不同，呈現出了百花齊放的局面。
但是，從某種角度來看，目前社區的產品方案有以下的侷限：
1、缺乏大一統的產品，同時對三個支柱進行支撐，並進行有機的關聯
這個無需多言，只要使用過上述的產品，就會發現沒有辦法找到一個完整開源產品，能夠對以上三種遙測進行同時處理。就更沒有辦法進行統一的關聯了。
2、缺乏大一統的產品模型，統一展示微服務 + 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
未來，可以預期混合使用經典微服務、服務網格的企業必然越來越多。因此，如何設計一個通用的模型，對以上三部分進行統一管控， 這也是螞蟻金服目前正在實踐探索的地方，期望外來有機會向大家分享。
未來展望
綜上所述，隨着雲原生的發展， 我們相信擁有完整的可觀察性三大支柱處理能力，並能在產品層面上對三大支柱進行靈活關聯、下轉、查看的監控產品，適用於混合的雲原生場景的監控的產品，都將會越來越多，幫助企業內部落地雲原生架構。
視頻回顧
本次分享的視頻回顧以及PPT 查看地址：
https://tech.antfin.com/community/activities/779/review
參考資料
[1]“Monitoring in the timeof Cloud Native”：
https://conferences.oreilly.com/velocity/vl-ny-2017/public/schedule/detail/61529
[2]Observability：
https://en.wikipedia.org/wiki/Observability
[3]“Metrics, tracing, and logging”：
https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html
[4]設置應用日誌關聯：
https://tech.antfin.com/docs/2/72179
[5]https://news.ycombinator.com/item?id=15326272
[6]https://github.com/jaegertracing/jaeger/issues/425
[7]螞蟻金服金融科技：https://tech.antfin.com/ 本文歸檔在sofastack.tech