App instrumentation generally involves significant manual effort, with application code invoking logging/metrics/tracing SDKs when something interesting happens. This is useful, but not without its challenges. For one, it’s a lot of work. It also leads to a lot of code cruft. The most consequential challenge, however, is that it mostly results in an inconsistent treatment of observability data (e.g., free-form log messages, metrics data embedded in log messages, unconventional metric and dimension names). There’s little leverage, and it’s hard to do anything systematic with the data.
应用程序检测通常涉及大量的人工工作，并且在发生有趣的事情时，应用程序代码会调用日志记录/指标/跟踪SDK。 这很有用，但并非没有挑战。 首先，这是很多工作。 这也导致很多代码崩溃。 但是，最严重的挑战是，它主要导致对可观察性数据(例如，自由格式的日志消息，嵌入在日志消息中的度量标准数据，非常规的度量标准和维度名称)的处理不一致。 杠杆作用很小，并且很难对数据进行系统的处理。
While manual instrumentation isn’t going anywhere, we can automate more than we typically do. Prometheus, for instance, boasts an impressive arsenal of automated metrics exporters.
尽管手动检测无处不在，但我们可以实现比通常更多的自动化。 例如， 普罗米修斯(Prometheus)拥有大量令人印象深刻的自动化指标出口商 。
In this post we’ll explore a recent and developing offering for automated instrumentation: the OpenTelemetry for Java Instrumentation project. I’ll show you how to use it to add automated tracing to your microservice-based Java application. I’m using opentelemetry-java-instrumentation v0.7.0.
在本文中，我们将探讨一种最新的开发中的自动化仪表产品： Java仪表的OpenTelemetry项目。 我将向您展示如何使用它向基于微服务的Java应用程序添加自动跟踪。 我正在使用opentelemetry-java-instrumentation v0.7.0。
示例应用 (The sample app)
For your convenience, I’ve created a sample Spring Boot app called otel-demo. It’s a toy travel application that doesn’t allow you to do anything other than look at a list of flights from Seattle to Las Vegas. But it turns out that this is good enough to show OpenTelemetry (OTel) auto-instrumentation in action, so may as well keep it simple.
为了您的方便，我创建了一个名为otel-demo的示例Spring Boot应用程序。 这是一个玩具旅行应用程序，除了查看从西雅图到拉斯维加斯的航班列表以外，您不能做任何其他事情。 但是事实证明，这足以显示OpenTelemetry(OTel)自动仪器的实际作用，因此也可以使其保持简单。
Here’s the underlying app architecture:
这是基础的应用程序体系结构：
(Note that the endpoints in the diagram are the endpoints on the Docker Compose network. See the sample app’s README.md for the host-level port mappings.)
(请注意，图中的端点是Docker Compose网络上的端点。有关主机级端口映射，请参见示例应用程序的README.md 。)
Notice that the app itself doesn’t have any observability stuff at all. It doesn’t log anything (besides what Spring Boot itself logs), it doesn’t write metrics, no traces, nothing. I didn’t even activate Spring Boot Actuator. The UI gets flights from an API, which in turn gets flights from two flight providers.
请注意，该应用程序本身根本没有任何可观察性的东西。 它不记录任何内容(除了Spring Boot本身记录的内容)，不记录指标，不显示跟踪信息，不记录任何内容。 我什至没有激活Spring Boot Actuator。 UI从API获取航班，而API又从两个航班提供商获取航班。
Maybe you noticed that the microservice startup scripts reference Jaeger and some kind of OTel Java agent. If so, pretend you didn’t see that yet. We’ll get to it in the next section.
也许您注意到微服务启动脚本引用了Jaeger和某种OTel Java代理。 如果是这样，假装您还没有看到。 我们将在下一部分中进行介绍。
At this point, go ahead and fire up the app:
此时，继续并启动应用程序：
$ docker-compose upAnd then point your browser at http://localhost:8080. You should see the amazing UI from the screenshot above (designed it myself). You may have to wait for all the containers to spin up, so wait a few seconds and retry if you get an error.
然后将浏览器指向http：// localhost：8080。 您应该从上面的屏幕截图(自己设计)中看到令人惊叹的UI。 您可能需要等待所有容器旋转起来，因此请等待几秒钟，然后在遇到错误时重试。
添加自动跟踪 (Adding automated tracing)
OK, now we get to the startup scripts that I just mentioned.
好的，现在我们进入我刚才提到的启动脚本。
To add automated tracing to the app, we attach an instrumentation agent to the JVM using the -javaagent option, and set some system properties that tell the agent where to send trace spans. Here I’m sending the spans directly to Jaeger, a popular tracing system. But there are other possibilities too, such as sending to Zipkin (another popular tracing system) or else an OTLP Collector. See opentelemetry-java-instrumentation for more information.
为了向应用程序添加自动跟踪，我们使用-javaagent选项将检测代理附加到JVM，并设置一些系统属性以告知代理将跟踪范围发送到哪里。 在这里，我将跨度直接发送到流行的跟踪系统Jaeger 。 但是还有其他可能性，例如发送到Zipkin (另一个流行的跟踪系统)或OTLP Collector 。 有关更多信息，请参见opentelemetry-java-instrumentation 。
I downloaded the agent JAR from the opentelemetry-java-instrumentation tags page. Again I’m using v0.7.0 in the sample app. You’ll probably want to use the latest and greatest.
我从opentelemetry-java-instrumentation标签页面下载了代理JAR。 再次，我在示例应用程序中使用v0.7.0。 您可能需要使用最新的和最大的。
Here are the JAVA_OPTS for the UI microservice:
这是UI微服务的JAVA_OPTS ：
JAVA_OPTS="${JAVA_OPTS} \
-Xms${JAVA_XMS} \
-Xmx${JAVA_XMX} \
-Dapplication.name=${APP_NAME} \
-Dapplication.home=${APP_HOME} \
-Dotel.exporter=jaeger \
-Dotel.jaeger.endpoint=jaeger:14250 \
-Dotel.jaeger.service.name=otel-ui \
-javaagent:${APP_HOME}/opentelemetry-javaagent-all.jar"What’s happening behind the scenes? The agent is knowledgeable about a fairly wide range of popular Java libraries and frameworks. During classload, the agent adds tracing instrumentation to targeted locations via bytecode injection. The app is now endowed with automatic tracing.
幕后发生了什么？ 该代理对相当广泛的流行Java库和框架有所了解。 在类加载期间，代理通过字节码注入将跟踪工具添加到目标位置。 该应用程序现在具有自动跟踪功能。
(Note: I was hoping that the same thing would work for metrics, but not yet. The opentelemetry-java-instrumentation team is waiting for the OTel spec to stabilize with regards to metrics semantics before they pursue that.)
(注意：我希望同样的事情适用于度量标准，但目前还没有。opentelemetry-java-instrumentation团队在寻求OTel规范关于度量标准语义的规范之前正在等待稳定 。)
让我们看看结果 (Let’s see the result)
The Docker Compose includes a Jaeger container, which you can access at http://localhost:16686. I’d recommend doing that, but to save you the trouble, here are some screenshots too.
Docker Compose包含一个Jaeger容器，您可以从http：// localhost：16686访问该容器。 我建议您这样做，但为避免麻烦，这里也有一些屏幕截图。
First, here’s a trace for an earlier version of the app. (I’ll explain why we’re looking at an earlier version in a minute.)
首先，这是该应用程序早期版本的跟踪。 (我将解释为什么我们在一分钟之内就会看到较早的版本。)
You can see that auto-instrumentation knew to instrument Spring Web MVC, the Spring RestTemplate calls (backed by Apache HttpClient if memory serves) to the REST APIs, and the Spring Data repositories. I didn’t have to provide any of that myself.
您可以看到自动仪器可以用来检测Spring Web MVC，Spring RestTemplate调用(如果有内存，则由Apache HttpClient支持)和REST API，以及Spring Data存储库。 我不必自己提供任何内容。
Because the startup scripts for each microservice specified the service name, Jaeger is able to distinguish them and render the associated spans in different colors.
由于每个微服务的启动脚本都指定了服务名称，因此Jaeger能够区分它们并以不同的颜色呈现关联的跨度。
We can drill down on any of the spans. Here’s an HTTP request:
我们可以深入研究任何范围。 这是一个HTTP请求：
Though you couldn’t easily see it in the screenshots above, it turns out that opentelemetry-java-instrumentation knows about Hibernate too (yay), so we can even see SQL queries:
尽管您在上面的屏幕截图中看不到它，但事实证明opentelemetry-java-instrumentation也了解Hibernate，所以我们甚至可以看到SQL查询：
A feature that I love about tracing systems (not just Jaeger, but Zipkin and Expedia’s Haystack too) is that they automatically build service dependency graphs based on span data. This makes it easier for human operators to diagnose incidents, and also opens the door for some extremely interesting algorithmic and graph-based machine learning possibilities. Anyway, here’s Jaeger’s automatically-generated graph visualization:
我喜欢跟踪系统(不仅包括Jaeger，而且还有Zipkin和Expedia的Haystack )都具有跟踪功能，它们会根据跨度数据自动构建服务依赖关系图。 这使操作员更容易诊断事件，也为一些极其有趣的算法和基于图的机器学习可能性打开了大门。 无论如何，这是Jaeger自动生成的图形可视化：
This is of course a tiny system, but automatic architecture extraction becomes at least potentially more useful as the number of collaborating services grows. (No doubt there’s room for improving the visualizations themselves: see for example the articles by Cindy Sridharan and William Louth. Over time I’d expect to see both improved UX and algorithmic/ML-based processing.)
这当然是一个很小的系统，但是随着协作服务数量的增加，自动体系结构提取至少可能变得更加有用。 (毫无疑问，还有改进自身可视化的空间：例如，参见Cindy Sridharan和William Louth的文章。随着时间的流逝，我希望看到改进的UX和基于算法/基于ML的处理。)
Before I close out this section, take another look at the first trace screenshot I posted above. You’ll see that the API calls providers 1 and 2 in series, which extends the call duration. After seeing the trace, I changed the behavior to a fork/join behavior. You can see the impact on the trace (parallel calls) and the duration (37ms vs 54ms previously) here:
在结束本节之前，请再次看一下我上面发布的第一个跟踪屏幕截图。 您将看到API依次调用提供程序1和2，从而延长了调用时间。 看到跟踪之后，我将行为更改为fork / join行为。 您可以在此处查看对跟踪(并行调用)和持续时间(之前为37ms与54ms)的影响：
结论 (Conclusion)
In this post we looked at using the OpenTelemetry for Java Instrumentation agent to automate one aspect of an observability effort, which in this case is tracing instrumentation. As the OTel spec matures we can expect to see similar OTel auto-instrumentation emerge for metrics as well. While none of this completely replaces manual instrumentation, it does serve to reduce effort, to reduce code cruft, and to harmonize observability data so we can enable more systematic approaches to processing observability data (e.g., metrics aggregation based on conventional dimensions).
在本文中，我们研究了使用Java工具仪表的OpenTelemetry代理自动化可观察性方面的一个方面，在这种情况下，它是跟踪仪表。 随着OTel规范的成熟，我们可以预期还会看到类似的OTel自动仪器出现在指标上。 尽管这些方法都不能完全替代手动工具，但确实可以减少工作量，减少代码混乱并统一可观察性数据，因此我们可以启用更系统的方法来处理可观察性数据(例如，基于常规维度的指标聚合)。
翻译自: https://medium.com/wwblog/auto-instrumentation-with-opentelemetry-3b096fdd068f
1971
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
