【云原生】springboot 整合 OpenTelemetry

OpenTelemetry 并不是一个完整的可观测性平台，因为它本身不提供处理、存储、和查询遥测数据的方式，它允许你从应用程序中，收集和导出数据到各种商业和开源后端。
OpenTelemetry 提供了可插拔的架构，使得开发人员能够轻松添加技术协议和格式，支持的开源项目包括 Prometheus的指标格式，通过接入开源的监控软件，方便从各种后端存储中查询指标数据，以及用于存储和查询追踪数据的Jaeger和Zipkin等跟踪协议。

遥测数据是指为了达到可观测系统的目的而从源系统收集的任何可输出的数据，这些数据一起进行分析，以查看分布式系统内的依赖关系和关联。

目前主要有三种类型的数据被称为可观测性的三大支柱，即日志，指标和追踪，随着时间的推移，OpenTelemetry 可以扩展以收集其他类型的遥测数据，比如性能分析，和端用户监控等。

3.2 OpenTelemetry架构和组件

如下是一张关于OpenTelemetry 包含了核心组件的架构图，关于其中的各个组件下面做详细的介绍。

Application

一般的应用程序，同时使用了 OpenTelemetry 的 Library (实现了 API 的 SDK)。即按照特定的格式生成遥测数据，比如跟踪、指标和日志，可能涉及到使用OpenTelemetry 的SDK相关代码，并使用OpenTelemetry API来创建和导出遥测数据。

SDK

OpenTelemetry SDK（软件开发工具包）是一个库和工具的集合，使开发人员能够对其应用程序进行检测并收集遥测数据以进行监控。通常用于负责在客户端程序里采集观测数据，包括 metrics，traces，logs，对观测数据进行处理，之后观测数据按照 exporter 的不同方式，通过 OTLP 方式发送到 Collector 或者直接发送到 Backend 中。

exporter

导出器，将应用生成的遥测数据导出发送到不同的后端服务，比如skywalking的OAP，jaeger等，导出器负责将数据转换为适当的格式并发送到指定的目标服务上去。

比如，你可以配置一个导出器将追踪的数据发送到Zipkin，通常导出器在Agent中已经集成进去，应用程序只需要按照规范集成，或配置即可；
下一个导出器负责将数据发送到可视化的展示平台中，比如Prometheus；
还可以将搜集的数据发送到es中；

Receiver

接收器，收集器需要使用接收器来接收来做各个应用程序的遥测数据。接收器一般允许多种协议，比如OTLP，HTTP等，方便接收数据。比如通常使用接收器接收微服务应用中的跟踪数据和指标数据，或者特定格式输出的日志数据。

Collector

收集器，在应用程序与上报的应用后端之间，存在一个或多个OpenTelemetry收集器。这些收集器接收来做应用程序中的遥测数据，然后根据配置或指定的过滤条件进行处理和筛选。它们充当了一个缓存层，以确保数据以可靠的方式发送到后端，并且不会对应用程序本身造成性能上的重大影响。

Telemetry后端

最后，收集器收集的遥测数据被上报到遥测后端，用于存储，查询和可视化展现，存储的选择可以有多种，比如mysql，es等，而展现通常借助一些可视化的工具，比如prometheus，ELK，grafana 等。通过展现的可视化指标数据一方面可以监控应用程序的整体情况，另一方面还能识别系统的性能问题。

四、OpenTelemetry与OpenTracing

其实在OpenTelemetry 之前，链路追踪与应用可观测概念已经被提出来了，而且行业中逐渐出现了一些解决方案，但并没有形成一套系统的标准或规范。

对于很多开发人员来说，想让应用支持分布式追踪太难了。不仅需要在进程内进行追踪数据的传递，还要在进程之间传递。更难的是，还需要其他组件对分布式跟踪的支持，比如 NGINX, Cassandra, Redis 等开源服务，或者在服务内引入的 gRPC, ORMs 等开源库。

在 OepnTracing 之前，一方面，很多分布式追踪系统通过使用不兼容 API 的应用程序级检测进行实现，这使得开发人员对应用与任何特定的分布式跟踪紧密耦合。另一方面，这些应用程序级检测 API 具有非常相似的语义。为了解决不同的分布式追踪系统 API 不兼容问题，或者说追踪数据从一个库到另一个库和一个进程到下一个进程传递过程中的标准化问题，诞生了 OpenTracing 规范。位于应用程序/类库和追踪或日志分析程序之间的轻量级标准化层。

4.1 OepnTracing 优势与特点

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 等框架中；

4.2 OpenCensus

在整个可观测领域，为了更好实现 DevOps，除了分布式追踪 Trace，应用系统开始关注 Log 和 Metrics。Metrics 指标监控作为可观测的重要组成部分，包括 CPU、内存、硬盘、网络等机器指标，gRPC 请求延迟、错误率等网络协议指标，用户数、访问数等业务指标。

OpenCensus 提供了统一的测量工具：跨服务捕获跟踪跨度 Span、应用级别指标 Metrics。

OpenCensus特点：

标准通信协议和一致的 API ：用于处理 Metrics 和 Trace；
多语言库支持：Java、C++、Go、.Net、Python、PHP、Node.js、Erlang 、Ruby；
与 RPC 框架的集成；
集成存储和分析工具；
完全开源并支持三方集成和输出的插件化；
不需要额外服务器或 Agent 来支持 OpenCensus；

OpenCensus优势：

相较于 OpenTracing 只支持 Traces，OpenCensus 同时支持 Traces 和 Metrics；
相较于 OpenTracing 制定规范，OpenCensus 不仅制定规范，还包含了 Agent 和 Collector；
生态和背书背景相较 OpenTracing 更加庞大，获得 Google、微软支持；

4.3 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 去兼容。

4.3.1 OpenTelemetry特点

为了更好的将 Traces、Metrics 和 Logs 融合在一起，OpenTelemetry 诞生了。作为 CNCF 的孵化项目，OpenTelemetry 由 OpenTracing 和 OpenCensus 项目合并而成，是一组规范、API 接口、SDK、工具和集成。为众多开发人员带来 Metrics、Tracing、Logs 的统一标准，三者都有相同的元数据结构，可以轻松实现互相关联。

OpenTelemetry 与厂商、平台无关，不提供与可观测性相关的后端服务。可根据用户需求将可观测类数据导出到存储、查询、可视化等不同后端，如 Prometheus、Jaeger 、云厂商服务中。当前，像阿里云，腾讯云等云厂商都提供了基于OpenTelemetry的云上解决方案，方便应用快速接入。

4.3.2 OpenTelemetry优势

OpenTelemetry具备如下优势：

打破各厂商各自为战的混乱局面，OpenTelemetry 的出现，旨在通过提供标准化 instrumentation 框架打破各厂商的接入壁垒，作为一个可插拔的服务，可轻松添加常见的技术协议与格式，让服务选择更加自由；
指定规范统一协议，OpenTelemetry 采用基于标准的实现方法，在解决跨语言的联通上更友好，许多语言都带有类型定义，可以在实现中使用，例如用于创建可重用组件的接口。包括可观测客户端内部实现所需要的规范，以及可观测客户端与外部通信所需实现的协议规范；
多语言 SDK 的实现和集成，OpenTelemetry 为每个常见语言都实现了对应 SDK，将导出器与 API 结合在一起。SDK 是具体的、可执行的 API 实现。包含 C++、.NET、Erlang/Elixir、Go、Java、JavaScript、PHP、Python、Ruby、Rust、Swift；
数据收集系统的实现，为了尽量减少数据收集的过程对应用的影响，OpenTelemetry 提供了基于 OpenCensus Service 的收集系统，包括 Agent 和 Collector，Collector 涵盖采集（Collect）、转换（Transform）和导出（Export）可观测数据的功能，支持以多种格式（例如 OTLP、Jaeger、Prometheus 等）接收可观测数据，并将数据发送到一个或多个后端。它还支持在输出可观测数据之前，对其进行处理和过滤。Collector contrib 软件包支持更多数据格式和后端；
自动代码注入技术，OpenTelemetry 也开始提供可以自动代码注入的实现，目前已经支持Java各类主流框架的自动注入；
云原生架构支持，OpenTelemetry 设计之初就已经考虑了云原生的特性，并且还提供了 Kubernetes Operator 用于快速部署使用；

4.4 三者之间的关系

OpenTelemetry ，OpenCensus 以及OpenTracing 都是与应用可观测性相关的项目和标准，它们之间有一定的关系和演进历史，结合上文的介绍，具体来说：

OpenTracing 是最早出现的项目之一，旨在为追踪(tracing)提供一个标准的API和规范，侧重于跟踪应用程序中的请求和操作，以帮助开发人员理解请求在分布式系统中的流程和性能，但是OpenTracing 并未覆盖指标和日志等遥测数据；
OpenCensus 是一个更综合的项目，旨在提供跟踪，指标和日志等全方位的遥测支持，可以说是OpenTracing 的扩展，添加了指标和日志的支持，从而能够全方位的监视应用程序的性能。OpenCensus 具有多语言支持和多后端支持，使得开发人员能够集成不同的技术栈和监视后端；
OpenTelemetry 实际上是OpenTracing 和OpenCensus 的合并和继承，它吸取了两个项目的经验和功能，提供了一个统一的标准和API，用于生成、收集和导出跟踪、指标和日志等遥测数据。OpenTelemetry 具有更广泛的支持，包括各种编程语言和集成后端，还具有模块化结构，并允许用户自定义其遥测方案；

综合来说，OpenTelemetry 可以看作是OpenTracing 和OpenCensus 的下一代，它整合了这两个项目的优点，并提供了更加全面的可观测性方案，因此如果你在实际项目中考虑集成，建议选择OpenTelemetry ，因为它代表了未来的方向，并且具有更丰富的功能和更广泛的支持。

五、OpenTelemetry 常用实现方案

OpenTelemetry 在实际的架构选择中有很多种组合和实现方案，接下来分别来了解一下 OpenTelemetry 的常用实现方案。

5.1 OpenTelemetry与开源工具的组合

OpenTelemetry 作为经典的对各各类遥测数据处理架构，使用开源工具可将不同类型的数据存储在不同的平台，比如日志存放在 ELK，追踪存放在 Jaeger 这类云原生友好的APM 工具，而指标保存在 Prometheus 并通过 Grafana 进行视图展示。组件的整体配置如下图所示：

5.1.1 业务流程分析

以Java技术栈中使用springboot构建的微服务应用来说，按照上述的流程，其完整的数据采集和传输过程如下：

前端页面请求服务端API，服务端集成相关SDK并结合Agent的方式，将链路追踪信息推送到 Collector；
Collector 对数据进行收集和转换后，将数据推送到 Jaeger；
同时， Prometheus 从 Collector 拉取数据，并通过Grafana将指标数据进行展现；

从上图不难发现，需求的不同或者说实际在技术选型时的复杂性要求不同，有的只需要展示日志，有的同时需要展示指标，日志以及链路监控数据，其方案选择也略有不同，比如在上图中针对日志收集就有两种不同的方式：

方式一，通过 OTLP 上报日志，应用服务端和客户端将日志通过 Exporter 推送到 Collector，再通过 Collector 输出到 Elasticsearch，由于 OpenTelemetry 在 log 方面还不稳定，推荐单独处理日志，不走 Collector；
方式二，通过 Logback 上报日志，应用服务端和客户端将日志通过 Logback 推送到 Logstash（需要使用 Logstash-Logback 组件，是 Logstash 的 Logback 实现），这也是行业中一种比较成熟的解决方案。

5.1.2 OpenTelemetry 结合Grafana

随着近些年可观测性的流行，Prometheus得到广泛的应用，同时Grafana也开始出现在人们的视野中，Prometheus与Grafana的结合，让可观测性的展现更加全面也更加友好，使用 Grafana 对接 OpenTelemetry 的架构如下图所示，这里面主要用到 Grafana Tempo 和 Loki 两个组件：

对于流程中的各个组件做如下介绍：

Grafana Tempo 是一个开源、易于使用且大规模的分布式追踪后端。Tempo 具有成本效益，只需要对象存储即可运行，而且它可以和 Grafana、Prometheus 、 Loki 深度集成。Tempo 可以与任何开源跟踪协议一起使用，包括 Jaeger、Zipkin 、 OpenTelemetry；
Loki 是 Grafana Labs 团队最新的开源项目，是一个水平可扩展，高可用性，多租户的日志聚合系统。Loki 的设计非常经济高效且易于操作，因为它不会为日志内容编制索引，而会为每个日志流编制一组标签；

整个执行流程如下：

OpenTelemetry 采集输出 Springboot 应用的链路追踪数据，并为对应的日志打上 TraceID、SpanID 等标签；
empo 收集处理 OpenTelemetry 数据并本地化存储，Tempo Query 为 Tempo 的检索后端服务；
Loki 收集微服务应用的日志数据；
最后，可以通过 Grafana Dashboard 展示和查看 Tempo 链路追踪和日志数据；

“ Grafana Tempo + Loki” 这个组合能够让我们直观地看到日志链路情况，但 Loki 的特性也决定了它并不能高效分析和处理大型生产系统的日志。日志链路只是可观测的一部分，仅仅通过日志链路查询并不能解决大部分问题，特别是在微服务云原生架构时代，多种多样的问题需要我们结合各方面进行分析。

5.1.3 OpenTelemetry 结合观测云

随着云服务商提供的云上服务能力增强，像阿里云，腾讯云等服务商也开始逐步涉入OpenTelemetry ，如下是两大云厂商的接入点：

腾讯云接入点：手动埋点上报-应用性能监控-文档中心-腾讯云

阿里云接入点：如何快速接入可观测链路 OpenTelemetry 版 – 可观测链路 OpenTelemetry 版 – 阿里云

观测云特点：

观测云允许包括开发、测试、运维在内的所有团队成员在一套统一的可观测数据体系下客观分析与定位故障，便于高效地协作；
观测云能够采集指标、链路、日志以及所有的可观测数据，并将它们进行关联和整合分析，实现系统完整的可观测性；
观测云的数据采集 Agent 是 DataKit ，它能够支持主机和容器的环境；

关于DataKit 做如下补充说明：

在主机环境下, 每个主机都有一个 DataKit , 数据会先打给本地的 DataKit , 由 DataKit 缓存，预处理，然后上报到观测云的数据网关。这就在避免了网络抖动的同时，附带了边缘处理能力，缓解了后台处理数据的压力；
在 Kubernetes 环境下, 每个节点（即 Node）都有一个 DataKit 的 DaemonSet，通过 Kubernetes 的 local traffic 机制，每个节点中 Pod 的数据都会先发送本地的 DataKit。这就在避免网络抖动的同时, 为链路追踪数据增加了 Pod 和 Node 标签，能够有效地关联数据；

由于 DataKit 是接收 OTLP 协议的，所以我们可以把 OpenTelemetry Collector 的 Exporter 设置为 OTLP（指向 DataKit），也可以直接将数据打给 DataKit。因此这里有两种方案。

方案一：

方案二：

4.1.4 OpenTelemetry 与云厂商

当众多的云厂商也介入应用可观测性领域，微服务与OpenTelemetry 的整合集成就变得更容易了，对客户端来说，甚至不需要独立部署用于链路展示的服务平台，而是直接将遥测数据上报到云平台即可，由云平台提供大屏展示的链路数据，指标数据等。

五、微服务使用OpenTelemetry接入jaeger

5.1 jaeger简介

aeger是一款广受欢迎的开源分布式链路跟踪系统，受到Zipkin的启发由 Uber 创建的分布式追踪平台，用于监控和诊断分布式应用程序和微服务架构中的性能问题。官网地址：jaeger官网

它兼容OpenTracing API，且已加入CNCF开源组织。其主要功能是聚合来自各个异构系统的实时监控数据。它用于监控和故障排查基于微服务的分布式系统，其核心功能点如下：

全链路追踪， Jaeger 支持全链路追踪，允许您追踪请求在不同服务之间的传播路径，帮助用户了解整个操作流程和性能瓶颈；
跨度（Span），在 Jaeger 中，每个操作或步骤都被称为跨度（Span），包括起始时间、结束时间、操作名称、标签等信息；
上下文传递， Jaeger 使用 Trace ID 和 Span ID 来传递上下文信息，以确保在整个操作链路中跟踪相关的事件；
性能指标，除了追踪数据，Jaeger 还可以收集和显示性能指标，如响应时间、调用次数、错误率等；
数据存储， Jaeger 支持多种后端存储，如Elasticsearch、Cassandra、Kafka等，用于存储和查询追踪数据；
数据可视化， Jaeger 提供直观的数据可视化仪表板，用于展示追踪数据、性能指标和系统拓扑图；
告警与通知， Jaeger 可以与警报系统集成，帮助用户设置和触发性能和健康问题的警报通知；

5.1.1 jaeger架构图

下面是官方给出的架构图

对于这张图中，几个核心的组件做如下说明：

Agent ，Agent 是部署在每个应用程序节点上的代理程序，用于捕获应用程序内的跟踪数据；
Collector 接收来自各个应用程序节点的跨度数据，并将其存储到后端存储，比如：Elasticsearch、Cassandra、Kafka中；
Storage，存储模块用于保存跨度数据和性能指标，Jaeger 支持多种后端存储，包括：Elasticsearch、Cassandra、Kafka等，用户可以根据需求选择合适的存储引擎；
Query，查询模块用于从存储中检索和查询跨度数据，它提供了一个Web界面，使用户可以通过可视化界面了解追踪数据、性能指标和应用地图；
Ingester ，Ingester 模块负责将采集到的数据发送到后端存储，并提供了数据导入的功能，可以从其他数据源导入历史数据；
Agent/Instrumentation Libraries，提供了多种编程语言的客户端库和工具，用于在应用程序中插入追踪代码，从而捕获和发送跨度数据；
Collector/Ingester/Query UI，这些组件提供了用户界面，允许用户配置、监控和查询追踪数据，了解应用程序的性能和运行状况；

5.1.2 jaeger优势

可扩展性好

Jaeger后端为无单点故障设计，可随时根据需要进行扩展ub，er每天使用它处理几十亿级别的span

原生支持OpenTracing

Jaeger后端、webUI、以及相关的框架适配库的设计实现都是支持OpenTracing标准的；

支持云原生部署

官方已将Jaeger后端打包为docker镜像发布；

二进制文件支持CLI选项、ENV、配置文件方式三种方式加载配置；

K8s部署，参考Kubernetes operator, Kubernetes templates and a Helm chart

支持可观测性组件集成

Jaeger后端组件均支持暴露指标到Prometheus（其他监控后端也支持）；

Log是通过第三日志库zap写到stdout；

向后兼容Zipkin client

如果你已经使用Zipkin作为trace平台，并且希望迁移到Jaeger，不用太担心；
无需重写client代码，Jaeger后端支持Zipkin格式的span，只需要将数据的转发目的地指向Jaeger后端就行。

5.1.3 jaeger小结

Jaeger 在架构的设计上沿用了 Zipkin 的架构风格，两者具备很多类似的特性，除了开发语言不同而已。作为后起之秀，基于 Go 的强大特性，使得 Jaeger 在基于云原生生态领域中能够如鱼得水，具备强大的号召力，甚至在一些新技术框架领域中，作为默认首选的分布式链路追踪系统，落地于各种不同的业务场景。虽然已在 2012 年启动研发，但相对于 2017 年启动的 Jaeger 而言，Zipkin 与 Jaeger 在社区中发展势态几乎没多大差异，从侧面说明，Jaeger 已成为新一代的云原生链路追踪系统的布道者。其支持跨平台、多样性的组件追踪，例如：分布式边缘路由组件 Traefik、下一代微服务体系 Istio 等等。

下列表简要对比了下当前在各大企业中，所采用链路追踪系统的特性对比情况，具体来说：

5.2 jaeger搭建

后面我们会通过微服务集成OpenTelemetry，然后将链路追踪信息上报jaeger并通过jaeger进行展示，下面通过docker搭建jaeger服务。

5.2.1 获取镜像

docker pull jaegertracing/all-in-one:latest

5.2.2 启动容器

使用下面的命令启动一个jaeger容器

docker run -d --name jaeger 
  -e COLLECTOR_ZIPKIN_HOST_PORT=:9411 
  -p 5775:5775/udp 
  -p 6831:6831/udp 
  -p 6832:6832/udp 
  -p 5778:5778 
  -p 16686:0.0.0.0/0 
  -p 14250:14250 
  -p 14268:14268 
  -p 14269:14269 
  -p 9411:9411 
  jaegertracing/all-in-one:latest

5.2.3 访问web界面

访问地址：http://IP:16686/search，看到如下界面；

5.3 springboot接入jaeger

使用过skywalking的同学应该不陌生，在springboot中要想通过skywalking监控服务链路并展示链路信息，只需要启动时利用skywalking提供的Agent，然后指定skywalking服务端端点即可。

同样，如果需要将springboot服务的链路追踪信息上报jaeger，也需要一个Agent，或者手动埋点，或者集成sdk的方式结合编码进行，这里提供一种最简单的操作方案，即使用OpenTelemetry提供的Agent方式进行集成。下载Agent，opentelemetry-javaagent.jar，下载地址：agent下载地址

选择具体的版本之后，下载第一个agent的包

5.3.1 编写测试接口

@RestController
@RequestMapping("/user")
@Slf4j
public class UserController {

    @Autowired
    private UserService userService;

    //http://localhost:8088/user/get?userId=001
    @GetMapping("/get")
    public Object getUserInfo(String userId){
        Map userInfo = userService.getUserInfo(userId);
        return userInfo;
    }
}

5.3.2 启动服务

启动服务时使用下面的参数

-javaagent:E:code-selfopentelemetry-javaagent.jar -Dotel.service.name=your-service-name -Dotel.traces.exporter=jaeger -Dotel.exporter.jaeger.endpoint=http://jaeger IP:14250

该参数的含义解释：

javaagent …，指定opentelemetry-javaagent.jar的位置；
-Dotel.service.name=user-service，指定启动的服务名称；
-Dotel.traces.exporter=jaeger ，指定exporter使用jaeger；
-Dotel.exporter.jaeger.endpoint，指定上报链路追踪、指标等信息到jaeger的监听端口；

启动完成后，尝试调用一下接口

接口调用成功后，进入到jaeger的UI界面，可以通过trace查看调用的详细信息

5.4 springcloud接入jaeger

也可以使用相同的方式在springcloud中通过Agent上报链路追踪等指标信息到jaeger，以之前的一个工程案例进行说明，在user,order,gateway三个模块中，启动的时候分别使用参数的方式启动

-javaagent:E:code-selfopentelemetry-javaagent.jar -Dotel.service.name=user-service -Dotel.traces.exporter=jaeger -Dotel.exporter.jaeger.endpoint=http://IP:14250


-javaagent:E:code-selfopentelemetry-javaagent.jar -Dotel.service.name=order-service -Dotel.traces.exporter=jaeger -Dotel.exporter.jaeger.endpoint=http://IP:14250


-javaagent:E:code-selfopentelemetry-javaagent.jar -Dotel.service.name=gate-service -Dotel.traces.exporter=jaeger -Dotel.exporter.jaeger.endpoint=http://IP:14250

服务启动后，通过走网关调用一下接口

然后通过UI界面检查jaeger的服务监控信息，服务是从order发起的，我们检查下上面的接口

点击进去之后可以查看接口调用的详情

也可以在拓扑图中进行视察，服务的调用过程更形象

小结：

事实上，利用jaeger的能力，结合上述的Agent，还可以接入像Prometheus这样的指标可视化的监控组件，从而更详细的了解应用系统的各种指标监控信息。

六、写在文末

本文通过较大的篇幅详细介绍了应用可观测性的理论，以及OpenTelemetry在应用客观性中的使用，最后通过微服务使用OpenTelemetry提供的Agent上报链路追踪信息到jaeger，事实上，OpenTelemetry可以理解为一种标准化的解决思想，在实际项目或技术选型中，可以有多种解决方案，可以结合自身的情况选择一种适合当前业务现状的即可。本篇到此结束感谢观看。

原文地址:https://blog.csdn.net/zhangcongyi420/article/details/135567316

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。

如若转载，请注明出处：http://www.7code.cn/show_57656.html

如若内容造成侵权/违法违规/事实不符，请联系代码007邮箱：suwngjj01@126.com进行投诉反馈，一经查实，立即删除！

声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。

opentelemetry