SRE（站点可靠性工程）是一种确保 Web 项目可用性的方法。 它被认为是 DevOps 的框架，讨论如何在应用 DevOps 实践中取得成功。 本文的翻译 书籍 来自谷歌。 我自己准备了这个翻译，并依靠自己在理解监控流程方面的经验。 在电报频道 и 我还发布了同一本书中有关服务级别目标的第 4 章的翻译链接。
猫翻译。 享受阅读！
Google 的 SRE 团队拥有创建成功的监控和通知系统的基本原则和最佳实践。 本章提供有关网页访问者可能遇到的问题以及如何解决导致网页难以显示的问题的指导。
确定
没有单一的词汇用于讨论与监控相关的主题。 即使在 Google 上，以下术语也不常用，但我们将列出最常见的解释。
监控
实时收集、处理、聚合和显示系统的定量数据：请求数量和请求类型、错误数量和错误类型、请求处理时间和服务器正常运行时间。
白盒监控
基于内部系统组件显示的指标进行监控，包括日志、Java 虚拟机分析指标或生成内部统计信息的 HTTP 处理程序指标。
黑盒监控
从用户的角度测试应用程序行为。
仪表板
提供服务关键健康指标概述的界面（通常是网页）。 仪表板可能具有过滤器、选择所显示的指标的能力等。该界面被设计为识别对用户最重要的指标。 仪表板还可以为技术支持人员显示信息：请求队列、高优先级错误列表以及给定职责区域的指定工程师。
警报（通知）
旨在由人员通过电子邮件或其他方式接收的通知，这可能是由错误或请求队列的增加触发的。 通知分为：票证、电子邮件警报和即时通讯消息。
根本原因
软件缺陷或人为错误一旦纠正就不应再发生。 问题可能有几个主要原因：流程自动化不足、软件缺陷、应用逻辑阐述不够。 这些因素中的每一个都可能是根本原因，并且每一个都必须被消除。
Node and machine（节点和机器）
可互换术语，指物理服务器、虚拟机或容器上正在运行的应用程序的单个实例。 一台机器可以承载多个服务。 服务可以是：
- 相互连接：例如缓存服务器和Web服务器；
- 单个硬件上不相关的服务：例如，配置系统的代码存储库和向导，例如 или .
推
软件配置的任何更改。
为什么需要监控？
需要监控应用程序的原因有几个：
长期趋势分析
数据库有多大以及增长速度有多快？ 每日用户数量如何变化？
性能对比
与 Ajax DB 2.72 相比，Acme Bucket of Bytes 3.14 上的请求是否更快？ 出现附加节点后，请求缓存效果会好多少？ 与上周相比，网站运行速度是否变慢？
警报（通知）
有些东西坏了，需要有人来修复它。 或者有些东西很快就会坏掉，需要有人尽快检查。
创建仪表板
仪表板应回答基本问题并包含以下内容： ——延迟（latency）、流量（traffic）、错误（errors）和负载大小（saturation）。
进行回顾性分析（调试）
请求处理延迟增加了，但同时还发生了什么？
监控系统可作为商业智能系统的数据源，并有助于安全事件的分析。 由于本书重点关注 SRE 拥有专业知识的工程领域，因此我们不会在这里讨论监控技术。
监控和警报使系统可以在其已发生故障或即将发生故障时告诉您。 当系统无法自动修复时，我们希望有人分析警报，确定问题是否仍然存在，解决问题并确定根本原因。 如果您不审核系统组件，您将永远不会仅仅因为“有些事情似乎有点奇怪”而收到警报。
让员工承受通知的负担是相当浪费员工时间的。 如果员工正在工作，警报会中断工作流程。 如果员工在家，警报会打断个人时间，甚至可能打断睡眠。 当警报发生过于频繁时，员工会浏览、推迟或忽略传入的警报。 他们有时会忽略被噪音事件掩盖的真正警报。 由于噪声事件会妨碍问题的快速诊断和纠正，因此服务中断可能会持续很长时间。 有效的预警系统具有良好的信噪比。
为监控系统设定合理的期望
为复杂的应用程序设置监控本身就是一项复杂的工程任务。 即使拥有重要的收集、显示和警报工具基础设施，由 10-12 名成员组成的 Google SRE 团队通常也包括一两个人，其主要目的是构建和维护监控系统。 随着我们整合和集中监控基础设施，这个数字随着时间的推移而减少，但每个 SRE 团队通常至少有一个人专门负责监控。 我们不得不说，虽然监控系统仪表板看起来非常有趣，但 SRE 团队小心地避免了需要有人查看屏幕来监控问题的情况。
总的来说，谷歌已经转向简单、快速的监控系统和最佳的事后分析工具。 我们避免尝试预测阈值或自动检测根本原因的“神奇”系统。 检测最终用户请求中非预期内容的传感器是唯一的反例； 只要这些传感器保持简单，它们就可以快速检测出严重异常的原因。 使用监控数据的其他格式（例如容量规划或流量预测）更为复杂。 以低采样率（小时或天）进行很长一段时间（数月或数年）的观察将揭示长期趋势。
Google SRE 团队在复杂的依赖层次结构方面取得了不同程度的成功。 我们很少使用诸如“如果我发现数据库很慢，我会收到数据库很慢的警报，否则我会收到网站很慢的警报”之类的规则。 基于依赖关系的规则通常指的是我们系统中不可变的部分，例如用于过滤数据中心用户流量的系统。 例如，“如果配置了数据中心的流量过滤，则不要就处理用户请求的延迟向我发出警报”是来自数据中心的警报的一项通用规则。 Google 很少有团队支持复杂的依赖层次结构，因为我们的基础设施具有恒定的持续重构率。
本章中描述的一些想法仍然具有相关性：总是有机会更快地从症状转向根本原因，尤其是在不断变化的系统中。 因此，虽然本章概述了监控系统的一些目标以及如何实现这些目标，但重要的是监控系统对于团队中的每个人来说都是简单且易于理解的。
同样，为了保持低噪音水平和高信号水平，监控警报资产的方法必须非常简单和可靠。 为人们发出警告的规则应该易于理解并提出明确的问题。
症状与原因
您的监控系统应该回答两个问题：“什么坏了”和“为什么坏了”。
“什么坏了”谈论的是症状，“为什么坏了”谈论的是原因。 下表显示了此类连接的示例。
症状
原因
收到 HTTP 错误 500 或 404
数据库服务器拒绝连接
服务器响应慢
CPU 利用率高或以太网电缆损坏
南极洲的用户收不到猫的 GIF
你的 CDN 讨厌科学家和猫，所以一些 IP 地址最终被列入黑名单
私人内容随处可见
新软件版本的推出使防火墙忘记了所有 ACL，并让每个人都可以进入
“什么”和“为什么”是创建具有最大信号和最小噪声的良好监控系统的一些最重要的构建块。
黑盒与白盒
我们将广泛的白盒监控与针对关键指标的适度黑盒监控相结合。 比较黑盒与白盒的最简单方法是，黑盒以症状为中心，是被动的，而不是主动监控：“系统现在无法正常工作。” 白盒依赖于系统的内部验证能力：事件日志或网络服务器。 因此，白盒允许您检测即将发生的问题、看似重新传输请求的故障等。
请注意，在多层系统中，一个工程师的职责范围内的症状也是另一位工程师的职责范围内的症状。 例如，数据库性能下降。 数据库读取缓慢是检测数据库 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 利用率或平均数据库填充度。 最后两个例子的危险是显而易见的：处理器和数据库的处理方式非常不可预测。 这同样适用于延迟。 如果您运行平均延迟为 100 毫秒、每秒 1000 个请求的 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 响应一次或两次以上可能会过于频繁。
- 同样，每 99,9-1 分钟检查一次硬盘空间是否有 2% 的可用性可能没有必要。
请注意如何构建测量的粒度。 每秒收集一次 CPU 负载可以提供有趣的数据，但这种频繁测量的收集、存储和分析成本可能非常昂贵。 如果您的监控目标需要高粒度且不需要高响应能力，则可以通过在服务器上设置指标收集，然后设置外部系统来收集和聚合这些指标来降低这些成本。 您可以...吗：
- 每秒测量 CPU 负载。
- 将细节减少至 5%。
- 每分钟汇总指标。
此策略将允许您以高粒度收集数据，而不会产生高分析和存储开销。
尽可能简单，但不简单
不同需求的叠加可能会导致非常复杂的监控系统。 例如，您的系统可能具有以下复杂元素：
- 根据请求处理延迟的不同阈值、不同百分位、针对所有类型的不同指标发出警报。
- 编写额外的代码来检测和识别可能的原因。
- 为每个可能的问题原因创建相关的仪表板。
潜在并发症的来源永无止境。 与所有软件系统一样，监控可能变得非常复杂，以至于变得脆弱且难以更改和维护。
因此，设计监控系统时应尽可能简化。 选择跟踪内容时，请记住以下几点：
- 最常捕获真实事件的规则应该尽可能简单、可预测和可靠。
- 应删除不经常执行的数据收集、聚合和警报配置（例如，对于某些 SRE 团队来说，少于季度一次）。
- 收集但未在任何预览仪表板中显示或由任何警报使用的指标是要删除的候选指标。
在谷歌，基本指标的收集和聚合，与警报和仪表板相结合，作为一个相对独立的系统运行良好（谷歌的监控系统实际上分为几个子系统，但人们通常都了解这些子系统的各个方面）。 将监控与其他技术结合起来检查复杂系统可能很诱人：详细的系统分析、进程调试、跟踪异常或故障的详细信息、负载测试、日志收集和分析或流量检查。 虽然大多数这些东西与基本监控有共同点，但将它们混合在一起会导致太多结果并创建一个复杂而脆弱的系统。 与软件开发的许多其他方面一样，通过清晰、简单、松散耦合的集成点支持不同的系统是最佳策略（例如，使用 Web API 以可长期保持一致的格式检索聚合数据） ）。
将原则结合在一起
本章讨论的原则可以合并为 Google SRE 团队认可和遵循的监控和警报理念。 坚持这种监控理念是可取的，是创建或修改警报方法的良好起点，并且可以帮助您提出有关运营职能的正确问题，无论您的组织规模如何或服务或系统的复杂程度如何。
创建监控和警报规则时，询问以下问题可以帮助您避免误报和不必要的警报：
- 此规则是否检测到系统中无法检测到的紧急状态、号召性用语以及不可避免地影响用户的状态？
- 我可以忽略这个警告，因为它是良性的吗？ 我何时以及为什么可以忽略此警告以及如何避免这种情况？
- 此警报是否意味着用户受到负面影响？ 是否存在用户不会受到负面影响的情况，例如通过流量过滤或使用应过滤警报的测试系统时？
- 我可以针对此警报采取行动吗？ 这些措施是紧急还是可以等到早上？ 可以安全地自动化操作吗？ 这一行动是长期解决方案还是短期解决方案？
- 有些人会收到有关此问题的多个警报，那么有没有办法减少警报数量？
这些问题反映了警报和警告系统的基本原理：
- 每次警报到来时，我都必须立即做出反应。 在我感到疲倦之前，我每天可以紧急反应几次。
- 每个警报必须是相关的。
- 对警报的每次响应都必须需要人工干预。 如果通知可以自动处理，那么它应该不会到达。
- 警报应该是关于以前不存在的新问题或事件。
这种方法模糊了某些区别：如果警报满足前面的四个条件，则警报是从白盒还是黑盒监控系统发送并不重要。 这种方法还强化了某些差异：最好花更多的精力来识别症状而不是原因； 当谈到原因时，你只需要担心不可避免的原因。
长期监测
在当今的生产力环境中，监控系统通过不断变化的软件架构、工作负载特征和性能目标来监控不断发展的生产系统。 目前难以自动化的警报可能会变得司空见惯，甚至可能值得解决。 此时，必须有人找到并消除问题的根源； 如果无法实现这种解决方案，则对警报的响应需要完全自动化。
制定监测决策时必须考虑到长期目标，这一点很重要。 今天运行的每个警报都会分散人们对明天改进系统的注意力，因此从长远来看，生产系统的可用性或性能通常会在改进监控系统所需的时间内降低。 让我们看两个例子来说明这一现象。
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 示例有一个共同的主题：短期可用性和长期可用性之间的竞争。 通常，强有力的努力可以帮助脆弱的系统实现高可用性，但这条道路通常是短暂的，充满团队倦怠和对同一英雄团队中少数成员的依赖。
受控的、短期的可用性降低通常是痛苦的，但对于系统的长期稳定性具有战略意义。 重要的是不要孤立地看待每个警报，而是要考虑警报量的总体水平是否会带来健康、可正确访问的系统、可行的团队和良好的预后。 我们在向管理层提交的季度报告中分析警报频率统计数据（通常表示为每个班次的事件，其中一个事件可能包含多个相关事件），使决策者能够持续了解警报系统负载和整体团队健康状况。
结论
健康监控和警报的途径简单明了。 它重点关注触发警报的问题症状，并监控原因以帮助调试问题。 尽管监视数据库的负载和性能应该直接在数据库本身上完成，但您控制的堆栈越高，监视症状就越容易。 电子邮件通知的用处非常有限，并且很容易成为噪音； 相反，您应该使用仪表板来监控触发电子邮件警报的所有当前问题。 仪表板还可以与事件日志配对以分析历史相关性。
从长远来看，有必要成功地轮换有关症状和迫在眉睫的实际问题的警报，调整目标以确保监测支持快速诊断。
感谢您将翻译读到最后。 订阅我的关于监控的电报频道 и .
来源： habr.com