监控分布式系统

本文由 Rob Ewaschuk 撰写，由 Betsy Beyer 编辑。本文是翻译的GoogleSRE权威指南第六章。

Google 的 SRE 团队有一些基本原则和最佳实践来构建成功的监控和警报系统。本章提供了关于哪些问题应该通过页面打断人，以及如何处理没有严重到足以触发页面的问题的指南。

定义

没有统一的共享词汇来讨论与监控相关的所有主题。即使在 Google 内部，以下术语的用法也各不相同，但此处列出了最常见的解释。

监控收集、处理、聚合和显示有关系统的实时定量数据，例如查询计数和类型、错误计数和类型、处理时间和服务器生命周期。

白盒监控：基于系统内部公开的指标进行监控，包括日志、接口（如 Java 虚拟机分析接口）或发出内部统计信息的 HTTP 处理程序。黑盒监控：测试用户看到的外部可见行为。仪表板提供服务核心指标摘要视图的应用程序（通常基于 Web）。仪表板可能有过滤器、选择器等，但都是预先构建的，以向其用户公开最重要的指标。仪表板还可能显示团队信息，例如工单队列长度、高优先级错误列表、给定责任区域的当前待命工程师或最近的推送。警报：旨在供人阅读并被推送到系统的通知，例如错误或票证队列、电子邮件别名或寻呼机。这些警报分别被分类为工单、电子邮件警报、页面。根因：软件或人类系统中的缺陷，如果修复，会让人相信此事件不会以同样的方式再次发生。一个给定的事件可能有多个根本原因：例如，它可能是由流程自动化不足、软件因虚假输入而崩溃以及对用于生成配置的脚本的测试不足等因素共同造成的。这些因素中的每一个都可能单独作为根本原因，并且每个因素都应该被修复。节点和机器可互换使用以指示物理服务器、虚拟机或容器中正在运行的内核的单个实例。一台机器上可能有多个值得监控的服务。这些服务可以是：相互关联：例如缓存服务器和网络服务器，不相关的服务共享硬件：例如，一个代码存储库和一个配置系统的主机，如Puppet或Chef推对服务的运行软件或其配置的任何更改。为什么要监控？

监视系统的原因有很多，包括：

分析长期趋势我的数据库有多大，增长速度有多快？我的每日活跃用户数增长的速度有多快？随着时间或实验组进行比较与 Ajax DB 3.14 相比，Acme Bucket of Bytes 2.72 的查询速度更快吗？多一个节点后，我的内存缓存命中率会好多少？我的网站比上周慢了吗？警报有些东西坏了，现在需要有人修理它！或者，某些东西可能很快就会坏掉，所以有人应该尽快查看。构建仪表板仪表板应该回答有关您的服务的基本问题，并且通常包括某种形式的四个黄金信号（在四个黄金信号中讨论）。进行临时回顾性分析（即调试）我们的延迟刚刚飙升；大约在同一时间还发生了什么？

系统监控还有助于为业务分析提供原始输入，并有助于分析安全漏洞。由于本书侧重于 SRE 具有特殊专业知识的工程领域，因此我们不会在这里讨论这些监控应用。

监控和警报使系统能够告诉我们它何时损坏，或者可能告诉我们什么将要损坏。当系统无法自动修复时，我们希望有人调查警报，确定手头是否存在真正的问题，缓解问题，并确定问题的根本原因。除非您对系统的范围非常狭窄的组件执行安全审计，否则您永远不应仅仅因为“有些事情看起来有点奇怪”而触发警报。

寻呼一个人是对员工时间的一种相当昂贵的使用。如果员工在工作，页面会中断他们的工作流程。如果员工在家，传呼会打扰他们的个人时间，甚至可能打扰他们的睡眠。当页面出现得太频繁时，员工会猜测、浏览甚至忽略传入的警报，有时甚至会忽略被噪音掩盖的“真实”页面。中断可能会延长，因为其他噪音会干扰快速诊断和修复。有效的警报系统具有良好的信号和非常低的噪音。

为监测设定合理的期望

监控复杂的应用程序本身就是一项重大的工程工作。即使现有大量用于检测、收集、显示和警报的基础架构，拥有 10-12 名成员的 Google SRE 团队通常也有一名或有时两名成员的主要任务是为其服务构建和维护监控系统。随着我们推广和集中通用监控基础设施，这个数字随着时间的推移而减少，但每个 SRE 团队通常至少有一个“监控人员”。（话虽这么说，虽然访问流量图表仪表板等可能很有趣，但 SRE 团队会小心避免任何需要有人“盯着屏幕看问题”的情况。）

总的来说，谷歌倾向于使用更简单、更快速的监控系统，并提供更好的事后分析工具。我们避免尝试学习阈值或自动检测因果关系的“魔法”系统。检测最终用户请求率意外变化的规则是一个反例；虽然这些规则仍然尽可能简单，但它们可以非常快速地检测到非常简单、具体、严重的异常情况。容量规划和流量预测等监控数据的其他用途可以容忍更多的脆弱性，因此也可以容忍更多的复杂性。在很长的时间范围（数月或​数年）内以低采样率（数小时或数天）进行的观察实验通常也可以容忍更多的脆弱性，因为偶尔丢失的样本不会隐藏长期趋势。

Google SRE 在复杂的依赖层次结构方面只取得了有限的成功。我们很少使用这样的规则，“如果我知道数据库很慢，就对慢速数据库发出警报；否则，就对普遍较慢的网站发出警报”。依赖依赖规则通常与我们系统中非常稳定的部分有关，例如我们用于将用户流量从数据中心排出的系统。例如，“如果数据中心耗尽，则不要提醒我它的延迟”是一种常见的数据中心警报规则。谷歌很少有团队维护复杂的依赖层次结构，因为我们的基础设施具有稳定的持续重构率。

本章中描述的一些想法仍然是有包袱的：总是有更快地从症状转变为根本原因的空间，尤其是在不断变化的系统中。因此，虽然本章为监控系统设定了一些目标，以及实现这些目标的一些方法，但重要的是，监控系统——尤其是从生产问题开始、通过页面到人、通过基本分类和深度分析的关键路径。调试——让团队中的每个人都保持简单和理解。

同样，为了保持低噪音和高信号，您的监控系统中指向寻呼机的元件需要非常简单和强大。为人类生成警报的规则应该易于理解并代表明显的失败。

症状与原因

您的监控系统应该解决两个问题：什么坏了，为什么？

“什么坏了”表示症状；“为什么”表示一个（可能是中间的）原因。

“什么”与“为什么”是编写具有最大信号和最小噪声的良好监控的最重要区别之一。

黑盒与白盒

我们将白盒监控的大量使用与黑盒监控的适度但关键的使用相结合。考虑黑盒监控与白盒监控的最简单方法是，黑盒监控是面向症状的，代表活动的——而不是预测的——问题：“系统现在没有正常工作。” 白盒监控取决于使用仪器检查系统内部结构（例如日志或 HTTP 端点）的能力。因此，白盒监控允许检测迫在眉睫的问题、被重试掩盖的故障等。

请注意，在多层系统中，一个人的症状是另一个人的原因。例如，假设数据库的性能很慢。缓慢的数据库读取是检测它们的数据库 SRE 的症状。然而，对于观察缓慢网站的前端 SRE，同样缓慢的数据库读取也是一个原因。因此，白盒监控有时是面向症状的，有时是面向原因的，具体取决于您的白盒提供的信息量。

在收集遥测数据进行调试时，白盒监控必不可少。如果 Web 服务器在处理大量数据库请求时看起来很慢，您需要知道 Web 服务器认为数据库有多快，以及数据库认为自己有多快。否则，您无法区分实际速度较慢的数据库服务器和您的 Web 服务器与数据库之间的网络问题。

对于寻呼，黑盒监控的主要好处是，当问题已经持续存在并导致真正的症状时，强制纪律只对人唠叨。另一方面，对于尚未发生但迫在眉睫的问题，黑盒监控是相当无用的。

四个黄金信号

监控的四个黄金信号是延迟、流量、错误和饱和度。如果您只能衡量面向用户的系统的四个指标，请关注这四个指标。

潜伏服务请求所需的时间。区分成功请求的延迟和失败请求的延迟很重要。例如，由于与数据库或其他关键后端的连接丢失而触发的 HTTP 500 错误可能会很快得到服务；

但是，由于 HTTP 500 错误表示请求失败，将 500 秒计入整体延迟可能会导致误导性计算。另一方面，慢速错误比快速错误更糟糕！因此，跟踪错误延迟非常重要，而不是仅仅过滤掉错误。流量衡量对您的系统有多少需求的衡量标准，以高级系统特定指标衡量。

对于 Web 服务，此度量通常是每秒 HTTP 请求数，可能按请求的性质（例如，静态内容与动态内容）分开。对于音频流系统，此测量可能侧重于网络 I/O 速率或并发会话。

对于键值存储系统，此度量可能是每秒的事务数和检索数。错误失败的请求率，无论是显式（例如 HTTP 500s）、隐式（例如 HTTP 200 成功响应，但伴随着错误的内容），还是策略（例如，“如果您承诺一秒钟响应时间，任何超过一秒的请求都是错误的”）。在协议响应代码不足以表达所有故障情况的情况下，可能需要辅助（内部）协议来跟踪部分故障模式。

监控这些情况可能会截然不同：在您的负载均衡器上捕获 HTTP 500 可以很好地捕获所有完全失败的请求，而只有端到端系统测试才能检测到您提供了错误的内容。

系统分数的度量，强调最受限的资源（例如，在内存受限的系统中，显示内存；在 I/O 受限的系统中，显示 I/O）。请注意，许多系统在达到 100% 利用率之前会降低性能，因此拥有一个利用率目标至关重要。

在复杂的系统中，可以通过更高级别的负载测量来补充饱和度：您的服务能否正确处理两倍的流量、仅多处理 10% 的流量，或者处理比当前接收的流量更少的流量？对于没有改变请求复杂性的参数的非常简单的服务（例如，“给我一个随机数”或“我需要一个全局唯一的单调整数”），很少更改配置，来自负载测试的静态值可能就足够了. 然而，如前一段所述，大多数服务需要使用间接信号，例如 CPU 利用率或具有已知上限的网络带宽。延迟增加通常是饱和度的领先指标。在某个小窗口（例如，一分钟）内测量第 99 个百分位的响应时间可以提供非常早的饱和信号。最后，饱和度还与即将饱和的预测有关，例如“看起来您的数据库将在 4 小时内填满其硬盘驱动器”。

如果您测量所有四个黄金信号并在一个信号有问题（或者在饱和的情况下几乎有问题）时传呼一个人，您的服务至少会受到监控。

担心你的尾巴（或仪器和性能）

从头开始构建监控系统时，很容易根据一些数量的平均值来设计系统：平均延迟、节点的平均 CPU 使用率或数据库的平均填充度。后两种情况带来的危险是显而易见的：CPU 和数据库很容易以非常不平衡的方式使用。延迟也是如此。如果您以每秒 1,000 个请求的速度运行平均延迟为 100 毫秒的 Web 服务，则 1% 的请求可能很容易花费 5 秒。23如果您的用户依赖于多个此类 Web 服务来呈现他们的页面，则一个后端的第 99 个百分位数很容易成为您前端的中值响应。

区分缓慢的平均请求和非常慢的“尾部”请求的最简单方法是收集按延迟（适合呈现直方图）计算的请求计数，而不是实际延迟：我处理了多少请求，耗时在 0 毫秒之间和 10 毫秒，10 毫秒和 30 毫秒之间，30 毫秒和 100 毫秒之间，100 毫秒和 300 毫秒之间，等等？近似指数地分布直方图边界（在本例中大约为 3 倍）通常是可视化请求分布的一种简单方法。

为测量选择合适的分辨率

系统的不同方面应该用不同的粒度级别进行测量。例如：

在一分钟的时间跨度内观察 CPU 负载不会揭示导致高尾延迟的相当长的峰值。另一方面，对于目标为每年总停机时间不超过 9 小时（每年正常运行时间为 99.9%）的 Web 服务，每分钟探测 200（成功）状态超过一次或两次可能是不必要的频繁。同样，对于以 99.9% 可用性为目标的服务，每 1-2 分钟检查一次以上的硬盘驱动器充满度可能是不必要的。

请注意如何构建测量的粒度。收集每秒的 CPU 负载测量值可能会产生有趣的数据，但收集、存储和分析这种频繁的测量值可能非常昂贵。如果您的监控目标需要高分辨率但不需要极低的延迟，您可以通过在服务器上执行内部采样来降低这些成本，然后配置外部系统以随时间或跨服务器收集和汇总该分布。你可能：

每秒记录当前的 CPU 使用率。使用 5% 粒度的桶，每秒增加适当的 CPU 利用率桶。每分钟汇总这些值。

此策略允许您观察短暂的 CPU 热点，而不会因收集和保留而产生非常高的成本。

越简单越好

将所有这些要求叠加在一起会构成一个非常复杂的监控系统——您的系统最终可能会达到以下复杂程度：

关于不同延迟阈值、不同百分位数、各种不同指标的警报用于检测和暴露可能原因的额外代码每个可能原因的相关仪表板

潜在复杂性的来源是永无止境的。与所有软件系统一样，监控可能会变得非常复杂，以至于它变得脆弱、更改起来很复杂并且会增加维护负担。

因此，设计您的监控系统时应着眼于简单性。在选择要监视的内容时，请牢记以下准则：

最常捕捉真实事件的规则应该尽可能简单、可预测和可靠。很少使用的数据收集、聚合和警报配置（例如，某些 SRE 团队每季度少于一次）应该被删除。已收集但未暴露在任何预制仪表板中或被任何警报使用的信号是要删除的候选信号。

根据谷歌的经验，指标的基本收集和聚合，与警报和仪表板相结合，作为一个相对独立的系统运行良好。（事实上​​谷歌的监控系统被分解成几个二进制文件，但通常人们了解这些二进制文件的所有方面。）将监控与检查复杂系统的其他方面结合起来可能很诱人，例如详细的系统分析、单进程调试、跟踪有关异常或崩溃的详细信息、负载测试、日志收集和分析或流量检查。虽然这些主题中的大多数与基本监控有共同点，但将太多主题混合在一起会导致系统过于复杂和脆弱。与软件工程的许多其他方面一样，使用清晰、简单、

将这些原则结合在一起

本章讨论的原则可以结合成一种在 Google SRE 团队中广泛认可和遵循的监控和警报理念。虽然这种监控理念有点令人向往，但它是编写或审查新警报的一个很好的起点，它可以帮助您的组织提出正确的问题，无论您的组织规模或服务或系统的复杂程度如何。

在创建监控和警报规则时，提出以下问题可以帮助您避免误报和寻呼机倦怠：24

此规则是否检测到其他未检测到的紧急、可操作、主动或即将用户可见的情况？25知道它是良性的，我是否能够忽略此警报？我何时以及为何能够忽略此警报，以及如何避免这种情况？此警报是否明确表明用户受到了负面影响？是否存在用户没有受到负面影响的可检测案例，例如流量耗尽或测试部署，应该被过滤掉？我可以对此警报采取行动吗？这个行动是紧急的，还是可以等到早上？该操作可以安全地自动化吗？该行动是长期解决方案，还是只是短期解决方案？其他人是否因为这个问题而被传呼，因此至少有一个页面是不必要的？

这些问题反映了页面和寻呼机的基本理念：

每次传呼机响起，我都应该能够以紧迫感做出反应。在我变得疲倦之前，我每天只能以紧迫感做出几次反应。每个页面都应该是可操作的。每个页面响应都应该需要情报。如果一个页面仅仅值得一个机器人响应，它不应该是一个页面。页面应该是关于一个新问题或以前从未见过的事件。

这样的观点消除了某些区别：如果一个页面满足前面的四个要点，则该页面是由白盒监控还是黑盒监控触发的都无关紧要。这种观点也放大了某些区别：最好花更多的精力来捕捉症状而不是原因；当谈到原因时，只担心非常明确、非常迫在眉睫的原因。

长期监测

在现代生产系统中，监控系统跟踪一个不断发展的系统，其软件架构、负载特征和性能目标不断变化。当前异常罕见且难以自动化的警报可能会变得频繁出现，甚至可能需要编写一个脚本来解决它。此时，应该有人找到并消除问题的根源；如果这样的解决方案是不可能的，那么警报响应应该是完全自动化的。

重要的是要在考虑长期目标的情况下做出有关监控的决定。今天发生的每一页都会分散人们对明天改进系统的注意力，因此通常会有短期影响可用性或性能的情况，以改善系统的长期前景。让我们看一下说明这种权衡的两个案例研究。

Bigtable SRE：过度警报的故事

Google 的内部基础架构通常根据服务级别目标（SLO；请参阅服务级别目标）提供和衡量。许多年前，Bigtable 服务的 SLO 是基于一个综合的表现良好的客户端的平均性能。由于 Bigtable 和存储堆栈的较低层存在问题，平均性能由“大”尾驱动：最差的 5% 的请求通常比其余请求慢得多。

当接近 SLO 时触发电子邮件警报，当超过 SLO 时触发寻呼警报。两种类型的警报都大量触发，消耗了不可接受的工程时间：团队花费了大量时间对警报进行分类，以找到少数真正可行的警报，但我们经常错过真正影响用户的问题，因为它们太少了做过。由于基础设施中众所周知的问题，许多页面都不是紧急的，并且要么死记硬背，要么没有收到任何回复。

为了补救这种情况，该团队采用了三管齐下的方法：在努力提高 Bigtable 性能的同时，我们还临时拨回了我们的 SLO 目标，使用 75% 的请求延迟。我们还禁用了电子邮件警报，因为电子邮件警报太多，以至于花时间诊断它们是不可行的。

这种策略给了我们足够的喘息空间来实际解决 Bigtable 和存储堆栈的较低层中的长期问题，而不是不断地解决战术问题。值班工程师在没有被页面随时跟进的情况下实际上可以完成工作。最终，暂时取消我们的警报使我们能够在提供更好服务方面取得更快的进展。

Gmail：来自人类的可预测、可编写脚本的响应

在 Gmail 的早期，该服务是建立在一个名为 Workqueue 的改进分布式进程管理系统上的，该系统最初是为批量处理搜索索引片段而创建的。Workqueue 已“适应”长期存在的进程，并随后应用于 Gmail，但事实证明，调度程序中相对不透明的代码库中的某些错误很难解决。

当时，Gmail 监控的结构是当单个任务被 Workqueue“取消计划”时触发警报。这种设置并不理想，因为即使在那个时候，Gmail 也有许多、数千个任务，每个任务代表我们用户的一小部分。我们非常关心为 Gmail 用户提供良好的用户体验，但这样的警报设置无法维护。

为了解决这个问题，Gmail SRE 构建了一个工具，帮助以正确的方式“戳”调度程序，以最大限度地减少对用户的影响。团队就是否应该简单地自动化整个循环（从检测问题到推动重新调度程序，直到实现更好的长期解决方案）进行了多次讨论，但一些人担心这种解决方法会延迟真正的修复。

这种紧张在团队中很常见，通常反映出对团队自律的潜在不信任：虽然一些团队成员想要实施“黑客攻击”以便有时间进行适当的修复，但其他人担心黑客攻击会被遗忘或者适当的修复将被无限期地取消优先级。这种担忧是可信的，因为很容易通过修补问题而不是进行真正的修复来建立多层无法维护的技术债务。经理和技术领导者通过支持和优先考虑可能耗时的长期修复，在实施真正的长期修复方面发挥着关键作用，即使最初的分页“痛苦”已经消退。

带有死记硬背的算法响应的页面应该是一个危险信号。您的团队不愿意自动化此类页面意味着该团队对他们可以清理技术债务缺乏信心。这是一个值得升级的主要问题。

长跑

一个共同的主题将之前的 Bigtable 和 Gmail 示例联系在一起：短期和长期可用性之间的紧张关系。通常，纯粹的努力可以帮助摇摇欲坠的系统实现高可用性，但这条道路通常是短暂的，并且充满了倦怠和对少数英勇团队成员的依赖。采取受控的、短期的可用性下降通常是一种痛苦的，但对系统的长期稳定性来说是一种战略性的交易。重要的是不要将每个页面都视为孤立的事件，而是要考虑整体水平是否寻呼技术会导致一个健康、适当可用的系统，该系统具有健康、可行的团队和长期前景。我们在与管理层的季度报告中审查有关传呼频率的统计数据（通常表示为每个班次的事件，其中一个事件可能由几个相关页面组成），确保决策者及时了解传呼负载和他们的整体健康状况团队。

结论

健康的监控和警报管道简单易行。它主要关注分页的症状，保留面向原因的启发式方法来帮助调试问题。您监控的堆栈越“向上”，监控症状就越容易，尽管监控饱和度和子系统（例如数据库）的性能通常必须直接在子系统本身上执行。电子邮件警报的价值非常有限，而且很容易被噪音淹没；相反，您应该喜欢一个仪表板来监控所有正在进行的亚临界问题，以获取通常以电子邮件警报结尾的信息。仪表板也可以与日志配对，以便分析历史相关性。

从长远来看，实现成功的随叫随到轮换和产品包括选择提醒症状或迫在眉睫的实际问题，使您的目标适应实际可实现的目标，并确保您的监控支持快速诊断。

22有时被称为“警报垃圾邮件”，因为它们很少被阅读或采取行动。

23如果 1% 的请求是平均值的 50 倍，则意味着其余请求的速度大约是平均值的两倍。但是，如果您不衡量您的分布，那么您的大部分请求都接近均值的想法只是充满希望的想法。

24请参阅Applying Cardiac Alarm Management Techniques to Your On-Call [Hol14]以获取另一个上下文中警报疲劳的示例。

25 种零冗余 ( N + 0) 情况被视为迫在眉睫，您的服务中“几乎满载”的部分也是如此！有关冗余概念的更多详细信息，请参阅。