使用分布式跟踪功能观察微服务延迟时间

Last reviewed 2023-08-11 UTC

当应用重写为使用微服务时,单个用户事务中涉及的组件和端点数量会增加。 因此,可观测性对于可靠地运行用户服务至关重要。 此参考架构展示了如何使用 OpenTelemetry 和 Cloud Trace 在微服务应用上捕获跟踪记录信息。

本文档面向想要了解分布式跟踪基础知识并希望将这些原则应用于其服务以提高服务可观测性的开发者、SRE 和 DevOps 工程师。

架构

下图展示了实现此架构的应用的架构。

具有两个 GKE 集群的示例部署的架构。

如上图所示,此架构包含两个 GKE 集群。您将为每个集群部署应用。用户流量将发送到前端集群上的前端应用。前端集群上的前端 pod 会与后端集群上的后端 pod 通信。后端 pod 调用外部 API 端点。

可观测性数据将导出到 Cloud Trace,用于跟踪请求如何传播到应用中。

设计考虑事项

对于在 Kubernetes 上运行的服务,您可以使用 Istio 等服务网格启用从服务到服务的流量的分布式跟踪,而无需专用插桩。但是,您可能具有以下任何要求:

  • 您希望对 Istio 提供的跟踪记录具有更多控制权。
  • 您可能需要在跟踪记录信息中捕获应用内部资料。
  • 您可能需要跟踪不在 Kubernetes 上运行的代码。

对于这些使用场景,您可以使用 OpenTelemetry,这是一个开源库,可用于向分布式微服务应用添加插桩,以在各种语言、平台和环境之间收集跟踪记录、指标和日志。

了解跟踪记录、span 和上下文

如需了解分布式跟踪概念,请参阅 Google 发布的 Dapper 研究论文。如本文所述,下图显示了一个跟踪记录中的五个 span。

一个跟踪记录中包含五个 span 的分布式跟踪。

跟踪记录是描述分布式系统如何响应用户请求的信息汇总。跟踪记录由 span 组成,其中每个 span 表示为处理用户请求而涉及的特定请求和响应对。父级 span 描述最终用户观察到的延迟时间。每个子级 span 描述如何调用和响应分布式系统中的特定服务,并记录针对每个服务捕获的延迟信息。

该图显示了发出两个后端请求的单个前端请求。 第二个后端调用需要两个帮助程序调用才能完成。每个调用都标有其 span ID 和父级 span 的 ID。

在分布式系统中进行跟踪的挑战是,对各种后端服务发出后续请求时,原始前端请求的信息不会自动传递或者这些信息本身不会传递。

使用某些工具(例如,在 Go 语言中),您可以使用上下文(集群 IP 地址和凭据)发出请求。OpenTelemetry 扩展了上下文概念以包含 span 上下文,这意味着其他信息会加载到 HTTP 标头中。然后,可以在每个后续请求中包括父级 Span 的相关信息。您可以附加子级 span 以编写总体跟踪记录,以便查看用户请求如何遍历系统并最终被提供给用户。

Deployment

如需部署此架构,请参阅部署分布式跟踪以观察微服务延迟时间

后续步骤