在分布式系统中，测量请求生命周期内两点间的时间间隔听起来很简单，对吧？你只需要记录开始和结束时间，查看图表，问题就迎刃而解了。但当客户就某个特定延迟提出问题时，你深入日志、图表和指标进行诊断时，很快就会发现跨越不同系统连接线索远没有想象中那么简单。尽管有先进的工具、可观测性图表、仪表盘和结构良好的日志，要全面了解系统行为依然充满挑战。

最近，我的团队遇到了一个问题，当一位高MRR的客户报告他们测试号码上的特定短信延迟时，这个问题才变得明显起来。我们深入了各种监控工具，试图找出具体的时间，以调查这些特定的短信。

在 Klaviyo 中，我们依赖各种工具来帮助我们更好地了解系统，包括等等。

• Splunk 和 Logstash 用于转换和查询结构化日志数据
• Grafana、Graphite 和 StatsD 用于实时指标的聚合和可视化
• Redshift 用于日志事件相关的 OLAP 查询
• Jaeger 和 Clickhouse 用于追踪
• Sentry 用于追踪异常

每一个这样的工具都很有用，但在提供全面执行情况的连贯画面时，它们都有其固有的局限性。

提供格式化的结构化日志事件内容，以及相关的非结构化数据。

• 确保日志有序排列对于理解控制流程中事件之间的关系至关重要。
• 需要一个特定标识符来跨域关联这些日志。
• 需要详细的与时间相关的字段，包括开始、结束和持续时间戳，以准确捕捉事件的整个生命周期。

• 这些易于使用的工具让实时事件一目了然，便于监控系统性能。

• 在 Graphite 存储中，基数成为一个主要问题，特别是在执行聚合汇总时。这种限制使得基于唯一标识符（例如请求 ID）创建统计桶变得不切实际。因此，为了保持性能并高效管理存储空间，我们常常需要将统计信息的粒度限制在更粗的级别。

• 用 SQL 作为主要查询语言，简化了在各种非结构化的日志来源上执行连接和聚合的操作，从而让数据的分析更加灵活多样。

• 执行查询可能很慢，特别是在处理大量收集的日志事件时。
• Redshift 只提供了一个时间戳字段，该字段记录了日志的摄入时间，而不是需要单独记录的起始时间、结束时间和持续时间等细粒度的时间信息。

• 使识别和排查代码级问题、bug 和运行时错误变得更加容易，实现实时识别和解决。
• 捕获详细的堆栈跟踪和与错误相关联的数据，有助于提供关于错误的详细信息。
• 追踪用户会话，并允许您查看每个错误影响的用户数量，有助于评估问题的影响大小。

• 虽然对于追踪异常非常有效，但它无法自动关联跨越不同域边界的事件，这使得在控制流程中连接这些事件变得困难。
• 错误量高时成本会迅速增加。
• Sentry 主要针对异常，而不是捕获开始、结束或持续时间，不适用于跟踪非异常事件生命周期。

我们很快意识到，在处理一个看似简单的问题时发现自身不足，因为存在几个局限，这表明我们现有的工具链在应对这些问题时存在不足。

1. 事件关联：理解一个事件如何与其他事件关联，并且如何在整体控制流程中找到合适的位置。
2. 时间粒度：获取每个事件的具体时间，包括开始时间、结束时间和持续时间（计算为结束时间减去开始时间）。
3. 采样策略：承认各事件的重要程度不同。我们需要优先处理“高优先级”事件，同时可以适当减少对非关键事件的监控。

我们在关联日志和事件时遇到了一些挑战，这些日志和事件在一个系统中使用特定标识符记录，但当这些事件跨越不同系统时，这些标识符往往无法一致地传递下去。例如，一个系统用 batch_id 标识一批特定的短信，而另一个系统则会用 transmission_id 记录相同的批次，但不会留下 batch_id 的记录。

这种不一致使得难以在不同系统之间关联事件，因为它们缺乏一个共同的属性来进行关联。即便我们设法关联了事件，我们的日志往往无法记录外部日志中的关键时间数据，如开始、结束时间和持续时间，以及准确关联事件所需的顺序。

最近，我们引入了Jaeger到我们的可观测性工具栈中。Jaeger是什么？简单地讲，它是一个工具，用于映射请求和数据在分布式系统中流动。

贾格尔给了你这些线索：

1. 一个独特的跟踪ID（Trace ID）。
2. 事件的确切开始和结束时间。
3. 事件的顺序。
4. 每个方法执行的可视化细分。
5. 记录函数输入和输出的能力。
6. 上下文传播，这意味着如果其他人在其特定领域实现跟踪，您将免费获得该系统的执行情况洞察。

简而言之，在 Python 中，我们只需在任务的前面添加一个装饰器，Jaeger 就会自动追踪整个运行过程。

雅各界面显示处理传输批次任务的请求流程。

可惜的是，使用Jaeger也存在一些挑战。Jaeger生成的跨度数据可能会变得很大，使得追踪每个请求变得不太现实。

因此，我们的跟踪样本比例默认设置为所有流量的 0.01%。虽然这有助于平衡性能和存储资源，但它也带来了只能提供整体系统性能的高层次理解，但缺乏细节的缺点。因此，我们通常无法追踪到具体的事件，比如与某个特定客户相关的事件。

最近，我们团队通过采取一些战略调整，成功克服了一些限制。

首先，我们将Jaeger的追踪ID整合到Splunk日志中，从而可以从任何Splunk日志条目中轻松地识别Jaeger事件。通过将这些日志与Jaeger跨度（spans）关联，我们可以在Jaeger中高效地查找相应的追踪。

这样一来，通过 trace_id 记录，我们可以轻松地从 Splunk 的日志条目直接定位到 Jaeger 的追踪中。

将 trace id 添加到我们的 Splunk 日志中，使我们可以通过在 Jaeger UI 中输入 trace id 直接查找追踪。这种集成将孤立的日志条目变为更广泛控制流中的重要部分。通过这种连接，我们可以获得关于执行流程的重要上下文，从而在特定时间点了解事件数据。这简化了调试过程，使我们能够理解导致事件的序列，以及状态。从而，我们可以清楚地了解这些信息。

此外，我们通过将日志数据纳入Jaeger事件中，增强了日志和跟踪工具之间的集成。这一变化减少了在Jaeger UI和Splunk UI之间切换的需要，因为我们现在可以在一个统一视图中捕获与事件相关的所有信息。

Grafana 中 Jaeger 跟踪的某部分视图。日志部分源自代码中的日志记录语句。这些信息以前仅可在 Splunk 中查看。

我们也利用了Jaeger附加异常回溯的功能，从而能够捕获任何异常的详细堆栈信息。

在Jaeger UI中，我们现在能够看到异常的完整堆栈轨迹。

这些改进为任何被追踪注解的方法提供了多项立即可见的好处：

1. 在查看Splunk的日志时，我们可以轻松地查看该方法的所有持续时间指标。
2. 我们可以轻松地可视化跨域边界的执行流程，包括异常跟踪。
3. 更容易访问更多的日志状态信息，这使得重现问题变得更加简单。

凭借这些改进，我们现在可以在不到一分钟的时间内访问与发送特定短信相关的Jaeger追踪。我们可以迅速确定总执行时间，并自信地告知客户延迟是否源自我们的系统或其他地方。这种效率与原来回答同样问题需要数小时形成了鲜明对比！

然而，使用只有_0.01%_请求的均匀随机样本，其捕捉任何特定事件的踪迹的可能性相当低。我们尝试改进我们的采样策略。尤其是涉及高流量客户或有历史问题的客户来说，优先处理这些关键执行对于调试我们服务水平目标（SLOs）和服务水平协议（SLAs）中的潜在回退至关重要。这一洞察使我们更专注于捕捉来自特定公司的更多事件。

我们决定保持默认采样率为 0.01%，同时允许根据业务需求调整为其他采样率。譬如，我们可以为公司ABC设置 50% 的采样率。

为了达到这个目的，我们利用了内部的hotsettings系统，该系统使我们能够动态地配置存储在Redis集群中的设置，并实时检索为哈希集的形式。这种灵活性使我们能够定义任何想要追踪的属性的自定义业务规则，通过JSON模式，这些规则还包括采样率。例如，如果我们希望记录id为ABC的客户的事件的50%，那么我们的配置将如下所示:

{
    "公司ID": {  
        "ABC": 50  
    }  
}

利用这种设置，我们可以根据 JSON 模式中任何指定的属性实时动态调整事件的捕获，从而按需增加或减少捕获的信息量。

最后的结果是：

• 可配置的采样率让我们在限制过度数据采集的同时，动态捕获最关键的相关事件。
• 将日志与跟踪合并提供了执行流程的完整视图，涵盖开始和结束时间、时长、输入/输出数据以及跨域上下文传递。
• 现在我们可以利用 Splunk 中的日志查询功能快速找到任何属性相关的 Jaeger 跟踪。

这些好处结合起来帮助我们迅速解答了特定延迟的问题，从以前需要数小时查看日志到现在只需几秒钟。