作者：可觀測
伴隨著分散式應用、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 來標準化追蹤資料的格式。
相關產品
遵循 OpenTracing 協議的產品有 Jaeger、Zipkin、 LightStep 和 AppDash 等追蹤元件，並可以輕鬆整合到 gRPC、Flask、Django 和 Go-kit 等開源框架中。
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。
相關產品
遵循 OpenCensus 協議的產品有 Prometheus、SignalFX、Stackdriver 和 Zipkin。
看到這裡，我們可以看到從功能、特性等維度來評估上述兩者。OpenTracing 和 OpenCensus 各有明顯優缺點：OpenTracing 支援語言更多、對其他系統耦合性更低；OpenCensus 支援 Metrics、分散式跟蹤，同時從 API 層一直到基礎設施層都進行支援。對很多開發人員而言，選擇困難症發作的同時，一個新的想法不斷被討論：是否能有一個能夠將 OpenTracing 和 OpenCensus，並且能夠支援 Log 日誌相關可觀測資料的專案呢？
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>替換為您上報區域對應的 Endpoint，例如：http://tracing-analysis-dc-bj...。
• 將<token>替換為您控制檯上獲取的 Token，例如：b590lhguqs@3a79b_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 與業務日誌相關聯，從應用介面角度排查業務異常問題。
相關連結
[1] 《"Dapper - a Large-Scale Distributed Systems Tracing Infrastructure"》
https://static.googleusercont...
[2] 監控 Java 應用
https://help.aliyun.com/docum...
[3] OpenTelemetry Java SDK 支援
https://help.aliyun.com/docum...
[4] 通過 OpenTelemetry 上報 Java 應用資料
https://help.aliyun.com/docum...
[5] 容器服務管理控制檯
https://cs.console.aliyun.com/
點選此處，瞭解阿里雲可觀測更多資訊！