本文转载自微信公众号「黑客下午茶」，作者很少。转载本文，请联系黑客下午茶微信官方账号。
目录
- 什么是跟踪？
- 为什么要跟踪？
- 跟踪(Traces)、事务(Transactions和跨度(Spans)
- 例子：调查缓慢的页面加载
- 更多示例
- 跟踪数据模型
- 更多信息
- 。数据采样
- 跟踪中的一致性
分布式跟踪(Distributed tracing)通过捕获软件系统之间的交互，提供连接错误和事务的视图。Sentry 可以跟踪您的软件性能，并显示跨系统的错误影响。将您的前端连接到您的后端。
- https://docs.sentry.io/product/sentry-basics/tracing/distributed-tracing/
使用性能监控来扩展您现有的错误数据，跟踪从前端到后端的交互。Sentry 可以跟踪您的软件性能，测量吞吐量和延迟，并显示跨系统的错误影响。跟踪使 Sentry 成为更完整的监控解决方案，帮助您更快地诊断问题，衡量应用程序的整体健康状况。Sentry 跟踪提供以下见解：
- 或 具体错误事件issue 发生了什么
- 导致应用程序瓶颈或延迟 issue 的条件
- 最耗时的端点或操作时间最多
什么是跟踪？
首先，请注意跟踪不是什么：跟踪不是分析。虽然分析和跟踪的目标有很多重叠，但它们可以用来诊断应用程序中的问题，但它们在测量内容和数据记录方法上是不同的。
profiler 可以测量应用程序操作的许多方面：执行指令数、各过程中使用的内存、给定函数调用所花费的时间等。profile 是这些测量值的统计总结。
- https://en.wikipedia.org/wiki/Profiling_(computer_programming)
另一方面，tracing tool 关注发生了什么(及时)，而不是发生了多少次或花了多长时间。跟踪结果(resulting trace)它是程序执行过程中发生的事件日志，通常跨越多个系统。尽管最常见的跟踪 - 或，就 Sentry就 跟踪而言，总是 - 包括时间戳(timestamps)，允许计算持续时间，但测量性能并不是唯一的目的。它们还可以显示互连系统的交互方式，以及一个系统中的问题可能导致另一个系统问题的方式。
- https://en.wikipedia.org/wiki/Tracing_(software)
为什么要跟踪？
应用程序通常由互连组件组成，也称为服务。例如，让我们看看现代 Web 由网络边界分隔的以下组件组成的应用程序：
- Frontend (Single-Page Application) 前端
- Backend (REST API) 后端
- Task Queue 任务队列
- Database Server 数据库服务器
- Cron Job Scheduler 定时任务调度器
这些组件中的每一个都可以在不同的平台上用不同的语言编写。每一个都可以用 Sentry SDK 单独检测以捕获错误数据或崩溃报告，但不能提供完整的图片，因为每个部分都是单独考虑的。跟踪允许您连接所有数据。
在我们的例子 Web 在应用程序中，跟踪意味着可以跟踪从前端到后端和后端的任何后台任务(background tasks)或通知作业(notification jobs)提取数据。这不仅能让你关联 Sentry 错误报告，查看一个服务中的错误如何传播到另一个服务，也可以让您更深入地了解哪些服务可能对应用程序的整体性能产生负面影响。
了解一些关键术语及其关系将有助于学习如何在你的应用程序中使用跟踪。
跟踪(Traces)、事务(Transactions和跨度(Spans)
trace 表示要测量或跟踪整个操作的记录 - 如页面加载、用户在应用程序中完成某些操作的例子或后端 cron job。当跟踪包括多个服务中的工作时，如上述服务，由于跟踪分布在这些服务中，因此被称为分布式跟踪。
每个 trace 由一个或多个称为 transactions 树状结构，其节点称为 spans。在大多数情况下，每个 transaction 代表单个调用服务的例子， transaction 中的每个 span 代表服务执行单个工作单元，无论是调用服务中的函数还是不同的服务。这是一个分解为事务的示例跟踪(transactions)和跨度(spans)：
由于事务(transaction)有树结构，所以顶级跨度(top-level spans)它本身可以分解为更小的跨度(smaller spans)，这反映了一个函数可能会调用许多其他较小的函数；这是用父子隐喻来表达的，所以每个跨度可能是多个其他子跨度的父跨度。此外，由于所有的树都必须有一个根，每个事务中的一个跨度总是代表事务本身，事务中的所有其他跨度都从根跨度下降。这是上图中事务之一的放大视图：
让我们再次考虑我们的，让我们再次考虑我们的 Web 应用程序。
例子：调查缓慢的页面加载
假设您的 Web 应用程序加载缓慢，你想知道为什么。为了使您的应用程序首先进入可用状态，必须发生很多事情：对后端的多个要求可能是一些工作 - 包括对数据库或外部 API 的调用 - 在返回响应之前完成，并由浏览器处理，以呈现所有 将返回数据转换为对用户有意义的内容。那么这个过程的哪一部分会减慢呢？
假设在这个简化的例子中，当用户在浏览器中加载应用程序时，每个服务都会发生以下情况：
- Browser
- HTML、CSS 和 JavaScript 各 1 请求
- 1 次渲染任务触发 2 次 JSON 数据请求 ^
- Backend(后端)
- 3 提供静态文件(HTML、CSS 和 JS)的请求
- 2 个 JSON 数据请求 - 1 需要调用数据库- 1 需要外部调用API在将结果返回回到前端之前，处理结果^
- Database Server
- 1 查询身份验证
- 1 查询获取数据
- 1 要求要求 2次
注：外界 API 没有准确列出，因为它是外部的，所以你看不到它的内部。
在这个例子中，整个页面加载过程(包括上述所有过程)由单个 加载trace 表示。跟踪将由以下事务进行。(transactions)组成：
- 1 浏览器事务(页面加载)
- 5 后端事务(每个请求一个)
- 1 单个数据库服务器服务于单个 DB 请求)
每个事务将被分解为跨度(spans)如下：
- 浏览器页面加载事务 span
- 2 个子 span，每个 JSON 请求一个
- 1 个根 span 代表整个页面加载
- HTML、CSS 和 JS 请各 1 个(共 3 个)
- 1 span，它本身包含
让我们暂停这里来解释一个关键点：这里列出的浏览器事务中的一些（尽管不是全部）跨度与上述后端事务直接对应。具体来说，浏览器事务中的每个请求跨度对应于后端中的单独请求事务。在这种情况下，当服务中的跨度导致后续服务中的事务时，我们称原始跨度为事务及其根跨度的父跨度。在下图中，波浪线代表了这种父子关系。
在我们的例子中，除了初始浏览器页面加载事务外，每个事务都是另一个服务中的跨度子项，这意味着每个根跨度都有一个父跨度（尽管在不同的服务中）。
在 fully-instrumented 该模式将始终适用于系统（每个服务都使用跟踪系统）。唯一的无父 span 将是初始 transaction 根；每隔一个 span 会有父级。parents 和 children 除非在子 ，否则将永远生活在同一个服务中span 是子 transaction 的根，在这种情况下，父 span子 将在调用服务中transaction/child 根 span 被调用服务。
换句话说， fully-instrumented 的系统创建了一个跟踪，它本身就是一个连接的树——每一件事都是一棵子树——在这棵树中，子树/事务之间的边界是服务之间的边界。上图显示了我们的例子对树的完整跟踪一个分支。
现在，为了完全起见，回到我们的 spans：
- 后端 HTML/CSS/JS 请求事务：每个 1 个 span
- 1 个根跨度(浏览器跨度的子项)代表整个请求^
- 有数据库调用事务的后端请求:2 个 span
- 1 表示整个请求的根跨度(浏览器跨度的子项)
- 1 用于查询数据库(数据库服务器事务的父级)的跨度^
- 带有 API 调用事务后端请求:3 span
- 1 表示整个请求的根跨度(浏览器跨度的子项)
- API 1 跨度(不同于数据库调用，不是父跨度，因为 API 是外)
- 1 处理 的跨度API 数据^
- 3 span
- 1 代表整个请求的根跨度(上后端跨度的子项)
- 1 跨度用于身份验证查询
- 1 用于查询检索数据的跨度
总结一下这个例子:检测完所有服务后，你可能会发现——出于某种原因——是数据库服务器中的身份验证查询(auth query)导致速度减慢，占整个页面加载过程的一半以上。跟踪不能告诉你为什么会发生这种情况，但至少现在你知道去哪里了！
更多示例
本节包含更多的跟踪示例，分为事务(transaction)和跨度(span)。
衡量特定的用户动作
如果您的应用涉及电子商务，您可能希望从用户单击测量“提交订单(Submit Order)”到订单确认出现之间的时间，包括跟踪向支付处理器提交费用和发送订单确认电子邮件。整个过程是一个跟踪，通常您会有事务 (T) 和跨度 (S) 用于：
- 全程浏览器(T 和根跨度 S)
- 对后端的 XHR 请求* (S)
- 渲染确认 screen(S)^
- 您的后端处理请求(T 和根跨度 S)
- 计算总数函数(Function)调用 (S)
- 存储订单数据库(DB)调用* (S)
- 支付处理器API 调用 (S)
- 确认电子邮件排队* (S) ^
- 您的数据库更新了客户订单历史(T 和根跨度 S)
- 单个 SQL 查询 (S) ^
- 发送电子邮件的排队任务(T 和根跨度 S)
- 函数调用 用于填充电子邮件模板(S)
- 为电子邮件发送服务API 调用 (S)
注:带星号的跨度表示父跨度作为后续事务(及其根跨度)。
监控后台过程
如果您的后端定期查询外部服务的数据，处理它，缓存它，然后转发给内部服务，发生这种情况的每个例子都是一个跟踪，您通常有以下事务 (T) 和跨度 (S)：
- 完成整个过程cron job(T 和根跨度 S)
- API 调用外部服务 (S)
- Processing 函数 (S)
- 调用缓存服务* (S)
- API 调用内部服务* (S) ^
- 在您的缓存服务中完成的工作(T 和根跨度 S)
- 检查现有数据的缓存 (S)
- 在缓存中存储新数据 (S) ^
- 您的内部服务处理请求(T 和根跨度 S)
- 服务可能为处理请求而做的任何事情 (S)
注:带星号的跨度表示父跨度作为后续事务(及其根跨度)。
跟踪数据模型
“我仍然莫名其妙地向我展示你的流程图并隐藏你的手表。如果你给我看你的手表，我不再需要你的流程图，因为它们太明显了。”
Fred Brooks,《The Mythical Man-Month》(人月神话)
虽然这个理论很有趣，但最终任何数据结构都是由它包含的数据类型定义的，数据结构之间的关系是由如何记录它们之间的链接定义的。跟踪、事务和跨度也不例外。
Traces(跟踪)
Traces 本身不是实体。相反，跟踪被定义为共享 trace_id 收集所有事务。
Transactions(事务)
Transactions 与其根跨度共享其大部分属性（开始和结束时间、标签等），因此以下跨度的相同选项可用于事务，并在任何位置设置。
Transactions 还有一个不包含在跨度中的附加属性，称为 transaction_name，它在 UI 用于标识 transaction。transaction_name 值的常见示例包括端点路径(如 /store/checkout/ 或 api/v2/users//)、cron job 事务任务名(如 data.cleanup.delete_inactive_users)和 URL( 像 https://docs.sentry.io/performance-monitoring/distributed-tracing/) 用于页面加载事务。
Spans(跨度)
transaction 事务中的大部分数据都停留在单个 span 中。span 数据包括：
- parent_span_id: 将 span 与其父 span 联系起来
- op: 测量标识跨度的操作类型或类别的短字符串
- start_timestamp: span 打开时
- end_timestamp: span 关闭时
- description: span 操作描述较长，唯一标识 span，但跨 span 实例一致(可选)
- status: 指示操作状态的短 code(可选)
- tags: key-value 附加数据(可选)保存相关跨度
- data: 关于 span 任何结构的附加数据(可选)
op 和 description 属性一起使用的示例是 op: sql.query 和 description: SELECT * FROM users WHERE last_active < %s。status 属性通常用于指示 span 操作成功或失败，或 HTTP 请求的情况下用于 response code。最后，tags 和 data 允许您向 添加更多的上下文信息span，例如 function: middleware.auth.is_authenticated 用于函数调用或 request: {url: ...,headers: ... , body: ...} 用于 HTTP 请求。
更多信息
更重要的是跟踪、事务和跨度以及它们相互关联的方式：
Trace Duration(跟踪持续时间)
因为 trace 只是 transaction因此 trace 没有自己的开始和结束时间。trace 在它最早的 transaction 从最新的 开始transaction 结束时结束。因此，你不能直接开始或结束 trace。相反，你在这里通过trace 创建第一个 transaction 来创建 trace，完成它包含的所有 transaction 来完成 trace。
Async Transactions(异步事务)
由于异步过程的可能性，子事务(child transaction)可能比包括父亲的跨度好(parent span)许多数量级的事务寿命都很长。例如，如果后端 API 调用启动长期运行的处理任务，然后立即返回响应，后端事务将在异步任务完成前很长一段时间完成（其数据将发送到 Sentry)。异步性也意味着 transaction 发送至(和接收)Sentry 的顺序与创建它们的顺序无关。(相比之下，同一 trace 中 transaction 的接收顺序与完成顺序有关，但由于传输时间的可变性等因素，相关性远非完美。
Orphan Transactions(孤儿事务)
理论上， fully instrumented 系统中，每个 trace 应该只包含一个 transaction 和一个 span(transaction没有父项，即原始服务中的 transaction。但在实践中，你可能不会在每项服务中使用 trace，由于网络中断或其他不可预见的情况，检测服务可能无法报告 transaction。当这种情况发生时，你可能会在跟踪层结构中看到间隙。具体来说，你可能在 span 中途看见父亲 span任何已知 transaction 的一部分 transaction。这种非发起，无父 transaction 被称为孤儿事务。
Nested Spans(嵌套跨度)
尽管我们上面的示例在其层次结构中有四个级别(跟踪trace、事务transaction、跨度span、子跨度child span)，但是，跨度嵌套的深度没有限制。但是，有实际限制：发送到 Sentry 事务有效负载最大允许大小，与任何类型相比类型的日志记录需要平衡数据的粒度和可用性。
Zero-duration Spans(零持续时间跨度)
跨度可能有相同的开始和结束时间，因此被记录为不占用时间。这可能是因为 span 被用作标记(例如在浏览器中 Performance API 完成)，或者因为操作时间少于测量分辨率(因服务而异)。
https://developer.mozilla.org/en-US/docs/Web/API/Performance/mark
Clock Skew(时钟偏移)
如果你从多台机器收集 transaction，你可能会遇到 clock skew，其中一个 transaction 时间戳和另一个 transaction 中的时间戳不一致。例如，如果您的后端调用数据库，则后端事务应在逻辑上从数据库事务开始。然而，如果每台机器上的系统时间（分别托管后端和数据库的机器）不符合一般标准，则可能不是这样。排序也可能是正确的，但两个记录的时间范围没有以准确反映实际情况的方式排列。为了减少这种可能性，我们建议使用在线时间协议 (NTP) 或您的云提供商时钟同步服务。
如何发送数据
单个 span 不会发送到 Sentry;相反，整个 transaction 作为单位发送。这意味着 Sentry 的服务器不会记录任何 span 数据，直到它们属于 transaction 被关闭和分配。然而，事实并非如此。——尽管没有 transaction 不能发送 span，但 transaction 仍然有效，即使它们只包含 span 是它们的根 span。
数据采样
当您在跟踪设置中使用采样时，您可以选择将其发送到 Sentry 已收集交易的百分比。例如，如果您每分钟有一个端点接收 1000 请求，0.25 取样率将导致每分钟大约250个事务 (25%) Sentry。(这个数字是相似的，因为每个请求要么被跟踪，要么被独立和伪随机跟踪，概率为 25%。因此，同样，100枚公平硬币在翻转时会导致大约50枚 正面硬币，SDK 将“决定” 收集和跟踪约250 个案例。)因为你知道采样百分比，你可以推断你的总流量。
在收集跟踪时，我们建议采样您的数据有两个原因。首先，虽然单个跟踪的成本最小，但每个页面都被加载或 捕获API 请求的跟踪可能会增加您的系统不想要的负载。其次，采样可以更好地管理和发送到 Sentry 事件数量，以便您可以根据组织的需要定制。
在选择采样率时，目标不是收集太多的数据（出于上述原因），而是收集足够的数据来得出有意义的结论。如果您不确定要选择什么速度，我们建议您平衡性能与流量与数据准确性之间的关系，直到您对流量模式和流量的理解逐渐增加。
跟踪中的一致性
跟踪涉及多个事务，Sentry 使用 “基于头部(head-based)” 方法：在原始服务中做出采样决策，然后将决策传递给所有后续服务。了解如何工作，让我们回到上面的 webapp示例。考虑两个用户 A 和 B，他们都在自己的浏览器中加载应用程序。A 加载应用程序时，SDK 伪随机“决定”收集跟踪，而当 B 加载应用程序时，SDK “决定”不收集跟踪。当每个浏览器向您的后端发出请求时，它将包含这些请求的标题“yes,please collect transactions)”或“no, don't collect transactions this time”的决定。
当您的后端处理来自 A 浏览器请求时，会看到 “yes” 决定收集事务和跨度数据，并将其发送给 Sentry。此外，它还包含在向后续服务(如您的数据库服务器)发出的任何请求中“yes”这些服务还将收集数据并将数据发送给 Sentry，任何决定传递给他们的服务。通过这个过程，A收集并发送跟踪中的所有相关事务Sentry。
另一方面，当您的后端处理来自 B 浏览器请求时，会看到 “no” 因此，它不会向 收集和发送事务和跨度数据Sentry。然而，它将决策传播到后续服务中A 告诉他们不要收集或发送要收集或发送数据。然后他们告诉他们不要发送们呼叫的任何服务的数据，这样他们就不会收集 B 跟踪事务。
简而言之:这个 head-based 的结果是，决定在原始服务中做出一次，并将其传递给所有后续服务，要么收集给定跟踪的所有事务，要么不收集任何事务，因此不应有不完整的跟踪。