SRE（站点可靠性工程）-一种确保Web项目可用性的方法。 它被认为是DevOps的框架，并告诉您如何成功应用DevOps实践。 本文是Google 网站可靠性工程丛书中第6章“监视分布式系统”的译文。 我自己准备了此翻译，并依靠自己的经验来了解监视过程。 在电报频道@monitorim_it和Medium博客上，我还发布了指向同一本书第4章翻译的链接，该链接涉及服务水平的目标。

由猫翻译。 祝您阅读愉快！

Google SRE团队具有创建成功的监视和通知系统的基本原则和最佳做法。 本章提供有关网页访问者可能遇到的问题以及如何解决使网页难以显示的问题的建议。

定义

没有一个词汇可以用来讨论与监视有关的主题。 即使在Google，以下术语也不常用，但我们将列出最常见的解释。

监控方式

实时收集，处理，汇总和显示有关系统的定量数据：请求数量和请求类型，错误数量和错误类型，请求处理时间和服务器正常运行时间。

白盒监控

基于系统内部组件显示的指标进行监视，这些指标包括日志，Java虚拟机的分析指标或生成内部统计信息的HTTP处理程序。

黑匣子监控

从用户的角度测试应用程序的行为。

仪表板（仪表板）

一个界面（通常是Web），概述了服务的关键健康指标。 仪表板可以具有过滤器，选择要显示的指示器的能力等。创建界面以识别用户最重要的指示器。 技术支持人员的信息也可以显示在仪表板上：请求队列，高优先级错误列表，给定职责范围内的分配工程师。

警报（通知）

旨在通过电子邮件或其他方式由人接收的通知，可以由于错误或请求队列增加而启动通知。 通知分类为：票证，电子邮件警报和信使消息。

根本原因

消除后不应再次出现的软件缺陷或人为因素。 该问题可能有几个主要原因：流程自动化不足，软件缺陷，对应用程序逻辑的研究不足。 这些因素中的每一个都可能是根本原因，因此必须消除它们。

节点和机器

可互换的术语，表示物理服务器，虚拟机或容器上正在运行的应用程序的单个实例。 一台机器上可以有多种服务。 服务可能是：

• 彼此相关：例如，缓存服务器和Web服务器；
• 单个硬件上不相关的服务：例如，代码存储库和配置系统的向导，例如Puppet或Chef 。

推入

对软件配置的任何更改。

为什么需要监控

监视应用程序的原因有几个：

长期趋势分析

数据库有多大，增长多快？ 每日用户数如何变化？

性能比较

Acme Bucket of Bytes 2.72查询比Ajax DB 3.14快吗？ 在出现另一个节点之后，对请求的缓存会更好吗？ 与上周相比，网站变慢了吗？

警报（通知）

某些地方坏了，需要修复。 否则某些内容很快就会崩溃，因此有人应该尽快检查出来。

创建仪表板

仪表板应回答一些基本问题，并包括“四个黄金信号”中的一些 -延迟，流量，错误和负载（饱和度）。

进行回顾性分析（调试）

请求处理延迟增加了，并且大约在同一时间发生了什么？
监视系统可用作商业智能系统的数据源，并简化对安全事件的分析。 由于本书侧重于SRE具有专业知识的工程领域，因此在此我们将不讨论监视技术。

监视和警报使系统可以告知何时已损坏或将要损坏。 当系统无法自动恢复自身时，我们希望由人员进行分析，确定问题是否相关，已解决并确定其根本原因。 如果您不审核系统组件，则永远不会仅仅因为“某些事情看起来有些奇怪”而收到警报。

人为警报的负担是对员工时间的相当昂贵的使用。 如果员工正在工作，则警报会中断工作流程。 如果员工在家，则通知会中断个人时间，甚至可能导致睡眠中断。 当警报发生得太频繁时，员工会迅速扫描，延迟或忽略传入的警报。 他们不时会忽略被噪音事件掩盖的真实警报。 服务中断可能会持续很长时间，因为噪声事件会干扰快速诊断和故障排除。 高效的警报系统具有良好的信噪比。

定义监控系统的合理期望

设置对复杂应用程序的监视本身是一项艰巨的工程任务。 即使拥有大量用于收集，显示和警报工具的基础架构，拥有10至12名成员的Google SRE团队通常也只有一两个人，其主要目的是创建和维护监视系统。 随着我们对监控基础结构的普遍化和集中化，这个数字随着时间的推移而减少，但是每个SRE团队通常至少拥有一名监控人员。 我必须说，尽管观看监视系统的仪表板非常有趣，但是SRE团队谨慎地避免了需要有人看着屏幕来监视问题的情况。

通常，Google会使用具有用于事后分析的最佳工具的简单，快速的监视系统。 我们避免使用试图预测阈值或自动检测根本原因的“神奇”系统。 唯一的反例是检测最终用户请求中不适当内容的传感器。 只要这些传感器保持简单，它们就可以迅速识别出严重异常的原因。 使用监视数据的其他格式（例如容量计划或流量预测）更具挑战性。 在很长的时间（数月或数年）内以低采样率（数小时或数天）进行的观察将显示出长期趋势。

Google SRE团队在处理复杂的依赖层次结构方面取得了不同的成功。 我们很少使用诸如“如果我发现数据库开始缓慢运行，就会收到有关数据库运行缓慢的通知，否则会收到有关运行缓慢的站点的警报”之类的规则。 基于依赖的规则通常适用于我们系统的不变部分，例如用于过滤到数据中心的用户流量的系统。 例如，“如果配置了到数据中心的流量过滤，请不要在处理用户请求时警告我”-这是来自数据中心的通知的一般规则。 Google很少有团队支持复杂的依赖项层次结构，因为我们的基础架构具有恒定的连续重构率。

本章中描述的一些想法仍然是相关的：始终有机会从症状到根本原因更快地转移，尤其是在不断变化的系统中。 因此，尽管本章概述了监视系统的一些目标以及实现这些目标的方法，但是监视系统对于团队中的每个人来说都是简单易懂的，这一点很重要。

同样，为了保持低噪声水平和高信号水平，监视为其发出警报的对象的方法应该非常简单和可靠。 为人们生成警告的规则应该易于理解并提出明确的问题。

症状与原因

您的监视系统应回答两个问题：“什么坏了”和“为什么坏了”。
“发生了什么”说明了症状，并说了“原因”。 下表显示了此类捆绑包的示例。

“什么”和“为什么”是创建具有最大信号和最小噪声的良好监视系统的一些最重要的组成部分。

黑盒与白盒

我们将广泛的白盒监控与适度的黑盒监控相结合，以实现关键指标。 比较黑匣子和白匣子的最简单方法是，黑匣子是针对症状的，是反应性的，而不是主动监视：“系统目前无法正常工作。” 白框取决于内部系统验证的功能：事件日志或Web服务器。 因此，白盒允许您检测将来的问题，类似重新发送请求的故障等。

请注意，在多层系统中，一位工程师的职责范围内的症状就是另一位工程师的职责范围内的症状。 例如，数据库性能下降。 数据库读取速度慢是检测到它们的数据库上SRE的症状。 但是，对于观察到网站速度缓慢的前端SRE，数据库同样缓慢读取的原因是数据库操作缓慢。 因此，白盒监视有时取决于症状，有时取决于原因，具体取决于其范围。

收集遥测时，需要进行白盒监视以进行调试。 如果Web服务器对数据库查询的响应速度很慢，则需要了解Web服务器与数据库交互的速度以及响应速度。 否则，您无法将慢速数据库服务器与Web服务器和数据库之间的网络问题区分开。

发送警报时，黑匣子监视具有一个关键优势：当问题已经导致实际症状时，您可以向收件人发起通知。 另一方面，对于尚未出现但即将发生的黑匣子问题，监视是无用的。

四个黄金信号

四个黄金监控信号是等待时间，流量，错误和饱和度。 如果您只能测量一个用户系统中的四个指标，请专注于这四个指标。

延误

处理请求所需的时间。 区分成功请求和不成功请求的延迟很重要。 例如，可以非常迅速地诊断出由于与数据库或其他后端的连接断开而导致的HTTP 500错误，但是，HTTP 500错误可能表示请求失败。 识别错误500对总延迟的影响可能导致错误的结论。 另一方面，缓慢的错误甚至是快速的错误！ 因此，重要的是跟踪带有错误的延迟，而不仅仅是过滤错误。

交通量

对系统的请求数量以高级系统指标进行衡量。 对于Web服务，此维度通常表示每秒HTTP请求的数量，以请求的性质（例如，静态或动态内容）分隔。 对于流音频系统，此度量可以集中在网络I / O速度或同时会话数上。 对于键值存储系统，此类度量可以是每秒的交易或搜索结果。

失误

这是显式（例如HTTP 500），隐式（例如HTTP 200，但与错误的内容结合）或策略（例如“如果您在一秒钟内记录响应，则任何一秒都是错误”）失败请求的频率。 如果HTTP协议响应代码不足以表示所有故障情况，则可能需要辅助（内部）协议来检测部分故障。 监视所有这些错误请求可能不会提供足够的信息，而端到端系统测试将帮助您发现正在处理错误的内容。

饱和度

该指标显示您的服务使用情况。 这是一种系统监视措施，用于标识最有限的资源（例如，在内存有限的系统中，它显示内存，在I / O限制的系统中，显示I / O的数量）。 请注意，许多系统在达到100％利用率之前会降低性能，因此有一个使用目的很重要。

在复杂的系统中，可以通过测量更高级别的负载来补充饱和度：您的服务是否可以正确处理双重流量，仅处理比当前多10％的流量或处理比目前少的流量？ 对于没有更改请求复杂性的参数的简单服务（例如，“不给我”或“我需要一个唯一的单调整数”），这些服务很少更改其配置，那么负载测试的静态值可能就足够了。在上一段中讨论过，大多数服务应使用间接信号，例如CPU利用率或网络带宽，这些信号具有已知的上限。 延迟增加通常是饱和的主要指标。 在一个小窗口（例如一分钟）内测量第99个百分位响应时间可以给出非常早的饱和信号。

最后，饱和度还与即将饱和的预测相关联，例如：“看起来您的数据库将在4小时内填满硬盘驱动器。”

如果您测量所有四个黄金信号，并且其中一个度量标准出现问题（或者在饱和的情况下几乎是问题），请通知该人员，您的服务将受到或多或少的监控。

对尾巴的焦虑（或仪器和性能）

从头开始创建监视系统时，很容易基于平均值来开发系统：平均值，平均延迟，CPU节点的平均利用率或平均数据库占用率。 最后两个示例的危险是显而易见的：以非常不可预测的方式处理处理器和数据库。 延迟也是如此。 如果您以每秒1000个请求的速度平均延迟100毫秒运行Web服务，则1％的请求可能需要5秒钟。 如果用户依赖于这些Web服务中的几个，则一个后端的第99个百分点很容易成为接口响应时间的中位数。

区分缓慢的平均查询和非常缓慢的“尾部”查询的最简单方法是收集以统计信息（一种适合的用于显示直方图的工具）表示的查询维度，而不是实际的延迟：服务处理了多少个请求，这些请求的时间介于0毫秒到10 ms，10 ms到30 ms之间，30 ms到100 ms之间，100 ms到300 ms之间，等等。近似直方图扩展直方图边界（近似系数为3）通常是一种可视化查询分布的简单方法。

选择正确的详细程度进行测量

系统的不同元素必须以不同的详细程度进行测量。 例如：

• 在特定时间间隔内监视CPU负载的利用率将不会显示会导致高延迟的长期异常值。
• 另一方面，对于每年停机时间不超过9个小时（每年正常运行时间的99.9％）的Web服务，检查HTTP响应是否超过200分钟（每分钟一次或两次）可能会变得不必要地频繁。
• 同样，可能不需要每1-2分钟检查一次硬盘可用空间是否达到99.9％的可用性。

请注意如何构造尺寸的粒度。每秒收集一次CPU负载的频率可以提供有趣的数据，但是这种频繁的测量对于收集，存储和分析而言可能非常昂贵。如果监视目标要求较高的粒度并且不需要较高的响应速度，则可以通过在服务器上设置度量标准收集，然后设置外部系统来收集和聚合这些度量标准来降低这些成本。您可以：

1. 每秒测量一次CPU利用率。
2. 将细节修剪到5％。
3. 每分钟汇总指标。

该策略将允许以高粒度收集数据，而不会经历高分析和存储开销。

尽可能简单，但不容易

彼此施加不同的要求可能会导致监视系统非常复杂。例如，您的系统可能具有以下复杂元素：

• 根据不同的阈值，针对各种不同的指标，以不同的百分比针对处理请求的延迟发出警报。
• 编写其他代码以检测和识别可能的原因。
• 为每种可能的问题原因创建相关的仪表板。

潜在并发症的根源永无止境。像所有软件系统一样，监控可能变得非常复杂，以至于变得脆弱且难以更改和维护。

因此，请设计您的监视系统以尽可能简化它。选择要跟踪的内容时，请记住以下几点：

• 最常捕获实际事件的规则应尽可能简单，可预测和可靠。
• , , (, SRE), .
• , , - - , .

在Google，指标的基本收集和汇总，以及警报和仪表板相结合，可以作为一个相对独立的系统正常工作（实际上，Google监控系统分为几个子系统，但是通常人们都知道这些子系统的各个方面）。将监视与检查复杂系统的其他方法结合起来可能很诱人：详细的系统分析，过程调试，跟踪有关异常或故障的详细信息，负载测试，收集和分析日志或检查流量。尽管这些东西大多数都具有基本监视的共同特征，但将它们混合在一起会导致创建复杂而脆弱的系统的结果过多。与软件开发的许多其他方面一样，对各种系统的支持清晰，简单，松散耦合的集成点是一种更好的策略（例如，使用Web API以可以长时间保持不变的格式检索摘要数据）。

将原则联系在一起

本章讨论的原则可以集成到Google SRE团队认可和尊重的监视和警报哲学中。坚持这种监视原则是可取的；它是创建或修改警报方法的一个很好的起点，并且可以帮助向运营服务提出正确的问题，而不管您的组织规模或服务或系统的复杂性如何。

通过询问以下问题来创建监视和警报规则时，可以避免误报和不必要的警报：

• 此规则是否可以检测到紧急情况下无法检测到的系统状态，因此需要采取措施并不可避免地影响用户？
• , , ? ?
• , ? , , , - , ?
• ? ? ? ?
• , ?

这些问题反映了警报和警报系统的基本原理：

• 每次收到警报，我都必须紧急响应。我每天可以紧急反应几次，然后再感到疲倦。
• 每个警报应相关。
• 对警报的每个响应都需要人工干预。如果警报可以自动处理，则不会出现。
• 警报应与以前不存在的新问题或事件有关。

这种方法消除了某些差异：如果通知满足前四个条件，则通知是从White-box监视系统还是Black-Box发送都是无关紧要的。这种方法还加强了某些差异：在识别症状方面比在原因上花费更多的精力；说到原因，您只需要担心不可避免的原因。

长期监控

在当今的生产环境中，监视系统通过不断变化的软件体系结构，负载特性和目标性能来跟踪不断发展的生产系统。当前难以自动化的警报可能会频繁发生，甚至值得解决。在这一点上，应该找到并消除问题的根本原因。如果没有这样的许可，则对通知的响应需要完全自动化。

重要的是，在制定监控决策时要牢记长期目标。今天执行的每个警告都会使人无法明天改进系统，因此，从长期来看，改进监视系统所需的时间通常会使生产系统的可用性或生产率下降。让我们看两个说明这种现象的例子。

Bigtable SRE：警报历史记录

Google的内部基础结构通常是根据服务水平（SLO）提供和衡量的。许多年前，Bigtable的SLO服务基于模拟工作客户的综合交易的平均性能。由于Bigtable的问题以及数据存储堆栈的较低级别，平均性能是由“大”尾巴造成的：最差的5％请求通常比其余请求慢得多。

电子邮件通知接近SLO阈值时发送，并且在超过SLO时向信使发送警报。两种警报的发送频率都足够高，从而浪费了无法接受的工程时间：团队花费了大量时间来解析警报，以找到一些真正相关的警报。我们经常错过实际上影响用户的问题，因为只有某些警报专门针对此问题。由于基础结构中的可理解问题，许多警报不是紧急的，并且是以标准方式制定的，或者根本没有处理。

为了解决这种情况，团队采取了三管齐下的方法：在努力提高Bigtable的绩效的同时，我们暂时将第75个百分位数设置为我们的SLO目标，以延迟对请求的响应。我们还关闭了电子邮件警报，因为其中有太多警报，以致无法花费时间来诊断它们。

这种策略使我们可以休息一下，开始解决Bigtable和较低级别数据存储堆栈中的长期问题，而不是不断解决战术问题。当工程师不会受到警报的不断攻击时，他们实际上可以完成这项工作。最终，处理通知的暂时延迟使我们能够提高服务质量。

Gmail：人们可预测的，算法化的响应

从一开始，Gmail就建立在经过修改的Workqueue流程控制系统上，该系统是为批量处理搜索索引片段而创建的。工作队列适应了长期存在的进程，随后又应用于Gmail，但是事实证明，不透明的调度程序代码中的一些错误很难解决。

当时，Gmail监视的结构是这样的：当使用Workqueue取消单个任务时，便会触发警报。这种方法并不理想，因为即使在那时，Gmail仍执行成千上万的任务，每个任务只提供给我们百分之一的用户。我们确保Gmail用户具有良好的用户界面，但要制定出如此多的警报是无法实现的。

为了解决此问题，Gmail SRE创建了一个工具，该工具可帮助尽可能最佳地调试计划程序，以最大程度地减少对用户的影响。团队讨论了是否有必要从发现问题到解决问题直到找到长期解决方案的整个周期自动化，但是其中一些人担心这样的解决方案会延迟问题的真正纠正。

这种紧张关系在团队中很常见，通常反映出对自律的信心不足：虽然一些团队成员想给时间进行正确的修复，但其他人担心最终的修复会被遗忘，而临时的修复会永远持续下去。这个问题值得关注，因为临时解决问题太容易了，而不是必须不断解决问题。经理和技术人员即使在最初的“痛苦”消退时，也通过支持和优先考虑潜在的长期修补程序，在实施长期修补程序中发挥关键作用。

定期定期提醒和算法响应应该是一个危险信号。您的团队不愿意自动执行此类警报，这意味着该团队缺乏信任算法的信心。这是一个需要解决的严重问题。

从长远来看

Bigtable和Gmail示例之间有一个共同的主题：短期可用性和长期可用性之间的竞争。通常，付出很大的努力可以帮助脆弱的系统实现高可用性，但是这条路径通常是短暂的，充满了团队的倦怠和对这个英勇团队的一小部分成员的依赖。

对于系统的长期稳定性而言，可控制的短期可用性降低通常是一项痛苦但具有战略意义的任务。重要的是不要孤立地考虑每个警报，而要考虑警报的总体水平是否会导致一个健康，适当访问的系统，并具有一支可行的团队并具有良好的预后。我们在与管理层的季度报告中分析警报频率的统计信息（通常表示为轮班事故，当事故可能由几个相关事故组成）时，决策者可以不断地表示警报系统的负担和团队的总体状况。

结论

健康监控和警报的途径非常简单明了。它着重于发出警报的问题的症状，并监视原因可以帮助调试问题。尽管必须直接在数据库上监视数据库负载和性能，但监视症状越容易，控制堆栈上的位置就越高。电子邮件通知的好处非常有限，并且往往容易成为噪音。相反，您应该使用仪表板来监视所有通过电子邮件发送的当前问题。仪表板也可以与事件日志配对以分析历史关联。

从长远来看，有必要成功地完成有关症状和不可避免的实际问题的警报轮换，调整目标以确保监视支持快速诊断。

感谢您阅读译文至最后。订阅有关监控@monitorim_it的电报频道和Medium上的博客。