想调试延迟吗？

近十年来，我们的系统变得复杂。我们的平均生产环境由许多不同的服务（许多微服务，存储系统等）组成，具有不同的部署和生产维护周期。在大多数情况下，每项服务都由不同的团队建立和维护 - 甚至有时由不同的公司完成。所以其中一个团队对其他团队的服务没有太多的了解。将所有东西放在一起的最终粘合在一起的通常是一个临时环境，或者有时候是产品本身！

随着我们的系统变得越来越复杂，测量延迟和能够对延迟问题做出反应变得同样复杂。本文将帮助您如何在延迟问题中找到自己的位置，以及您需要如何有效地完成此操作。

延迟

那么，什么是延迟？延迟是做某事所需的时间。需要多长时间才能得到回复？处理队列中的消息需要多长时间？

我们使用延迟作为核心措施之一来判断系统是否按预期的端到端方式工作。在关键路径（用户请求的生命周期）中，延迟是有助于整体用户体验的核心元素。它也使我们能够按照预期利用我们的资源，或者我们的吞吐量在我们的预期之内。

即使您没有进行延迟测量，您也可能已经熟悉每天报告延迟结果的各种工具。作为一个日常示例，各种浏览器开发者工具报告构成网页的所有请求所需的时间并报告总时间：

延迟是我们在服务之间设置的SLOs中的关键因素。每个团队为他们的服务设置SLO（例如，第50百分位延迟可以是20ms，第90百分位延迟可以是80ms，第99百分位可以是300ms），并监视它们的延迟以查看是否存在任何SLO违规。（观看“ SLIs, SLOs, SLAs, oh my! ”以了解更多关于SLO的信息。）

但是，我们如何系统地收集和分析当今生产系统中的请求延迟呢？

我们测量每个请求的延迟，主要使用度量收集系统来可视化和触发自动警报。延迟采集是未采样的（我们为每个请求收集延迟度量标准）并将其汇总为直方图分布，以提供对更高百分点的可见性。

您可以使用您选择的收集库来收集延迟指标。如果您已经计划将Prometheus用作后端，请查看他们的客户端库。或者，如果您使用的是gRPC，则可以从OpenCensus导出。

有意想不到的延迟吗？

为了检测延迟中的异常情况，我们需要首先回答什么是预期延迟。每项服务都有不同的要求，可能会出现意外延迟。以100％的可靠性提供服务几乎是不可能的，因此我们需要首先确定什么样的延迟范围会给用户带来他们认为不存在问题的体验。

“对于inbox.GetEmails调用，第99百分位请求延迟应小于300ms。”是一个示例SLO，我们为收件箱服务的GetEmails方法设置了第99百分位的延迟上限。可能有超过300毫秒的请求，但如果没有达到第99个百分点，则不会违反SLO。你可以用一个或更高的百分比来定义你的SLOs。（请观看如何不衡量延迟以了解百分比的重要性。）

当SLO违规发生时，我们可以自动触发警报，并通过ping通知调用方查看。或者您可以从客户那里听到，他们期望延迟很低，并要求您解决这个问题。

延迟的来源是什么?

当警报被触发或客户与您联系时，预计待召人员会看一眼。此时，他们知道存在延迟违规或其他糟糕·的情况。我们通常知道具体的服务/方法是什么，但不知道潜在的原因。此时，我们可以查看服务/方法的延迟分布热图。

热图可视化延时分布随着时间的改变而改变; x轴是时间，y轴是测量落入的等待时间桶。

我们最近开始将延迟分发桶与适合该桶的范例跟踪关联起来。这允许我们在调试延迟问题时从特定的延迟桶中找到跟踪。（有关更多详细信息，请观看使用更好的调试策略更快地解决停机问题。）

1. 每一个绿色的星星都代表着水桶的范例。当您单击它时，它将带您到跟踪示例，您可以看到位于该桶中的一个调用的分布式跟踪。

点击一个星星，你就可以看到跟踪，在那里你可以更清楚地看到在这个请求的生命周期中发生了什么。跟踪可以引导我们找到潜在的问题。如果我们所依赖的服务中出现了意外的中断，或者出现了网络问题，或者出现了不太可能的延迟问题，那么可以识别这种情况。

一旦我们检查了（1）中与延迟桶有关的跟踪信息，我们就会看到Spanner.Apply调用花费的时间比它特定的跟踪时间长，并且doond.GetDocs花了额外的40ms用于非RPC作业。

解决延迟问题

度量和跟踪可以导航到延迟已被根除的位置，但可能不是理解延迟的根本原因的主要工具。糟糕的调度、网络问题、糟糕的虚拟化、语言运行时、计算开销巨大的代码和类似的问题可能是原因。

一旦我们缩小了服务延迟的来源，有时也缩小到特定的进程，为了理解底层原因，我们首先要看主机特定的和进程内的原因，为什么会发生延迟。例如，要查看的特定于主机的信号的利用率和内存指标。

如果主机正常运行并且网络没有受到影响，我们可能会继续分析进程中的等待时间源。

通常，服务器正在处理大量的请求，并且没有简单的方法来隔离请求生命周期中发生的事件。一些语言运行时（比如Go）允许我们在请求的生命周期内部跟踪运行时事件。像运行时跟踪器这样的工具通常非常昂贵，如果我们试图诊断一个问题，我们就可以暂时使它们在生产中使用。我们暂时启用集合，尝试复制延迟问题。我们可以看到延迟是由I/O引起的，是由运行时触发的阻塞事件还是停止事件。如果没有，我们可以排除这些可能性。

有时延迟是由计算代价昂贵的代码造成的。例如，如果您推出取决于新压缩库的新版本，则可能会出现比平时更高的延迟。能够使用RPC名称标记探查器样本对于了解服务器上特定RPC的成本至关重要。

结论

延迟是确定我们的系统是否正常运行的关键度量。尽管度量标准可以确定是否存在延迟问题，但我们需要额外的信号和工具来进一步分析情况。能够将诊断信号与RPC名称，主机标识符和环境元数据相关联，使我们能够查看来自特定问题站点的各种不同信号。

原文作者：JBD

原文地址：https://medium.com/observability/want-to-debug-latency-7aa48ecbe8f7?source=search_post