OpenTelemetry系列（四）｜如何使用Java Agent来实现无侵入的调用链

矫情吗；* 2023-10-03 22:31 26阅读 0赞

## 前言 ##

在前文中我们已经介绍了`OpenTelemetry`的种种使用方式，然后真的当大家们自己接入的时候可能会有这样的问题“接入调用链需要引入sdk，我们线上应用这么多要改到猴年马月啊”，然后不禁开始怀疑起了人生，然后对于接入调用链也没有最开始那么积极。

确实如上面所说SDK的形式很多时候对于已经在线上稳定运行的应用来说是一个不小的改造负担，不仅麻烦而且后续升级困难，如果SDK有bug，后续的修复也成为了难题。但是调用链技术发展到当下已经比较成熟了，对于Java来说，Java Agent技术就可以帮助实现调用链的无侵入式接入。

## Java Agent ##

### 什么是Java Agent ###

`Java Agent`一般可以被称为探针，是一种可以在Java应启动前和运行中修改应用的字节码的技术。通过在启动项中添加`-javaagent:path/to/agent.jar`来制定使用特定的Agent。

### Java Agent的优势 ###

使用`Java Agent`可以无侵入式的对应用代码进行修改，而应用本身可以不用进行任何的修改。而且因为`Java Agent`是基于字节码的修改，因此非常适合应用在AOP的领域。具体的`Java Agent`的细节就不在此讨论了，后续大家有兴趣我可以另写一篇相关的介绍文章。

## OpenTelemetry Java Instrumentation ##

### 介绍 ###

[opentelemetry-java-instrumentation][]是一个隶属于OpenTelemetry系列的项目，这个项目就是一个基于`Java Agent`来实现无侵入式`OpenTelemetry`接入的官方Agent项目。使用方法非常简单：

java -javaagent:path/to/opentelemetry-javaagent.jar -jar myapp.jar
    复制代码

将`opentelemetry-javaagent.jar`下载下来，然后使用上述指令就能够运行，在启动成功后`OpenTelemetry`就能够直接接入成功，而不用对应用本身的代码进行任何的修改。

### 启动项参数配置 ###

虽然只要接入Agent然后简单启动就算是接入成功了，但是实际上这样是远远不够的。需要进行一些配置来让我们的调用链能够完成完整的接入。

#### collector地址 ####

首先我们在前面的文章里面提到过了，客户端产生的数据最终还是要发送到服务端的采集器进行统一收集整理，这样才能够处理出完整的调用链的信息。因此实际上我们需要在客户端配置服务端`Collector`的地址。

Agent内部默认的collector地址是`http://localhost:4317`，我们配置自己的采集器地址。

`Trace`，`Metrics`和`Logs`的采集器地址均可以自行配置，在此处我们以`Trace`配置来举例：

*  `otel.traces.exporter`用来配置数据输出的`exporter`，此处默认是`otlp`，但是`jaeger`，`zipkin`等等也在支持的范围之内，可以根据自己的需求进行配置。
 *  `otel.exporter.otlp.trace.endpoint`用来配置具体的采集端点地址，注意此配置仅生效于`otlp`，如果是`jaeger`等其他，需要自行使用其他配置。一般来说的话：`gRPC`协议使用`4317`端口，`http`协议使用`4318`端口（建议使用`gRPC`）
 *  `otel.metrics.exporter`这个是`metrics`的配置，在此处必须要特地提醒一下，在旧版本中这个值默认为`none`，即不开启。但是在较新的版本中这个值默认变成了`otlp`，因此需要提醒下如果不需要`metrics`的能力，需要在新版本中将这个值手动设置为`none`

#### 服务名 ####

使用`otel.service.name`来配置服务的名称，此名称会在后续多次被使用到，最好进行正确的配置。

#### 插件的开启与关闭 ####

使用`otel.instrumentation.*.enabled`可以配置插件的开启与关闭，例如：`otel.instrumentation.kafka.enabled`可以用来配置kafka组件的开关。在Agent中内置了大量的`Instrumentation`（可以理解为插件或者仪器），这部分插件并不一定你全都想要，因此使用这个配置可以自定义你需要使用到的插件列表。

**上述列举的都是一些你必须要重点关注到的配置，如果需要进行更多的拓展，开启更多的功能，使用更多的配置，可以参考[文档][Link 1]**

### instrumentation ###

我们可以把`instrumentation`简单理解为插件。

Agent的调用链的强大的采集数据能力说白了就是一个又一个的`Instrumentation`来支撑起来的。每一个不同的SDK都需要定制`Instrumentation`来支持其调用链的能力。`OpenTelemetry`丰富的`Instrumentation`库为完整的调用链能力赋予了巨大的可用性。这个是目前支持的库的[列表][Link 2]

### Logger MDC ###

如果你想要在日志中直接绑定并且看到`TraceId`和`SpanId`可以借助`Logger`的`MDC`能力。

在Agent中默认开启了日志的`Instrumentation`组件，其中的`MDC`相关组件实现了trace信息传递的能力，因此可以直接使用`%mdc{trace_id} %mdc{span_id} %mdc{trace_flags}`来输出trace的相关信息。

例如在logback中可以这么写（`%mdc`和`%X`等价）：

<property name="pattern" value="%d [%thread] %-5p [%c] [%F:%L] [trace=%X{trace_id:-},span=%X{span_id:-}] - %msg%n"/>
    复制代码

## 总结 ##

在这个篇章中我们简单的介绍了`OpenTelemetry Java Instrumentation`的使用，实际上这个项目支持了不少自定义的扩展能力。在下一个篇章中，会着重介绍如何在`OpenTelemetry Java Instrumentation`进行二次开发。

[opentelemetry-java-instrumentation]: https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2Fopen-telemetry%2Fopentelemetry-java-instrumentation
[Link 1]: https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2Fopen-telemetry%2Fopentelemetry-java%2Fblob%2Fmain%2Fsdk-extensions%2Fautoconfigure%2FREADME.md
[Link 2]: https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2Fopen-telemetry%2Fopentelemetry-java-instrumentation%2Fblob%2Fmain%2Fdocs%2Fsupported-libraries.md