监控SRE的黄金信号.docxVIP

监控SRE的黄金信号 目前没有明确的协议，但有以下当今金色信号的三大次要列表： 取自Google SRE的书籍：延迟，流量，错误，饱和度 USE方法（来自Brendan Gregg）：利用率，饱和度，错误 RED方法（来自Tom Wilkie）：速率，错误和持续时间 你可以看到有些是堆叠的。USE是关于具有内部视图的资源，而RED则是关于恳求和实际工作的外部视图。 在本文中，我们将关注由五个信号组成的超 集： 恳求率 - 恳求率，恳求/秒。 错误率 - 错误率，误差/秒。 延迟 - 响应时间，包括队列/等待时间，以毫秒为单位。 饱和度 - 某些东西的超负荷程度如何，直接通过诸如队列深度（或有时并发）之类的东西来衡量。当系统饱和时变为非零。 利用率 - 资源或系统的繁忙程度。通常表示0-100％，对猜测最有用（饱和度通常对警报更有用）。 饱和度和利用率通常是最难获得的，但它们往往是搜索当前和将来问题最有价值的。 我们应当如何处理我们的信号？ 这些是“黄金”信号的关键缘由之一是，他们试图测量直接系统中影响最终用户和工作生产部分的东西 - 它们是对重要事情的直接测量。 这意味着它们比较直接的测量（如CPU，RAM，网络，复制延迟和其他等等若干事情）更有用。 我们以几种方式使用金色信号： 警报 - 告知我们什么时候消灭问题。 疑问解答 - 挂念我们找到并处理问题。 调整和容量规划 - 挂念我们让事情变得更好。 首先要关注的一个方面是如何在这些信号上进行警报。 大体上，您可以也应当对这些信号使用当前的警报方法，由于它们比通常受监视的CPU，RAM和其他较低级别的指示器更有用。获得数据后，观看一段时间，然后开头在正常工作流程中添加基本警报，以查看这些信号如何影响您的系统。 但是，金色信号也很难警报，由于它们不适合传统的静态警报阈值，比如高CPU使用率、低可用内存或低磁盘空间。静态阈值很有用，但很难设置好且简约产生很多警报乐音，任何操作人员（以及任何与他们待在一起的人）都会这么跟你说。 但无论如何，还是要从静态警报开头着手，但是要将阈值设置为可以确定某些特别或错误的阈值，例如，延迟时间超过10秒，长队列，错误率高于每秒几个。 假如您使用静态警报，请不要遗忘下限警报，例如每秒接近零恳求或延迟，由于这通常意味着消灭问题，即便在凌晨3点，流量较轻时也是如此。 你是平均数还是百分数？ 基本警报通常使用平均值与某个阈值进行比较，但是使用中值不会像使用大/小特别值的那么敏感，假如您的监控系统能够这样做的话。这将削减错误警报。 百分比更好。例如，您可以在95%的延迟上警报，这是一个格外好的衡量不良用户体验的方法。假如95%是好的，那么大多数人都是好的。你会经常震惊怎样你的百分比那么蹩脚。 这是一个特别，还是只是个偶然大事？ 抱负情况下，您现在就可以开头对您的金色信号使用特别检测。这对于捕获非高峰问题或格外低的度量值尤其有用，例如当您的Web上的恳求速率凌晨3点比正常情况高5倍或在半夜由于网络问题降至零时。此外，特别检测允许更紧密的警戒带，所以您可以比静态阈值（它必需相当宽以避开错误警报）更快地发觉问题。 但是，特别检测可能具有挑战性，由于甚至很少有本地监控处理方案可以实现这一点。这也相当新和难以调整（特殊是在金色信号中常见的“季节性”和趋势）。支持特别检测的工具包括一些SaaS /云监控处理方案，如DataDog或SignalFX，以及Prometheus或InfluxDB等本地工具。 无论您的工具是什么，假如您想更好地了解特别检测带来的各种选项、算法和挑战，您应当阅读Baron Schwartz的“ 监测特别检测”一书。 我可以看到你？ 除了警报之外，您还应当可视化这些信号。尝试将一个给定服务的全部信号集中在一个页面上，以便您可以准时在视觉上对其建立关联关系，以查看错误率与延迟或恳求速率以及其他信号有怎样的关联性。以下是Datadog的一个例子： 您还可以使用标记/大事丰富您的目标，例如部署，自动缩放大事，重新启动等。抱负情况下，将全部这些度量标准显示在系统图上，以查看服务是如何关联的，以及在哪里较低级别的延迟或错误可能会影响较高级别。 修复我，修复你 关于警报的最终要留意的是，我发觉SRE金色信号警报更具挑战性，由于它们是很少直接暴露在警报中的潜在问题的症状。例如，低级别服务中的单个高延迟问题很简约导致整个系统消灭很多延迟和错误警报。 这通常意味着工程师必需拥有更多的系统学问，并且能够更深化地挖掘问题，而这些问题很简约消灭在任何一个服务或资源中。 即便对于基本的高CPU或低RAM问题，工程师总是必需连接全部点对警报进行深化挖掘。但是金色的信号通常愈加笼统，并且很简约拥有它们。 侥幸的是，金色信号通过为每个服务和堆栈的每一层供应明确的度量标准供应挂念。