分布式追踪（Distributed traces）的定义
分布式追踪是一种遥测数据，提供对每个用户请求在应用程序整个路径中的端到端代码级记录（事务/transaction）。
分布式追踪能让你了解应用的健康状况、依赖关系，以及系统组件之间的交互。它是云原生环境中可观测性和应用性能监控（application performance monitoring - APM）的重要组成部分。
追踪帮助站点可靠性工程师（SRE）、IT 运营（ITOps）和 DevOps 团队理解请求在系统中各个微服务间的端到端流动和行为。通过追踪，开发人员可以发现影响性能和用户体验的瓶颈及代码问题，并进行优化。
更多阅读：Observability：应用程序性能监控/管理(APM)实践
分布式追踪 vs 传统追踪
分布式追踪是观察请求在分布式环境中传递的方法。
分布式架构设计本身包含复杂的服务网络，请求会穿越多个执行特定任务的微服务。因此，在分布式系统中追踪请求非常复杂，传统用于单体应用的追踪方法无法胜任。
传统追踪提供的洞察有限，且不具备扩展性。传统追踪方法使用对每个请求的随机追踪样本，导致追踪不完整。
为什么追踪对应用开发很重要？
追踪对应用开发重要，因为它让软件工程师能够跟踪一个请求经过多个微服务的全过程。能够直观地追踪每一步，使追踪变得非常有价值。它帮助排查不同应用中的错误和性能问题。
追踪的作用包括：
更快定位问题：在分布式系统中，排错比单体系统复杂得多。分布式追踪帮助更快找到应用错误的根因和位置，减少中断时间。
简化调试：追踪提供请求如何与不同微服务交互的全面视图，辅助调试，即使在最复杂的架构中也有效。
促进协作：在分布式环境中，不同团队负责不同服务。追踪能定位问题发生的位置，指向负责修复的团队。
加快开发速度：通过追踪，开发者能获得用户行为的宝贵见解，优化应用性能，简化更新和新版本发布工作。
追踪如何工作
追踪通过收集、分析和可视化请求在微服务架构中跨不同服务传递的遥测数据来实现。
在生成追踪（和其他遥测）数据之前，应用必须进行代码埋点（instrumentation）。埋点是添加代码以跟踪追踪数据的过程。
像 OpenTelemetry（OTel）这样的开源平台，提供厂商中立的 SDK、API 和其他工具，用于对微服务架构进行埋点。
数据收集
端到端的分布式追踪工具从用户发起请求时开始收集数据。每个请求进入系统时都会添加一个标识信息 —— trace ID。这个标识信息会随着请求传递到各个服务和组件。
请求过程中的每一步也会被记录。最初的一步称为父跨度（parent span），后续的每一步称为子跨度（child span）。每个子跨度都编码有原始 trace ID、唯一的跨度 ID（span ID）、时间戳、状态及其他相关元数据。跨度按层级组织，跟踪请求在整个环境中各个服务的路径。
对于 APM（应用性能监控），对应用进行埋点并启用追踪收集，可以采集追踪应用的指标（数值），用于监控应用性能。这些指标包括：
请求速率（Request rate）——每秒请求数
错误率（Error rate）——失败请求数
延迟（Latency）——响应请求所需时间
持续时间（Duration）——请求处理的总耗时
吞吐量（Throughput）——应用在特定时间内能处理的请求量
追踪分析
请求完成且追踪收集所有数据后，数据会被汇总。利用跨度中的 trace ID、时间戳及其他上下文信息，开发人员可以定位资源瓶颈、延迟问题或错误。
监控与可视化
追踪应用指标有助于监控应用性能。指标变化时，SRE 和 DevOps 团队可以迅速响应。
借助人工智能（AI）或机器学习，监控过程可以部分自动化，工程师能在问题发生前获得预警。AI 助手还能深入分析追踪数据，通过关联其他观测数据快速排查根本原因。
最终，所有跨度会以瀑布图形式可视化，顶部是父跨度，下面是嵌套的子跨度。该图提供应用响应请求时的全景视图，帮助工程师理解分布式系统中哪些部分出现性能问题、错误或瓶颈。
OpenTelemetry 中的追踪开放标准
OpenTelemetry 是一个开源的可观测性框架，包含工具、API 和 SDK。OTel 使得 SRE、DevOps 和 IT 团队能够以统一格式对追踪等遥测数据进行埋点、收集和导出，方便分析。
云原生计算基金会（CNCF）开发了 OTel，提供标准化的协议、模式和工具，用于收集和路由遥测数据到可观测性平台。OTel 重点关注追踪，是 CNCF 之前两个项目 OpenTracing 和 OpenCensus 合并的产物，旨在为代码埋点和遥测数据路由到可观测后台设定统一标准。
自 2019 年两个项目合并以来，开源社区和企业都开始采用 OTel，因为它提供统一的埋点格式且具有未来兼容性。
在 OpenTelemetry 和其开放标准之前，可观测数据往往不一致且难以关联。在分布式环境中，DevOps 和 IT 需为组织中不同应用和服务的多种编程语言分别埋点，且常用的埋点、APM 或追踪工具多为专有，带来诸多问题。缺少统一标准和工具使得查找性能问题或错误变得困难。
而有了 OTel，工程师无需重新埋点不同服务代码，也不必频繁手动调整遥测数据路由。只需使用一个开源框架，支持所有兼容 OpenTelemetry 的可观测和监控工具。
随着 AI 异常检测和生成式 AI 等新技术出现，OpenTelemetry 将持续提供一个统一的端到端分布式追踪集成框架。
OTel 追踪标准包括：
一套统一的 API 和规范用于采集追踪数据
将跨度（span）定义为追踪的核心单位
命名跨度和添加属性的语义约定
用于跨服务关联跨度的上下文机制
支持多种编程语言
了解更多关于 Elastic 中的 OpenTelemetry
追踪、指标、日志与分析
遥测数据 —— 日志、指标和追踪 —— 提供了对分布式环境中应用程序、服务器、服务或数据库行为的完整可观测性。也称为可观测性的三大支柱，日志、指标和追踪共同创建了每个用户请求和事务的完整且关联的记录。
这三种数据类型各自提供环境的重要信息。它们共同帮助 DevOps、IT 和 SRE 团队实时和历史地跟踪整个系统的性能。
追踪
追踪是请求通过整个分布式系统路径的详细记录，用于提供上下文。通过整合孤立数据并记录用户的每个操作，追踪帮助工程师发现瓶颈，调试和监控使用多个应用的系统，同时理解系统组件之间的依赖关系和交互。
日志
日志文件是带时间戳的事件和系统消息记录。日志通常用于排错和调试。它们提供系统行为的洞察，有助于识别问题。
此外，大多数编程语言内置了日志功能，因此开发者倾向于继续使用他们已有的日志框架。
指标
指标是表示系统状态或性能的数值，通常覆盖一段时间。指标是关键性能指标。DevOps 及其他团队用它们来监控系统健康、识别趋势和触发警报。
分析：现代可观测性的未来第四支柱
指标、日志和追踪提供了“发生了什么”和“在哪里发生”的有价值见解。同样重要的是理解系统为何表现如此：为何存在性能瓶颈或浪费的计算？这时，持续分析（profiling）发挥作用。它帮助实现对系统的全面视图，提供更深层次的可视性 —— 直到代码级别。
更多阅读：Elastic Universal Profiling™ 是一种连续分析解决方案，现已正式上市
如何实现分布式追踪
分布式追踪对于监控和排查复杂系统及分布式应用非常重要。实施分布式追踪前，需要明确追踪目标和需求，并识别关键服务和请求路径。以下是成功实施分布式追踪的五个步骤：
选择追踪工具，例如 OpenTelemetry（目前收集追踪、指标和日志的标准框架）。该工具应兼容你现有的技术栈，并具备未来适应性。
对服务和应用进行代码埋点，即在代码中添加追踪代码，并在应用中定义追踪（span）。
收集追踪数据，通过发起请求采集数据。确保通过上下文传播保证追踪数据的准确和完整，这是分布式追踪的关键部分。
导出追踪数据，用于监控、分析和可视化，发送到你选择的后端或云追踪服务提供商。
识别性能瓶颈、低效和错误。追踪数据有助于发现错误、找出性能较慢的服务，并可视化跨服务的数据流。
下载电子书，了解如何使用应用性能监控（APM）实现分布式追踪。
Elastic 的 APM 与分布式追踪
应用性能监控（Application performance monitoring - APM）在现代可观测性中发挥关键作用，通过上下文关联和机器学习，帮助你分析所有遥测数据，提升根因分析效率。
利用 Elastic Observability 和搜索功能，通过端到端分布式追踪提升代码质量。捕获并分析跨微服务、无服务器和单体架构的分布式事务，支持 AWS Lambda、自动埋点及多种主流语言，如 Java、.NET、PHP、Python、Go 等。通过附加客户数据和部署标记，最大限度减少宕机时间，优化用户体验。