从Opentracing、OpenCensus 到 OpenTelemetry，看可观测数据标准演进史

作者：可观测

伴跟着分布式运用、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 的接入流程如下：

1. 经过 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 数据，则表示装置成功。

2. 修正运用 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，例如：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 与事务日志相相关，从运用接口视点排查事务反常问题。

相关链接

[1] 《”Dapper – a Large-Scale Distributed Systems Tracing Infrastructure”》 static.googleusercontent.com/media/resea…

[2] 监控 Java 运用 help.aliyun.com/document_de…

[3] OpenTelemetry Java SDK 支撑 help.aliyun.com/document_de…

[4] 经过 OpenTelemetry 上报 Java 运用数据 help.aliyun.com/document_de…

[5] 容器服务办理控制台 cs.console.aliyun.com/

点击此处，了解阿里云可观测更多资讯！ 发布云原生技能最新资讯、聚集云原生技能最全内容，定期举办云原生活动、直播，阿里产品及用户最佳实践发布。与你并肩探索云原生技能点滴，分享你需求的云原生内容。

重视【阿里巴巴云原生】公众号，获取更多云原生实时资讯！