從Opentracing、OpenCensus 到 OpenTelemetry，看可觀測數據標准演進史

本文轉載自查看原文 2022-04-14 10:14 785 雲原生/ 阿里雲/ 微服務/ 可觀測/ Serverless/ 開源/ 實踐/ MSE/ Kubernetes/ RocketMQ

作者：可觀測

伴隨着分布式應用、Serverless 應用被越來越多開發者及企業所接受，但其背后所隱藏的運維問題也逐漸凸顯出來--微服務架構中請求鏈路過長從而導致問題定位時間長，運維想要日常監控也非常困難。以一個具體問題舉例，在分布式應用中完成一個單一用戶請求可能會需要多個不同的微服務處理，這其中任何一個服務失敗或性能拉垮，都會對用戶請求響應造成極大影響。隨着業務不斷擴張，這個調用鏈也越來越復雜。僅憑借打印日志或 APM 性能監控很難做到全景瀏覽或者一鑽到底。對於問題排查或性能分析時，這無異於盲人摸象。

面對這樣的問題，Google 發表了論文《"Dapper - a Large-Scale Distributed Systems Tracing Infrastructure"》[1]介紹他們的分布式跟蹤技術，並認為分布式跟蹤系統應該滿足以下業務需求：

• 性能低損耗： 分布式跟蹤系統對服務的性能損耗應盡可能做到忽略不計，尤其是那些對性能敏感的應用。

• 低侵入： 盡可能做到業務代碼的低侵入或無侵入。

• 快速擴展：能夠隨着業務或微服務規模快速擴大。

• 實時展現：低延時采集數據，實時監控系統，對系統的異常狀況作出快速的反應。

在這里插入圖片描述

除了以上要求，該論文也針對分布式追蹤的數據采集、數據持久化、數據展示三個核心環節進行了完整闡述。這其中，數據采集指在代碼中埋點，設置請求中需要上報的內容。數據持久化指將上報的數據落盤存儲。數據展示則是根據 TraceID 查詢與之關聯的請求在界面上呈現。

在這里插入圖片描述

也是隨着這篇論文的誕生，分布式追蹤（Distributed Tracing)被越來越多人接受，技術概念逐漸興起。相關產品如雨后春筍般涌現，Uber 的 Jaeger、Twitter 的 Zipkin 等分布式追蹤產品聲名大噪。但在這過程中也帶來了一個問題：雖然每個產品都有自己一套數據采集標准和 SDK，但大多都是基於谷歌 Dapper 協議，只是實現不盡相同。為了解決這個問題，OpenTracing 和 OpenCensus 誕生。

OpenTracing

對於很多開發人員而言，想讓應用支持分布式追蹤太難了。這不僅需要在進程內進行追蹤數據的傳遞，還要在進程之間傳遞。更難的是還需要其他組件對分布式跟蹤的支持，比如 NGINX, Cassandra, Redis 等開源服務，或者在服務內引入的 gRPC, ORMs 等開源庫。

在這里插入圖片描述

在 OepnTracing 之前，一方面，很多分布式追蹤系統通過使用不兼容 API 的應用程序級檢測進行實現，這使得開發人員對應用與任何特定的分布式跟蹤緊密耦合，都會感到不安。另一方面，這些應用程序級檢測 API 具有非常相似的語義。為了解決不同的分布式追蹤系統 API 不兼容問題，或者說追蹤數據從一個庫到另一個庫和一個進程到下一個進程傳遞過程中的標准化問題，誕生了 OpenTracing 規范。位於應用程序/類庫和追蹤或日志分析程序之間的輕量級標准化層。

優勢

OpenTracing 的優勢在於制定了一套無關廠商、無關平台的協議標准，使開發人員只需要修改 Tracer 就可以更迅捷的添加或更換底層監控的實現。也是基於這一點，2016 年雲原生計算基金會 CNCF 正式接納 OpenTracing，順利成為 CNCF 第三個項目。而前兩個項目都已成為雲原生及開源領域的事實標准--Kubernetes 和 Prometheus。由此也可以看到行業對於可觀測及統一標准的重視程度。

OpenTracing 由 API 規范、實現該規范的框架和庫，以及項目文檔組成，並進行以下努力：

• 后台無關的 API 接口標准化：被追蹤的服務只需要調用相關 API 接口，就可被任何實現這套接口的追蹤后台支持。

• 對跟蹤最小單位 Span 管理標准化：定義開始 Span，結束 Span 和記錄 Span 耗時的 API。

• 進程間跟蹤數據傳遞方式標准化：定義 API 方便追蹤數據的傳遞。

• 對多語言應用支持的標准化：全面覆蓋 GO、Python、Javascript、Java、C#、Objective-C、C++ 、Ruby、PHP 等開發語言。它支持 Zipkin、LightStep、Appdash 跟蹤器，並可以輕松集成到 GRPC、Flask、DropWizard、Django和Go Kit 等框架中。

在這里插入圖片描述

核心術語介紹

• Trace

一個完整請求鏈路。
• Span - 一次調用過程

系統中具有開始時間和執行時長的邏輯單元，並包含多個狀態。

每個 Span 封裝以下狀態：
• An operation name - 操作名稱
• A start timestamp - 起始時間
• A finish timestamp - 結束時間
• Span Tag - 一組鍵值對構成的 Span 標簽集合。

鍵值對的鍵必須為 String，值可以是字符串、布爾或數字類型。

• Span Log - 一組 Span 的日志集合。

每次 Log 操作包含一個鍵值對以及時間戳。鍵值對的鍵必須為 String，值可以是任意類型。

• References - Span 間關系

相關的零個或者多個 Span。Span 間通過 SpanContext 建立 References 關系。

• SpanContext - 通過 SpanContext，引用其他因果相關的 Span。

OpenTracing 目前定義了兩種類型的引用：ChildOf 和 FollowsFrom. 這兩種引用類型都
專門模擬了子 Span 和父 Span 之間的直接因果關系。

ChildOf 關系中的父級 Span 要等待子 Span 返回，子 Span 執行時間影響了其所在父 Span 執行時間，父 Span 依賴子 Span 執行結果。除了串行的任務之外，我們的邏輯中還有很多並行的任務，它們對應的 Span 也是並行的，這種情況下一個父 Span 可以合並所有子 Span 執行結果並等待所有並行子 Span 結束。在分布式應用中某些上游系統不以任何方式依賴下游系統執行結果，例如，上游系統通過消息隊列向下游系統發送消息。這種情況下，下游系統對應的子 Span 和上游系統對應的父級 Span 之間是 FollowsFrom 關系。

數據模型

在了解相關術語之后，我們可以發現 OpenTracing 規范中具備三個關鍵且互連的類型：Tracer、Span 和 SpanContext。OpenTracing 的技術模型，也就清晰起來：Trace 調用鏈通過歸屬於此調用鏈的 Span 來隱性定義，每次調用就稱為一個 Span，每個 Span 都要帶上全局的 TraceId 。Trace 調用鏈可以被認為是一個由多個 Span 組成的有向無環圖（DAG 圖），一條 Trace 中 Span 是首尾連接的。TraceID 及相關內容以 SpanContext 為載體，通過傳輸協議，遵循着 Span“路徑”按序進行。以上可以看作分布式應用中一次客戶端請求全過程，除了從業務視角的 DAG 圖之外，為了更好的展示組件調用時間、先后關系等信息，我們也嘗試基於時間軸的時序圖去更好地展現 Trace 調用鏈。

在這里插入圖片描述

最佳實踐

• 應用代碼

開發人員可以使用 OpenTracing 來描述服務之間的因果關系，並添加細粒度日志信息。

• 庫代碼

采取中間控制請求的庫可以與 OpenTracing 集成，例如，Web 中間件庫可以使用 OpenTracing 為請求創建 Span，或者 ORM 庫可以使用 OpenTracing 描述高級別的 ORM 語義，並執行特定 SQL 查詢。

• RPC/IPC 框架

任何跨進程的子服務都可以使用 OpenTracing 來標准化追蹤數據的格式。

OpenCensus

在整個可觀測領域，為了更好的實現 DevOps，除了分布式追蹤 Trace，運維人員開始關注 Log 和 Metrics。Metrics 指標監控作為可觀測的重要組成部分，包括 CPU、內存、硬盤、網絡等機器指標，gRPC 請求延遲、錯誤率等網絡協議指標，用戶數、訪問數等業務指標。

OpenCensus 提供了統一的測量工具：跨服務捕獲跟蹤跨度 Span、應用級別指標 Metrics。

在這里插入圖片描述

優勢

• 相較於 OpenTracing 只支持 Traces，OpenCensus 支持 Traces 和 Metrics。
• 相較於 OpenTracing 制定規范，OpenCensus 不僅制定規范，還包含了 Agent 和 Collector。
• 家屬團陣容相較 OpenTracing 更加龐大，獲得 Google、微軟支持。

做了什么

• 標准通信協議和一致的 API ：用於處理 Metrics 和 Trace。
• 多語言庫支持：Java、C++、Go、.Net、Python、PHP、Node.js、Erlang 、Ruby。
• 與 RPC 框架的集成。
• 集成存儲和分析工具。
• 完全開源並支持三方集成和輸出的插件化。
• 不需要額外服務器或 Agent 來支持 OpenCensus。

核心術語介紹

除了沿用 OpenTracing 的相關術語之外，OpenCensus 也定義了一些新術語。

• Tags
OpenCensus 允許在記錄時將指標與維度相關聯。從而能夠從不同角度分析測量結果。
• Stats
收集庫和應用記錄的可觀測結果，匯總、導出統計數據，並包括 Recording（記錄）、Views（聚合度量查詢）兩部分。
• Trace
除了 Opentracing 所提供的 Span 屬性之外，OpenCensus 還支持 Parent SpanId、Remote Parent、Attributes、Annotations、Message Events、Links 等屬性。
• Agent
OpenCensus Agent 是一個守護進程，允許 OpenCensus 的多語言部署使用Exporter。與傳統上為每個語言庫和每個應用程序刪除和配置 OpenCensus Exporter不同，使用 OpenCensus Agent，只需為其目標語言單獨啟用 OpenCensus Agent Exporter。對於運維團隊而言，實現單個 exporte 管理並從多語言應用程序中獲取數據，將數據發送到所選擇的后端。與此同時，盡可能的減少反復啟動或部署對於應用的影響。最后，Agent 還附帶了“Receivers”。“Receivers”使 Agent 直通后端，去接收可觀測數據並將其路由到所選擇的 Exporter。比如 Zipkin、Jaeger 或 Prometheus。

在這里插入圖片描述

• Collector
Collector 作為 OpenCensus 的重要組成部分，由 Go 語言便編寫，可以從任何可用 Receivers 的應用中接受流量，而不用關注編程語言以及部署方式，而這個好處顯而易見。對於提供 Metrics 和 Trace 的服務或應用而言，只需要一個 Exporters 導出組件，就能從多語言應用中獲取數據。

對於開發者而言，只需要管理維護單個 Exporter，所有應用都使用 OpenCensus Exporter 發送數據。與此同時，開發人員自由選擇將數據發送到業務所需的后端，並隨時進行更好。為了解決通過網絡發送大量數據可能需要處理發送失敗的問題，Collector 具有緩沖和重試功能，可確保數據完整性與可用性。

在這里插入圖片描述

• Exporters
OpenCensus 可以通過各種 Exporter 實現將相關數據上傳到各種后端，比如：Prometheus for stats、OpenZipkin for traces、Stackdriver Monitoring for stats and Trace for traces、Jaeger for traces、Graphite for stats。

OpenTelemetry

在回答上一個問題時，我們先看看一個典型服務問題排查過程是怎樣的：
• 通過各式各樣預設報警發現異常（Metrics/Logs）
• 打開監控大盤查找異常現象，並通過查詢找到異常模塊（Metrics）
• 對異常模塊以及關聯日志進行查詢分析，找到核心的報錯信息（Logs）
• 通過詳細的調用鏈數據定位到引起問題的代碼（Tracing）

為了能夠獲得更好的可觀測性或快速解決上述問題，Tracing、Metrics、Logs缺一不可。

在這里插入圖片描述

與此同時，行業中已經有了豐富的開源及商業方案，其中包括：

• Metric：Zabbix、Nagios、Prometheus、InfluxDB、OpenFalcon、OpenCensus
• Tracing：Jaeger、Zipkin、SkyWalking、OpenTracing、OpenCensus
• Logs：ELK、Splunk、SumoLogic、Loki、Loggly。

有着五花八門的方案同時，各個方案也有着五花八門的協議格式/數據類型。不同的方案之間很難兼容/互通。與此同時，實際的業務場景中也會將各種方案混用，開發人員只能自己開發各類 Adapter 去兼容。

什么是 OpenTelemetry

為了更好的將 Traces、Metrics 和 Logs 融合在一起，OpenTelemetry 誕生了。作為 CNCF 的孵化項目，OpenTelemetry 由 OpenTracing 和 OpenCensus 項目合並而成，是一組規范、API 接口、SDK、工具和集成。為眾多開發人員帶來 Metrics、Tracing、Logs 的統一標准，三者都有相同的元數據結構，可以輕松實現互相關聯。

在這里插入圖片描述

OpenTelemetry 與廠商、平台無關，不提供與可觀測性相關的后端服務。可根據用戶需求將可觀測類數據導出到存儲、查詢、可視化等不同后端，如 Prometheus、Jaeger 、雲廠商服務中。

優勢

OpenTelemetry 核心優勢集中在以下部分：

• 完全打破各個廠商的 Lock-on 隱患

作為運維人員而言，發現工具不夠用，但評估實現成本太高而無法切換時，一定會跳起來大罵廠商“狗賊又要謀害朕”。而 OpenTelemetry 的出現，旨在通過提供標准化 instrumentation 框架打破這種宿命，作為一個可插拔的服務，可以輕松添加常見的技術協議與格式，讓服務選擇更加自由。

• 規范的制定和協議的統一

OpenTelemetry 采用基於標准的實現方法。對標准的關注對於 OpenTelemetry 來說尤其重要，因為需要追蹤跨語言的互操作性。許多語言都帶有類型定義，可以在實現中使用，例如用於創建可重用組件的接口。包括可觀測客戶端內部實現所需要的規范，以及可觀測客戶端與外部通信所需實現的協議規范。具體包括：

• API：定義 Metrics、Tracing、Logs 數據的類型和操作。
• SDK：定義 API 特定語言實現需求，定義配置、數據處理和導出概念。
• 數據：定義 OpenTelemetry Line Protocol （OTLP）。雖然在 Opentelemetry中組件支持了 Zipkin v2 或 Jaeger Thrift 協議格式的實現，但都以第三方貢獻庫形式提供。只有 OTLP 是 Opentelemetry 官方原生支持的格式。

在這里插入圖片描述

每種語言都通過其 API 實現規范。API 包含特定於語言的類型和接口定義，它們是抽象類、類型和接口，由具體的語言實現使用。它們還包含無操作（no-op）實現，以支持本地測試並為單元測試提供工具。API 的定義位於每種語言的實現中。正如 OpenTelemetry Python 客戶端所述：“opentelemetry-api 包包括抽象類和無操作實現，它們組成了遵循規范的 OpenTelemetry API。”可以在 Javascript 客戶端中看到類似定義：“這個包提供了與 OpenTelemetry API 交互所需的所有東西，包括所有 TypeScript 接口、枚舉和 no-op 實現。它既可以在服務器上使用，也可以在瀏覽器中使用。”

• 多語言 SDK 的實現和集成

OpenTelemetry 為每個常見語言都實現了對應 SDK，將導出器與 API 結合在一起。SDK 是具體的、可執行的 API 實現。包含 C++、.NET、Erlang/Elixir、Go、Java、JavaScript、PHP、Python、Ruby、Rust、Swift。

OpenTelemetry SDK 通過使用 OpenTelemetry API 使用選擇的語言生成可觀測數據，並將該數據導出到后端。並允許為公共庫或框架增強。用戶可以使用 SDK 進行代碼自動注入和手動埋點，同時對其他三方庫（Log4j、LogBack 等）集成支持；這些包一般都是根據 opentelemetry-specification 里面的規范與定義，結合語言自身的特點去實現在客戶端采集可觀測數據的基本能力。如元數據在服務間、進程間的傳遞，Trace 添加監測與數據導出，Metrics 指標的創建、使用及數據導出等。

在這里插入圖片描述

• 數據收集系統的實現

在 Tracing 實踐中有個基本原則，可觀測數據收集過程需要與業務邏輯處理正交。盡量減少可觀測客戶端對原有業務邏輯的影響，Collector 是基於這個原則。OpenTelemetry 基於 OpenCensus Service 的收集系統，包括 Agent 和 Collector。Collector 涵蓋采集（Collect）、轉換（Transform）和導出（Export）可觀測數據的功能，支持以多種格式（例如 OTLP、Jaeger、Prometheus 等）接收可觀測數據，並將數據發送到一個或多個后端。它還支持在輸出可觀測數據之前，對其進行處理和過濾。Collector contrib 軟件包支持更多數據格式和后端。

從架構層面來說，Collector 有兩種模式。一種是把 Collector 部署在應用相同的主機內（如Kubernetes 的 DaemonSet），或者部署在應用相同的 Pod 里面（如Kubernetes 中的 Sidecar），應用采集到的遙測數據，直接通過回環網絡傳遞給 Collector。這種模式統稱為 Agent 模式。另一種模式是把 Collector 當作一個獨立的中間件，應用把采集到的遙測數據往這個中間件里面傳遞。這種模式稱之為 Gateway 模式。兩種模式既可以單獨使用，也可以組合使用，只需要數據出口的數據協議格式跟數據入口的數據協議格式保持一致。

• 自動代碼注入技術

OpenTelemetry 也開始提供可以自動代碼注入的實現，目前已經支持Java各類主流框架的自動注入。

• 雲原生架構

OpenTelemetry 設計之初就已經考慮了雲原生的特性，並且還提供了 Kubernetes Operator 用於快速部署使用。

OpenTelemetry 支持的數據類型

• Metrics

Metric 是關於一個服務的度量，在運行時捕獲。從邏輯上講，捕獲其中一個量度的時刻稱為 Metric event，它不僅包含量度本身，還包括獲取它的時間和相關元數據。應用和請求指標是可用性和性能的重要指標。自定義指標可以深入了解可用性如何影響用戶體驗和業務。自定義 Metrics 可以深入理解可用性 Metrics 是如何影響用戶體驗或業務的。

OpenTelemetry 目前定義了三個 Metric 工具：
• counter: 一個隨時間求和的值，可以理解成汽車的里程表，它只會上升。
• measure: 隨時間聚合的值。它表示某個定義范圍內的值。
• observer: 捕捉特定時間點的一組當前值，如車輛中的燃油表。

• Logs

日志是帶有時間戳的文本記錄，可以是帶有元數據結構化的，也可以是非結構化的。雖然每個日志都是獨立數據源，但可以附加到 Trace 的 Span 中。日常使用調用時，在進行節點分析時出伴隨着也可看到日志。
在 OpenTelemetry 中，任何不屬於分布式 Trace 或 Metrics 的數據都是日志。日志通常用於確定問題根因，通常包含有關誰更改了內容以及更改結果的信息。

• Traces

Trace 指單個請求的追蹤，請求可以由應用程序發起，也可以由用戶發起。分布式 Tracing 是跨網絡，跨應用的追蹤形式。每個工作單元在 Trace 中被稱為 Span，一個 Trace 由一個樹形的 Span 組成。Span 表示經過應用程序所設計的服務或組件所做工作的對象，Span 還提供了可用於調試可用性和性能問題的請求、錯誤和持續時間的 Metrics。Span 包含了一個 Span 上下文，它是一組全局唯一標識符，表示每個 Span 所屬的唯一請求。通常我們稱之為 TraceID。

• Baggage

除了 Trace 的傳播，OpenTelemetry 還提供了 Baggage 來傳播鍵值對。Baggage 用於索引一個服務中的可觀察事件，該服務包含同一事務中先前的服務提供的屬性，有助於在事件之間建立因果關系。雖然 Baggage 可以用作其他橫切關注點的原型，但這種機制主要是為了傳遞 OpenTelemetry 可觀測性系統的值。這些值可以從 Baggage 中消費，並作為度量的附加維度，或日志和跟蹤的附加上下文使用。

僅僅是第一步，還是一站式？

結合上面的內容，我們可以看到 OpenTelemetry 覆蓋了各類可觀測數據類型的規范定義、API 定義、規范實現以及數據的獲取與傳輸。應用只需要一種 SDK 就可以實現所有類型數據的統一產生；集群只需要部署一個 OpenTelemetry Collector 便可以實現所有類型數據的采集。而且 Metrics、Tracing、Logging 的具有相同的 Meta 信息，可以做無縫關聯。

OpenTelemetry 要解決的是可觀測性數據統一的第一步，通過 API 和 SDK 來標准化可觀測數據的采集和傳輸，OpenTelemetry 並不想對所有組件都進行重寫，而是最大程度復用業界在各大領域常用工具，通過提供一個安全、無關平台、無關廠商的協議、組件、標准。其自身定位很明確：數據采集和標准規范的統一，對於數據如何去使用、存儲、展示、告警，官方是不涉及的。但就可觀測整體方案而言，OpenTelemetry 只完成了數據統一生產部分，后續如何存儲、利用這些數據進行分析、告警等並沒有明確提供相關方案，但這些問題又非常突出。

• 各類數據的存儲方式

Metrics 可以存在 Prometheus、InfluxDB 或者各類時序數據庫；Tracing 可以對接Jaeger、OpenCensus、Zipkin。但如何進行選型以及后續進行運維這些后端服務是個很難抉擇的問題。

• 數據分析（可視化與關聯）

對於所采集的數據如何進行統一分析？不同數據需要不同的數據平台進行處理，想要在統一平台顯示 Metrics、Logging、Tracing 並實現三者關聯跳轉，需要很多定制開發工作。這對於運維而言是個很大的工作量。

• 異常檢測與診斷

除了日常可視化監控之外，對應用異常檢測和根因診斷是運維的重要業務需求，這時就需要把 OpenTelemetry 的數據融入到 AIOps 中。但對很多開發及運維團隊而言，基礎的 DevOps 都尚未完全落地，更何況更進一步的 AIOps。

最佳實踐：通過 OpenTelemetry 接入應用實時監控服務 ARMS

針對上述問題，阿里雲提供了應用實時監控服務 ARMS，幫助運維團隊解決數據分析、異常檢測與診斷問題。ARMS 支持多種方式接入 OpenTelemetry Trace 數據，您可以將 OpenTelemetry Trace 數據直接上報至 ARMS，或通過 OpenTelemetry Collector 轉發。

（1）直接上報

• 通過 ARMS Java Agent 接入 OpenTelemetry Trace 數據 Java 應用推薦安裝 ARMS Java Agent。ARMS Java Agent 內置了大量通用組件的鏈路埋點，能夠自動上報 OpenTelemetry 格式的 Trace 數據，開箱即用，無需額外配置。具體操作，請參見監控 Java 應用[2]。

• 結合 ARMS Java Agent 與 OpenTelemetry Java SDK 上報 Trace 數據 v2.7.1.3 及以上版本的 ARMS Java Agent 支持 OpenTelemetry Java SDK 擴展。您在使用 ARMS Java Agent 自動獲取通用組件 Trace 數據的同時，還可以通過OpenTelemetry SDK 擴展自定義的方法埋點。具體操作，請參見 OpenTelemetry Java SDK支持[3]。

• 通過 OpenTelemetry 直接上報 Trace 數據您也可以使用 OpenTelemetry SDK 進行應用埋點，並通過 Jaeger Exporter 直接上報 Trace 數據。具體操作，請參見通過 OpenTelemetry 上報 Java 應用數據[4]。

（2）通過 OpenTelemetry Collector 轉發

• 通過 ARMS for OpenTelemetry Collector 轉發 Trace 數據

在容器服務 ACK 環境下，您可以一鍵安裝 ARMS for OpenTelemetry Collector，通過它進行 Trace 數據的轉發。ARMS for OpenTelemetry Collector 實現了鏈路無損統計（本地預聚合，統計結果不受采樣率影響），動態配置調參，狀態管理以及開箱即用的 Trace Dashboard on Grafana，同時更加易用、穩定、可靠。
ARMS for OpenTelemetry Collector 的接入流程如下：

通過 ACK 控制台應用目錄安裝 ARMS for OpenTelemetry Collector。
a. 登錄容器服務管理控制台[5]。
b. 在左側導航欄選擇市場 > 應用市場。
c. 在應用市場頁面通過關鍵字搜索 ack-arms-cmonitor 組件，然后單擊 ack-arms-cmonitor。
d. 在 ack-arms-cmonitor 頁面單擊右上角的一鍵部署。
e. 在創建面板中，選擇目標集群，然后單擊下一步。說明命名空間默認為 arms-prom。
f. 單擊確定。
g. 在左側導航欄單擊集群，然后單擊剛剛安裝了 ack-arms-cmonitor 組件的集群名稱。
h. 在左側導航欄選擇工作負載 > 守護進程集，在頁面頂部選擇命名空間為 arms-prom。
i. 單擊 otel-collector-service。查看 otel-collector-service（Service）是否正常運行，如下圖所示對外暴露了多種 Receivers 端口接收 OpenTelemetry 數據，則表示安裝成功。

在這里插入圖片描述

修改應用 SDK 中的 Exporter Endpoint 地址為 otel-collector-service:Port。

在這里插入圖片描述 • 通過開源 OpenTelemetry Collector 轉發 Trace 數據

使用開源的 OpenTelemetry Collector 轉發 Trace 數據至 ARMS，只需要修改 Exporter 中的接入點（Endpoint）和鑒權信息（Token）。

exporters:   otlp:     endpoint: <endpoint>:8090     tls:       insecure: true     headers:       Authentication: <token>

說明

• 將替換為您上報區域對應的 Endpoint，例如： http://tracing-analysis-dc-bj.aliyuncs.com:8090。

• 將替換為您控制台上獲取的 Token，例如：b590lhguqs@3a7*********9b_b590lhguqs@53d *****8301。

（3）OpenTelemetry Trace 使用指南

為了更好的發揮 OpenTelemetry Trace 數據價值，ARMS 提供了鏈路詳情、預聚合大盤、Trace Explorer 后聚合分析、調用鏈路關聯業務日志等多種診斷能力。

• 鏈路詳情在鏈路詳情面板左側可以查看鏈路的接口調用次序與耗時，面板右側展示了詳細的附加信息和關聯指標，例如數據庫 SQL，JVM 和 Host 監控指標等。
在這里插入圖片描述

• 預聚合大盤 ARMS 基於 OpenTelemetry Trace 數據提供了多種預聚合指標大盤，包括應用總覽，接口調用，數據庫調用等。

在這里插入圖片描述

• Trace Explorer 后聚合分析針對 OpenTelemetry Trace 數據，ARMS 提供了靈活的多維篩選與后聚合分析能力，例如查詢特定應用的異常鏈路。還可以根據 IP、接口等維度對 Trace 數據進行聚合。

在這里插入圖片描述

• 調用鏈路關聯業務日志 ARMS 支持將 OpenTelemetry Trace 與業務日志相關聯，從應用接口角度排查業務異常問題。

在這里插入圖片描述