共计 2428 个字符,预计需要花费 7 分钟才能阅读完成。
前言
在前文中咱们曾经介绍了 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
(能够了解为插件或者仪器),这部分插件并不一定你全都想要,因而应用这个配置能够自定义你须要应用到的插件列表。
上述列举的都是一些你必须要重点关注到的配置,如果须要进行更多的拓展,开启更多的性能,应用更多的配置,能够参考文档
instrumentation
咱们能够把 instrumentation
简略了解为插件。
Agent 的调用链的弱小的采集数据能力说白了就是一个又一个的 Instrumentation
来撑持起来的。每一个不同的 SDK 都须要定制 Instrumentation
来反对其调用链的能力。OpenTelemetry
丰盛的 Instrumentation
库为残缺的调用链能力赋予了微小的可用性。这个是目前反对的库的列表
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
进行二次开发。