如何检测SRE的黄金信号

站点可靠性工程(SRE)和相关概念最近非常流行，部分原因是著名的Google SRE书和其他人谈到了“黄金信号”，您应该监控这些“黄金信号”，以保持系统在扩展时的快速和可靠。
每个人似乎都同意这些信号很重要，但你实际上如何监测它们？似乎没人多谈这个。
这些信号比传统的CPU或RAM监视更难获得，因为每个服务和资源都有不同的度量、定义，尤其是所需的工具。
微服务、容器和无服务器使获取信号变得更加困难，但仍然值得，因为我们需要这些信号–既要避免传统的警报噪声，又要有效地解决日益复杂的分布式系统的故障。
本系列文章将介绍一些常见服务的信号和实用方法。首先，我们将简要介绍信号本身，然后介绍如何在监控系统中使用它们。
最后，还有一个关于如何监视信号的特定于服务的指南列表，用于负载均衡器、Web和应用程序服务器、DB和缓存服务器、通用Linux等。随着我们不断寻求反馈和更好的方法来获得更好的数据，这个列表和细节可能会随着时间的推移而发展。

SRE信号是什么

有三种常见的清单或方法：

摘自Google SRE一书：延迟、流量、错误和饱和度
使用方法（来自布兰登·格雷格）：利用、饱和和错误
RED方法（来自Tom Wilkie）：速率、错误和持续时间

您可以看到重叠，正如Baron Schwartz在他的监视和可观测性与使用和RED博客中指出的，每种方法的重点不同。他建议，USE是关于内部视图的资源，而RED是关于请求、实际工作以及外部视图（从服务使用者的角度来看）。它们显然是相关的，也是互补的，因为每个服务都要消耗资源来完成工作。
出于我们的目的，我们将关注五个信号的简单超集：

• 速率-请求速率，以请求/秒为单位
• 错误-错误率，以错误/秒为单位
• 延迟-响应时间，包括队列/等待时间，以毫秒为单位。
• 饱和度–某物的重载程度，这与利用率有关，但更直接地由队列深度（有时是并发性）之类的东西来衡量。作为队列度量，当您饱和时，这将变为非零，以前通常不会太多。通常是柜台。
• 利用率-资源或系统有多忙。通常表示为0-100%，对预测最有用（因为饱和度可能更有用）。注意：我们不是使用利用率定律来获得这个值(~费率x服务时间/工人），而是寻找更熟悉的直接度量值。

在这些饱和度和利用率中，通常是最难得到的，充满了假设、警告和计算复杂性–最好把它们当作近似值。然而，它们往往对于找出当前和未来的问题是最有价值的，所以我们忍受并学会爱它们。
所有这些测量都可以被各种事物分割和/或聚合。例如，HTTP可以划分为4xx和5xx错误，就像延迟或速率可以由URL划分一样。
此外，还有更复杂的计算方法。例如，错误的延迟通常低于成功请求，因此如果可以的话，可以将错误排除在延迟之外（通常不能）。
尽管这些拆分或聚合非常有用，但它们不在本文的讨论范围内，因为它们越来越接近度量、事件、高基数分析等。

如何处理

如果你愿意，你可以在本帖的末尾跳过实际的数据收集指南，但我们应该谈谈一旦我们有了这些信号，该如何处理它们。
这些是“黄金”信号的关键原因之一是，它们试图测量直接影响最终用户和系统生产部分的东西–它们是对重要东西的直接测量。
这意味着，在理论上，它们比许多不太直接的测量更好，更有用，例如CPU、RAM、网络、复制延迟和其他无穷无尽的东西（我们应该知道，因为我们经常在每个服务器上监视200多个项目；从来都不是一个好时机）。
我们收集黄金信号有几个原因：

• 警报–有问题时告诉我们
• 疑难解答-帮助我们找到并修复问题
• 调优和容量规划-帮助我们随着时间的推移使事情变得更好

我们这里的重点是警报，以及如何对这些信号进行警报。之后你做什么是在你和你的信号之间。
警报传统上使用静态阈值，在我们心爱的（哈！）Nagios、Zabbix、DataDog等系统。这很有效，但很难设置好，并产生大量警报噪音，因为你（以及任何和你住在一起的人）很可能会敏锐地意识到。
但是，如果必须，根据您的经验和最佳实践，从静态开始。当我们非常确定有什么问题，或者至少有不寻常的情况发生时（例如，95%CPU、延迟超过10秒、队列大小适中、错误率超过每秒几个，等等），这些通常工作得最好
如果使用静态警报，不要忘记下限警报，例如每秒接近零请求或延迟，因为这些通常意味着出错，即使是在流量较少的凌晨3点。

平均数还是百分位数？

这些警报通常使用平均值，但请帮自己一个忙，尽可能使用中值，因为它们对大/小异常值不太敏感。
平均数也有其他问题，正如他们在博客中所指出的那样。不过，平均数/中位数很容易理解、容易获得，而且作为一个信号非常有用，只要你的测量窗口很短（例如1-5分钟）。
更好的是开始考虑百分位数。例如，您可以在第95百分位延迟时发出警报，这是一个更好的衡量对您的用户来说有多糟糕的指标。
然而，百分位数比表面上看起来更复杂，当然，Livid Cortex有一个关于这方面的博客：为什么百分位数不像你想的那样工作，例如，他警告说，在你的测量时间（例如1或5分钟）内，你的系统实际上是在做平均值的百分位数。但它对于提醒仍然有用，如果可以的话，你应该尝试一下（你经常会惊讶于你的百分位数有多糟糕）。

理想情况下，你也可以开始在你闪亮的新金色信号上使用现代异常检测。异常检测对于捕捉非峰值发生或导致异常较低度量值的问题特别有用。此外，它们允许更紧的警报带，因此您可以更早地发现问题（但不会过早地淹没在错误警报中）。
然而，异常检测可能非常具有挑战性，因为很少有现场监控解决方案能够做到这一点（Zabbix不能）。它也是相当新的，仍在发展中，很难调整好（尤其是在我们的黄金信号中“季节性”和趋势如此普遍）。
幸运的是，新的SaaS/云监控解决方案如DataDog、SignalFX等可以做到这一点，新的现场系统如Prometheus和InfluxDB也可以做到这一点。
无论您的异常工具是什么，Baron Schwartz都有一本关于这方面的好书，您应该阅读它来更好地理解各种选项、算法和挑战：用于监视的异常检测。

除了警报之外，您还应该可视化这些信号。Weave Works有一个很好的格式，有两个图表列，Splunk有一个很好的视图。左边是请求和错误率的堆叠图，右边是延迟图。您还可以添加第三个混合饱和度/利用率图。
您还可以使用标记/事件来丰富度量，例如部署、自动缩放事件、重新启动等，并且理想情况下像Netsil那样在系统架构图上显示所有这些度量。

关于警报的最后一点，我们发现SRE Golden Signal警报更难响应，因为它们实际上是警报很少直接暴露的潜在问题的症状。
这通常意味着工程师必须拥有更多的系统知识，并且在深入研究问题上更加熟练，而这些问题很容易存在于十几个服务或资源中的任何一个
工程师总是必须连接所有的点，挖掘警报的下面（或上面），即使是基本的高CPU或低RAM问题。但是黄金信号通常更为抽象，很容易出现大量的黄金信号，即低层服务的单个高延迟问题很容易导致整个系统的大量延迟和错误警报。
Golden Signals帮助解决的一个问题是，我们通常只拥有少数几个服务的有用数据，而前端问题会导致对罪魁祸首的长期追捕。收集每个服务的信号有助于确定哪个服务是最有可能的原因（尤其是如果您有依赖信息），从而确定关注哪里。
就是这样。享受你的信号，因为它们既具有挑战性，也很有趣，可以发现、监控和警觉。

从每个服务获取数据

下面是各种流行服务的附录文章，我们正在努力随着时间的推移添加更多。同样，我们欢迎对这些问题的反馈。
注意：要以一种可用的方式获得这些数据有很多细微差别和挑战，所以在我们平衡清楚和透彻的时候，请先为所有的注释和警告道歉。
还要注意，在某些情况下，您必须进行自己的处理，例如在对基于计数器的度量进行采样时进行增量计算（大多数系统会自动为您进行此操作）。