極速體驗｜使用 Erda 微服務觀測接入 Jaeger Trace
在大型網站系統設計中，隨著分散式架構，特別是微服務架構的流行，我們將系統解耦成更小的單元，通過不斷的新增新的、小的模組或者重用已經有的模組來構建複雜的系統。隨著模組的不斷增多，一次請求可能會涉及到十幾個甚至幾十個服務的協同處理，那麼如何準確快速的定位到線上故障和效能瓶頸，便成為我們不得不面對的棘手問題。
Jaeger 是什麼
為解決分散式架構中複雜的服務錯誤定位和效能問題，Google在論文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》中提出了分散式跟蹤系統的設計和構建思路。
Jaeger 是受到 Dapper 的啟發，由 Uber 建立的分散式追蹤平臺，可用於監控和追蹤基於微服務模式構建的分散式系統。Jaeger 於 17 年 4 月份開源，9 月進入 CNCF 孵化，2019 年 10 月正式從 CNCF 畢業，一躍成為 CNCF 頂級專案。
Jaeger 的流行得益於背後有大廠和強大的組織支援，同時原生支援 OpenTracing 標準（可以認為是 OpenTracing 協議的參考實現），當前支援多種主流語言（如 Java、.NET、Golang、Python、NodeJS 等），並且社群有大量的 OpenTracing 生態元件可以直接使用。
在架構設計上，Jaeger 使用 gRPC 外掛化的設計，可以同時支援多種後端儲存，目前支援的資料儲存包括：記憶體、Badger、Cassandra、Elasticsearch、GRPC外掛等。在 Jaeger 的新版本中，也實現了流式架構來處理資料分析，不過需要額外引入 Kafka 和 Flink 元件。
但在要實現微服務系統完整的可觀測性，我們發現 Jaeger 本身也具有一定的侷限性：
-
相比其他的可觀測性系統，Jaeger 更專注於鏈路追蹤（Tracing），日誌和指標功能支援比較有限。同時因為本身缺少監控和報警機制，Jaeger 往往需要結合其他系統來一起實現，比如 Prometheus、ELK 等。
-
Jaeger 作為一個可觀察性/監控系統的組成部分，是開發和運維同學定位和發現業務系統問題的重要手段，我們一定要保證監控系統比業務系統活的更久。而 Jaeger 作為一個開源專案，它本身只提供解決方案，並不會提供部署規模的評估方案和服務如何保證高可用的方案，這需要運維同學基於對服務高可用的經驗和對業務系統規模的調研的給出具體部署方案。
那麼這種情況下我們怎麼去降低可觀測性平臺的複雜性？怎麼去提供高可用和高效能的後端服務？
最好的方式是尋找一個能夠相容 Jaeger 的後端系統，提供高可靠、高效能的能力。
當 Jaeger 相遇 Erda
Erda 作為一款雲上應用協同開發平臺，提供了 SaaS 化可開箱即用的可觀測性雲服務，免去了自己運維多個監控、日誌系統後端的複雜性，同時也提供了完整的微服務觀測能力，包括但不限於：
- 服務效能監控，包括介面呼叫監控、SQL 呼叫監控、慢事務分析、JVM 監控等
- 分散式鏈路追蹤，呼叫鏈路的瀑布圖/火焰圖等多種分析模式
- 分散式日誌查詢和分析
- 視覺化並且靈活的告警配置，支援告警收斂、降噪
- 自定義儀表盤分析
一般情況下，可以有兩種不同的方式來替換 Jaeger 的後端：
-
原生的資料用 Jaeger SDK 產生，查詢模式繼續使用 Jaeger 的 UI，這樣對於應用開發同學來說繼續沿用之前的使用模式，但也僅限於 Jaeger 能提供的 Trace 能力
-
原生的資料用 Jaeger SDK 產生，查詢使用 Erda 的微服務觀測平臺
在 Erda 上，目前我們只支援第 2 種方式，原因在於除了 Trace 能力之外，Erda 還可以基於 Jaeger 的資料，自動發現服務呼叫拓撲，自動分析服務介面的呼叫效能等。
接下來，我們看一下如何使用 Jaeger SDK 把資料接入 Erda 微服務觀測平臺。
首先，在管理中心建立一個監控專案（監控專案和研發專案的區別是後者除觀測能力之外還包含完整的 DevOps 研發功能）：
接下來在微服務治理平臺中找到建立的監控專案，進入後點擊【環境設定】 > 【接入配置頁面】：
目前 Erda 支援 Jaeger SDK 直連後端的方式，為了區分不同使用者上報的追蹤資料和鑑權，我們需要根據頁面的提示獲取【接入點】、【環境ID】和【環境Token】三個變數。
下面以 Java SDK 為例，我們可以使用 Jaeger SpringCloud Starter 或者其他任何相容 OpenTracing 的 SDK，然後在 Jaeger 的 tags 中新增上面的三個變數標籤，並且把 SDK 的上報接入點修改為
【https://collector.erda.cloud/api/jaeger/traces】
例如：
opentracing:
jaeger:
service-name: <your_service_name>
http-sender:
url: https://collector.erda.cloud/api/jaeger/traces
log-spans: true
tags:
erda.env.id: <your_env_id>
erda.env.token: <your_token>
Jaeger 和 Erda 功能對比
拓撲分析可以自動計算並生成 Trace 的依賴拓撲，相比 Jaeger 增加了非常多的指標計算，包括 QPS、錯誤率、平均延遲、狀態碼分佈等：
Erda 可以自動從 Jaeger 的 Trace 資料中計算出服務節點，並生成服務的全域性 Top 對比：
Erda 提供服務端視角的 APM 功能，Jaeger 並不具備這樣的能力：
Erda 可以對 Trace 資料進行計算分析並且生成大量可自定義配置的告警策略，Jaeger 還暫不支援此功能：
此外，Erda 鏈路追蹤分析能力增強，並支援火焰圖模式：
小結
Jaeger 作為 OpenTracing 協議的代表實現，也是 CNCF 的頂級專案和大量雲原生框架實現Trace能力的首選。如果你正在使用 Jaeger ，可以很容易的在不修改程式碼的情況下進行嘗試把資料接入到 Erda 進行統計和分析。
另外，Erda 2.0 版本也將於今天正式釋出，本次版本中產品整體視覺互動進行全新的改版上線，深度優化產品使用者體驗；專案級的研發流程全新上線，在單應用的 CI/CD 基礎之上，提供了專案級的流水線、製品、環境部署的核心功能，讓軟體專案產品研發、交付變得更簡單優雅～我們在後續的文章中將會對新版本進行詳細解讀，感興趣的小夥伴可以持續關注！
參考連結 & 延伸閱讀
《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》