使用分散追踪(OpenTelemetry) (第一部分)
我认为在普通应用程序中使用分散追踪也很方便,所以我想写一些东西。
关于分布式追踪,OpenTracing和OpenTelemetry的内容。
分散追踪是在调试和监控分布式软件架构(如微服务)时非常有用的工具。
在分散追踪中,最著名的是OpenTracing,但是由于出现了许多不同的实现,这并不好。
是否应该统一规范呢?这样的想法也不无道理。
还有一个叫做OpenCensus的项目,将OpenTracing和OpenCensus相结合,形成了OpenTelemetry。
因此,OpenTracing和OpenCensus已经在2019年停止更新了。
OpenTracing API与OpenTelemetry API的兼容性
从现在开始,似乎是OpenTelemetry API的时代了,
关于OpenTracing API的关系可以在以下链接中找到详细信息。
https://opentelemetry.io/docs/migration/opentracing/
概括地描述分散追踪。
概括来说,它与一个请求等同。它是一系列所述Span的集合。
Span是在一个边界内进行的处理。它可以是函数单元,也可以是微服务的服务单元。
根跨度:在Trace的起始跨度上,与整个Trace的时间几乎相同。下图中的跨度A适用于此。
有许多用例可供选择,特别适用于那些涉及跨过程的情况。通过查看https://opentelemetry.io/registry/,例如,可以在Apache→Web应用程序、Apache Camel→Apache Kafka的流程中,一气呵成地追踪并发现性能瓶颈。
随便摇晃
启动Jaeger的Tracer。
根据参考资料,据说Uber开发了一款著名的追踪器。
当使用Docker 安装 All in One 镜像后,可以立即开始运行。
参考文档:https://www.jaegertracing.io/docs/1.35/getting-started/
$ docker run -d --name jaeger \
-e COLLECTOR_ZIPKIN_HOST_PORT=:9411 \
-e COLLECTOR_OTLP_ENABLED=true \
-p 6831:6831/udp \
-p 6832:6832/udp \
-p 5778:5778 \
-p 16686:16686 \
-p 4317:4317 \
-p 4318:4318 \
-p 14250:14250 \
-p 14268:14268 \
-p 14269:14269 \
-p 9411:9411 \
jaegertracing/all-in-one:1.35
你可以在http://localhost:16686/上查看Jaeger的界面。
运行示例的Java应用程序
我們有一個 gRPC 的範例,我們會試著運行它。你可以在這個網址找到相關資訊:https://opentelemetry.io/docs/instrumentation/java/getting-started/
$ git clone -b v1.47.0 --depth 1 https://github.com/grpc/grpc-java
$ cd grpc-java/examples
$ ./gradlew installDist
将 opentelemetry-javaagent.jar 下载并放置在 grpc-java/examples 目录中。
启动服务器
$ cd grpc-java/examples # examplesで実行してください。opentelemetry-javaagent.jarもここに置いておく
$ export OTEL_TRACES_EXPORTER=jaeger
$ export JAVA_OPTS="-javaagent:./opentelemetry-javaagent.jar"
$ ./build/install/examples/bin/hello-world-server
打开客户端
$ cd grpc-java/examples
$ ./build/install/examples/bin/hello-world-client
打开 http://localhost:16686/ 可以查看 Jaeger 的界面。
未知的服务:它似乎是Java等语言,但它会输出。
这样的好处很多,你可以通过环境变量(OTEL_TRACES_EXPORTER)或系统属性轻松切换Opentelemetry的输出方式,非常方便。
接下来,我打算尝试使用Apache Camel或Apache Kafka等来进行多进程组合。