使用OpenTelemetry进行分布式跟踪：一个实用的指南

"注意"\n\n"大多数供应商都支持OpenTelemetry，因此您可以在不更改应用程序中的任何内容的情况下轻松更换分布式跟踪后端。例如，您可以将跟踪发送到其他平台，如Honeycomb、Lightstep或VMware Tanzu Observability，而不是Tempo。\n\n首先，让我们更新Polar Bookshop的Docker Compose文件，包括Tempo（polar-deployment/docker/docker-compose.yml）。Grafana已经配置为在您从第13章导入的配置文件中使用Tempo作为数据源。\n\n接下来，让我们在Docker上运行完整的Grafana可观测性堆栈。打开一个终端窗口，导航到保存Docker Compose文件的文件夹，并运行以下命令：\n\nbash\n\ndocker-compose up -d\n\n\n\n现在，Tempo已准备好在端口4317上接受OpenTelemetry跟踪。在下一节中，您将了解如何更新Spring Boot应用程序以生成跟踪并将其发送到Tempo。\n\nOpenTelemetry项目包括为最常见的Java库（包括Spring、Tomcat、Netty、Reactor、JDBC、Hibernate和Logback）生成跟踪和跨度的仪器。OpenTelemetry Java Agent是该项目提供的一个JAR文件，可以附加到任何Java应用程序。它动态注入必要的字节码，以从所有这些库中捕获跟踪和跨度，并以不同的格式导出它们，而无需更改Java源代码。\n\nJava代理通常在运行时从外部提供给应用程序。为了更好地管理依赖关系，这种情况下，我更喜欢使用Gradle（或Maven）将代理JAR文件包含在最终应用程序构件中。让我们看看如何操作。\n\n打开Catalog Service项目（catalog-service）。然后在build.gradle文件中添加对OpenTelemetry Java Agent的依赖项。记得在添加新依赖后刷新或重新导入Gradle依赖项。\n\n除了对Java代码进行仪器化以捕获跟踪外，OpenTelemetry Java Agent还与SLF4J（及其实现）集成。它提供了作为上下文信息的跟踪和跨度标识符，可以通过SLF4J提供的MDC抽象将其注入日志消息中。这使得从日志消息导航到跟踪（反之亦然）比孤立地查询遥测数据更加简单，从而实现对应用程序的更好可见性。\n\n让我们扩展Spring Boot使用的默认日志格式，并添加以下上下文信息：\n\n* 应用程序名称（我们为所有应用程序配置的spring.application.name属性的值）\n* 跟踪标识符（当启用时，由OpenTelemetry代理填充的trace_id字段的值）\n* 跨度标识符（当启用时，由OpenTelemetry代理填充的span_id字段的值）\n\n在Catalog Service项目中，打开application.yml文件，并将三个新信息添加到日志级别旁边（由%5p表示），遵循Logback语法。这是Spring Cloud Sleuth使用的相同格式。\n\n接下来，打开一个终端窗口，导航到Catalog Service根文件夹，并运行./gradlew bootBuildImage将应用程序打包为容器镜像。\n\n最后一步是配置和启用OpenTelemetry Java Agent。为了简单起见，我们将仅在容器中运行应用程序时启用OpenTelemetry，并依靠环境变量来配置它。\n\n我们需要三个配置项才能成功启用跟踪：\n\n* 指示JVM加载OpenTelemetry Java代理。我们可以通过JAVA_TOOL_OPTIONS标准环境变量来实现，该变量由OpenJDK支持，用于为JVM提供附加配置。\n* 使用应用程序名称标记和分类跟踪。我们将使用OpenTelemetry Java代理支持的OTEL_SERVICE_NAME环境变量。\n* 定义分布式跟踪后端的URL。在我们的案例中，它是端口4317上的Tempo，并且可以通过OpenTelemetry Java代理支持的OTEL_EXPORTER_OTLP_ENDPOINT环境变量进行配置。默认情况下，跟踪数据通过gRPC发送。\n\n转到Polar Deployment项目（polar-deployment），打开Docker Compose文件（docker/docker-compose.yml）。然后向Catalog Service添加必要的配置以支持跟踪。\n\n最后，从相同的文件夹中将Catalog Service作为容器运行：\n\nbash\n\ndocker-compose up -d catalog-service\n\n\n\n应用程序启动后，发送一些请求以触发有关HTTP请求的一些日志和跟踪生成：\n\nbash\n\ncurl localhost:8080/books\n\n\n\n然后检查容器的日志（docker logs catalog-service）。您会看到每条日志消息现在都有一个新的部分，其中包含应用程序名称以及（如果可用）跟踪和跨度标识符：\n\n分布式跟踪帮助我们跟踪请求通过多个服务的过程，因此我们需要另一个应用程序来测试它是否正常工作。继续对Edge Service进行相同的更改以支持OpenTelemetry。然后从Docker Compose文件中将应用程序作为容器运行：\n\nbash\n\ndocker-compose up -d edge-service\n\n\n\n再次发送一些请求以触发有关HTTP请求的一些日志和跟踪生成。这次您应该通过网关进行：\n\nbash\n\ncurl localhost:8080/books\n\n\n\n使用Catalog Service记录的跟踪ID，我们可以检索（关联）处理在Edge Service中启动的/ books端点的HTTP请求涉及的所有步骤。能够从日志导航到跟踪（反之亦然）对于更好地了解在分布式系统中处理请求的所有步骤非常有用。让我们看看它在Grafana堆栈中是如何工作的。\n\n打开浏览器窗口，转到Grafana（http://localhost:3000），并使用在Docker Compose中配置的凭据登录（user/password）。在“Explore”页面上，检查Catalog Service的日志（{container_name="/catalog-service"}），就像我们之前做的那样。接下来，单击最新的日志消息以获取更多详细信息。您将看到与该日志消息关联的跟踪标识符旁边有一个Tempo按钮。如果单击该按钮，Grafana将使用来自Tempo的数据将您重定向到相关的跟踪，所有这些都在同一个视图中（图13.9）。\n\n在检查日志和跟踪完成后，停止所有容器（docker-compose down）。在继续之前，继续配置Polar Bookshop系统中所有其余应用程序的OpenTelemetry。作为参考，您可以查看本书附带的源代码存储库（Chapter13/13-end）。\n\n到目前为止，我们已经处理了三种主要类型的遥测数据：日志、指标和跟踪。我们还启用了健康端点，以提供有关应用程序状态的附加信息。接下来的部分将介绍如何从应用程序中检索更多信息，并对其操作进行更好的可见性。