什么是追踪？
分布式追踪定义
分布式追踪是一种遥测数据，可提供应用程序整个路径中每个用户请求的端到端、代码级别记录（事务）。
分布式追踪可提供应用程序运行状况、依赖关系和系统组件间交互的可见性。它是云原生环境中可观测和应用程序性能监测 (APM)的重要组成部分。
追踪可帮助网站可靠性工程师 (SRE)、ITOps 和 DevOps 团队了解请求通过系统内各种微服务的端到端移动和行为。开发人员可利用追踪功能定位影响性能和用户体验的代码瓶颈及问题，并进行优化以提升效率。
分布式追踪与传统追踪
分布式追踪是一种观察请求在分布式环境中传播的方法。
根据设计，分布式架构涉及复杂的服务网络。一个请求会跨越许多微服务，每个微服务都会执行特定的任务。因此，在分布式系统中追踪请求是一项复杂的任务，传统的单体应用追踪技术根本无法实现。
传统追踪提供的见解有限，并且不可扩展。传统追踪方法使用每个请求的随机追踪样本，导致追踪不完整。
为什么追踪对应用程序开发很重要？
跟踪对于应用程序开发非常重要，因为它能让软件工程师通过众多微服务跟踪一个请求。直观地跟踪每个步骤的能力使跟踪变得非常有价值。它通过排查不同应用程序的错误来帮助解决故障和性能问题。
追踪有助于：
- 更快发现问题：在分布式系统中，故障排除的难度远高于单体系统。分布式追踪有助于更快地确定应用程序错误的根本原因和位置，从而最大限度地减少中断。
- 简化调试过程：分布式追踪可完整呈现请求在微服务间的调用链路，即便面对最复杂的系统架构，也能提升调试效率。
- 改善协作：在分布式环境中，不同的团队往往负责不同的服务。跟踪可确定问题发生的位置，并指向负责解决问题的团队。
- 加快开发速度：借助追踪技术，开发人员可以获得对用户行为的宝贵见解，优化应用程序性能，简化发布更新和新功能部署。
追踪的工作原理
追踪的工作原理是收集、分析和可视化请求在微服务架构中不同服务间传输时的遥测数据。
在生成追踪（和其他遥测）数据之前，必须对应用程序进行插桩。插桩是添加代码来追踪数据的过程。OpenTelemetry（OTel）等开源平台提供了供应商中立的 SDK、API 和其他工具，用于微服务架构插桩。
数据收集
端到端分布式追踪工具在用户发起请求时就开始收集数据。在每个请求进入系统时，都会添加标识信息，即追踪 ID。这些标识信息会随请求在各类服务与组件间流转而持续传递。
请求过程中的每个步骤也会被记录下来。第一个跨度称为父跨度，而每个后续跨度称为子跨度。每个子跨度都用原始追踪 ID、唯一跨度 ID、时间戳、状态和其他相关元数据进行编码。跨度按层级组织，追踪整个环境中的服务历程。
对于 APM，对应用程序进行插桩并启用追踪收集功能，就可以收集追踪应用程序指标或数值，用于监测应用程序的性能。这些指标包括：
- 请求率 - 每秒请求次数
- 错误率 - 失败的请求次数
- 延迟——响应请求所需的时间
- 持续时间 - 请求所花费的时间
- 吞吐量 — 应用程序在给定时间段内可以处理的请求量
追踪分析
当请求完成且追踪数据采集完毕后，系统会对数据进行汇总。开发人员可以利用来自跨度的数据（如追踪标识符、时间戳和其他上下文信息）来定位资源瓶颈、延迟问题或错误。
监测和可视化
追踪应用程序指标有助于监测应用程序的性能。当发生变化时，SRE 和 DevOps 团队可以立即采取行动。
借助人工智能 (AI) 或机器学习，监测过程可以实现部分自动化，工程师可在潜在问题发生前收到警报。AI 助手还可以通过关联其他来源的可观测数据，深入分析追踪数据并快速定位潜在问题。
最后，所有跨度都会以瀑布图形式可视化呈现，父跨度位于顶部，子跨度按层级嵌套排列在下。该瀑布图可鸟瞰应用程序在尝试响应请求时的工作情况。这样，工程师就能了解分布式系统的哪些部分出现了性能问题、错误或瓶颈。
OpenTelemetry 中的追踪开放标准
OpenTelemetry 是一个开源的可观测性框架，由工具、API 和 SDK 组成。OTel 使 SRE、DevOps 和 IT 团队能够以统一的单一格式检测、收集和导出遥测数据（包括追踪），以进行分析。
云原生计算基金会 (CNCF) 开发了 OTel，为收集遥测数据并将其路由到可观测性平台提供标准化协议、模式和工具。OTel 专注于追踪，是 CNCF 之前两个项目 OpenTracing 和 OpenCensus 合并的结果。它们旨在为代码插桩和将遥测数据路由到可观测性后端设定单一标准。
这两个项目自 2019 年合并以来，因其统一化的插桩规范与前瞻性架构设计，获得了开源社区和企业广泛采用。
在 OpenTelemetry 及其开放标准问世之前，可观测数据通常不一致且难以关联。在分布式环境中，DevOps 和 IT 部门必须在几种编程语言中使用不同的库，以支持组织的各种应用程序和服务。通常，每种代码检测、APM 或跟踪工具都是专有的，这给分布式追踪带来了无数问题。如果没有标准和单一的工具来收集（和导出）所有应用程序的跟踪信息，工程师查找性能问题或错误的工作就会变得非常困难。
另一方面，有了 OTel，工程师就不需要重新编写代码来追踪来自不同服务的追踪数据，也不需要在每次更改时手动重新路由遥测数据。目前只有一个开放源代码框架，用于提供符合 OpenTelemetry 标准的可观测性和监测工具。
随着新技术（例如 AI 深度集成，包括异常检测和生成式 AI）的涌现，OpenTelemetry 将继续为端到端分布式追踪提供单一且受支持的集成框架。
OTel 的追踪标准包括：
- 一组用于收集追踪数据的单一 API 和约定
- 跨度被定义为追踪的核心单元
- 命名跨度和添加属性的语义约定
- 用于跨不同服务链接跨度的上下文机制
- 支持不同的编程语言
追踪、指标、日志和分析
遥测数据（日志、指标和追踪）提供了对分布式环境中应用程序、服务器、服务或数据库行为的全面可观测性。日志、指标和追踪也被称为可观测性的三大支柱，它们为每个用户请求和事务创建了完整的关联记录。
这三种数据类型均提供有关环境的基本信息。这此数据共同帮助 DevOps、IT 和 SRE 团队实时监测系统性能，并进行历史数据分析。
跟踪
追踪详细记录了请求通过整个分布式系统的路径，可提供上下文信息。通过将孤立的数据整合在一起并记录用户的每个操作，追踪功能有助于工程师发现瓶颈，调试和监测使用多个应用程序的应用程序，以及了解系统组件之间的依赖关系和交互。
日志
日志文件是事件和系统消息的时间戳记录。日志通常用于故障排除和调试。它们提供了对系统行为的见解，有助于发现问题。
此外，大多数编程语言都有内置日志功能。因此开发人员倾向于继续使用现有的日志框架。
指标
指标是数值，代表一段时间内系统的状态或性能。指标是关键绩效指标。DevOps 和其他团队通过指标监测系统的运行状况、识别趋势和触发警报。
分析：现代可观测性体系的第四大支柱
指标、日志和追踪提供了有价值的见解，帮助我们了解所发生的问题。同样重要的是理解系统行为背后的根因：为何会出现性能瓶颈或计算浪费？这就是持续分析可以发挥作用的地方。它不仅能提供系统的全景视图，更能实现代码级的深度可观测性。
如何实现分布式追踪
分布式追踪对于监测复杂系统和分布式应用程序并排除故障至关重要。在实施分布式追踪之前，必须确定追踪目标和需求，并确定关键服务和请求路径。以下是成功实施分布式追踪的五个步骤：
- 选择一种追踪工具，如 OpenTelemetry（现在是收集追踪、指标和日志的标准框架）。该工具需兼容现有技术栈，并具备未来适应性。
- 服务插桩和应用程序。 这涉及将追踪代码添加到代码库并在应用程序中定义追踪（跨度）。
- 通过发起请求来采集追踪数据。通过分布式追踪的核心机制上下文传播，确保追踪的准确性与完整性
- 向您选择的后端或云追踪服务提供商导出追踪信息，以便进行监测、分析和可视化。
- 识别性能瓶颈、低效和错误。跟踪数据可帮助检测错误、查找性能缓慢的服务并可视化跨服务的数据流。
下载电子书，了解如何使用应用程序性能监测 (APM) 实现分布式追踪
使用 Elastic 的 APM 和分布式跟踪
应用程序性能监测 (APM) 在现代可观测性体系中发挥着关键作用，它通过提供上下文和利用机器学习改进根本原因分析，指导您处理所有遥测数据。
利用 Elastic Observability 和强大的搜索功能，通过端到端分布式追踪提高代码质量。跨微服务以及无服务器和单体架构捕获和分析分布式事务，包括支持 AWS Lambda、自动检测，以及 Java、.NET、PHP、Python、Go 等常用语言。使用客户数据和部署标记对事务进行注释，最大程度地减少中断并优化客户体验。