共计 12023 个字符，预计需要花费 31 分钟才能阅读完成。
作者：可观测
随同着分布式应用、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/
点击此处，理解阿里云可观测更多资讯！
