监控 SRE 的黄金信号

关键要点

• 金牌信号对于运营团队监控其系统和发现问题至关重要。
• 随着我们转向微服务和容器，这些信号变得尤为重要，其中包括第三方在内的更多功能更加分散。
• 需要监测的指标有许多，但行业经验表明，包括速率，错误，延迟，饱和度和利用率这 5 个指标几乎包含了所有需要了解到底怎么回事的相关信息。
• 获取这些信号非常具有挑战性，通过有效的服务和工具可以带来很多改变。
• 这些信号作为异常检测（寻找不寻常的模式）的一部分最为有效，因为这些指标会随时间和日期的变化而产生很大的变化。

金色信号现在越来越受欢迎，部分原因是网站可靠性工程（SRE）的兴起，以及 Google 相关的书籍以及各行各业的人就提高网站、性能和监控能力的博客。

监测黄金信号很重要，但关于如何实际监测和使用它们的文章并不多。本文概述了什么是金色信号，以及如何在各种常见服务中获取和使用它们。

什么是金色信号？

目前没有明确的协议，但有以下当今金色信号的三大主要列表：

• 取自 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 问题，工程师总是必须连接所有点对警报进行深入挖掘。但是金色的信号通常更加抽象，并且很容易拥有它们。

幸运的是，金色信号通过为每个服务和堆栈的每一层提供明确的度量标准提供帮助。这有助于确定哪些服务最有可能导致问题（尤其是如果您拥有准确的依赖信息），从而集中精力处理它。

现在，我们来看看如何从常用服务中获取黄金信号数据。

从多个服务获取数据

以可用的方式在感兴趣的领域获取这些数据存在一些细微差别和挑战，下面的元素已经被简化了一些。还要注意，在某些情况下，当您使用基于计数器的指标（如网络字节数，日志行数，总请求数和其他数据）时，您必须自行处理，如差值计算（每秒更改一次）（大多数监测系统将自动执行此操作）。

负载均衡器的黄金信号

负载平衡器是大多数现代系统的关键组件，通常在应用程序之前，但也越来越多地在系统内部，支持容器，套接字服务，数据库等等。

目前有几种流行的负载均衡器，因此我们将涵盖三种最常见的负载均衡器： HAProxy ， AWS ELB 和 AWS ALB 。

负载均衡器前端和后端

负载均衡器具有前端和后端，通常每个都有几个。根据您的体系结构，您可以使用所有这些的总和，或者可以为各种服务分解信号以获取更多详细信息。

另外，正如您将在下面看到的，负载均衡器通常拥有比 Web / 应用服务器本身更好的各种 Web / 应用服务器的后端数据。所以你可以根据哪个更容易监控来选择。

HAProxy

HAProxy 数据采用 CSV 格式，可以通过三种方式访问​​：CSV，CLI 和 unix 套接字。

HAProxy 金色信号（大写字母引用官方 HAProxy 变量名称）可以按如下方式检索：

• 请求率 - 使用 REQ_TOT 并进行增量处理以获得比率。服务器的利用率（尽管这只是在最后一秒）。
• 错误率 - 使用响应错误 ERESP，这意味着后端错误。这是一个计数器，所以你必须对它进行增量处理。您也可以通过后端服务器获取此信息。您还可以获得对任何系统都至关重要的 HTTP 5xx 错误计数。
• 延迟 - 使用响应时间 RTIME（每个后端），它计算最近 1024 次请求的平均值。每台服务器也可用。
• 饱和度 - 排队请求的使用数量，QCUR。应该是零，如果更高则警报。
• 利用 - 这对 HAProxy 没有用处，因为它很难测量，并且在大多数系统中，HAProxy 的容量远远超过后端系统。因此，超负载几乎是不可能的。

AWS ELB 和 ALB

AWS Elastic Load Balancing 和应用程序负载平衡服务的所有数据点均通过 CloudWatch 提供。如果您对 ELB / ALB 信号做了百分比和统计，请务必仔细阅读文档中经典负载平衡器指标的统计信息部分。

ELB 指标适用于 ELB 整体，但不适用于后端组或服务器。ALB 数据非常相似，具有更多可用数据，而度量标准名称存在一些差异。度量标准由 Target Group（通过 Dimension Filtering）提供，适用于 ALB 整体，您可以从中获取后端服务器的数据，而不是直接监控 Web / 应用程序服务器。来自 ALB 的每个服务器的数据是不可用的（尽管您可以按可用区进行过滤，如果每个可用区只有一个目标后端服务器，则可以按每个服务器进行过滤）。

ALB / ELB 信号（请注意，sum（）部分是指启用这些指标时必须选择的 CloudWatch 统计函数）：

• 请求率 - 使用请求数（sum（RequestCount））除以配置的 CloudWatch 采样时间（1 或 5 分钟）。这将包括出错的请求数。
• 出错率 - 您应该添加三个指标：

ELB：sum（HTTPCode_Backend_5XX），sum（HTTPCode_ELB_5XX）和 sum（BackendConnectionErrors）

ALB：sum（HTTPCode_Backend_5XX），sum（HTTPCode_ELB_5XX）和 sum（TargetConnectionErrorCount）

• 延迟 - 使用平均值：

ELB: average(Latency)

ALB: average(TargetResponseTime)

• 饱和度 - 使用：

ELB：max（SurgeQueueLength）和 sum（SpilloverCount）

ALB：sum（RejectedConnectionCount）

• 利用率 - 没有好的方法来获取 ELB 或 ALB 的利用率数据，因为它们不提供也没有暴露给我们。

Web 服务器的金色信号

从 Web 服务器获取良好信号至关重要。不幸的是，他们通常不直接提供这些数据，当他们这样做时，他们仍然缺乏所有服务器的汇总数据。因此我们剩下三个选择：

1. 使用非常有限的内置状态报告 / 页面
2. 收集并汇总 Web 服务器的 HTTP 日志
3. 利用上游负载均衡器每个服务器的指标（如果可以的话）

最后的选择通常是最好的选择，因为负载平衡器比 Web 服务器具有更好的度量标准。请参阅上面的关于负载平衡黄金信号的部分，以找出其中的原因。

但是，并非所有系统都具有正确的负载均衡类型，并且并非所有监控系统都支持这种类型的后端数据。在这些情况下，我们必须诉诸前两种选择。

下面的方法需不太完善，但仍值得一提，那就是使用状态页面和 HTTP 日志从 Web 服务器检索金色信号。我们将看看两个流行的 Web 服务器：Apache 和 Nginx。

启用状态监控

要获取监控数据，首先需要启用状态监控：

• Apache - 启用 mod_status，包括 ExtendedStatus。有关更多详细信息，请参阅 Datadog 的 实用 Apache 指南。
• Nginx - 启用 stub_status_module。有关更多细节，请参阅有用的 Nginx 指南。

启用日志

您还需要打开日志并通过编辑您的 Web 配置向日志添加响应时间：

• Apache - 将“％D”字段添加到日志定义中（通常位于 httpd.conf 文件末尾），该日志定义了响应时间（以微秒为单位）（如果在 Apache V1.x 上使用“％T”，但注意这仅记录秒，而不是毫秒）。
• Nginx - 添加“$ upstream_response_time”字段以记录后端响应时间（通常在 nginx.conf 文件中）。

针对指标的日志处理

延迟和其他关键指标只能从难以读取，解析和总结的日志中获得。本节介绍如何最好地为各种服务器做到这一点。

虽然 HTTP 日志工具有很多，但他们都无法计算出金色信号 - 我们需要可以读取和汇总日志的工具。 ELK 软件栈可以做到这一点（比如 Splunk、Sumologic、Logz 和其他一样就可以）有详细的响应时间、状态计数等汇总查询，还有当今大多数 SaaS 的监控工具也可以提取这些数据，如 DataDog。

传统的监视系统如 Zabbix 无法如此轻松地完成这项工作，特别是在我们需要日志聚合指标时，而不是实际的日志行。理想情况下，您可以找到一个本机支持 Web 服务器日志指标的监控系统或工具。

对于 Web 服务器，我们可以获得标准状态和监控统计信息：

• 请求率 - 每秒请求数，您可以通过服务器的状态信息获取：

Apache - Apache 提供总访问，您需要进行增量处理以获取每秒请求数（仅为当前度量和最近一次之间的差值除以它们之间的秒数，例如（50800 - 50200）/ 60 秒 = 10 / 秒）。不要使用 Apache 的“每秒请求数”，因为它涉及整个服务器进程的生命周期，可能是几个月或几年，而不是我们感兴趣的最近几分钟。

Nginx - 对请求进行增量处理以每秒获取请求。

• 错误率 - 计算每秒日志的 5xx 错误。
• 延迟 - 根据日志的平均值（或中值）平均请求和响应时间。我建议 1-5 分钟但仍然有响应的采样周期来降低噪音。
• 饱和度 - 不是很有用，因为在大多数系统中几乎不可能使 nginx 饱和，因此它将始终为零，除非每天每台服务器执行数十亿次请求。
• 利用率 - 对 Nginx 无用。对于 Apache，您应该监视 BusyWorkers 与 MaxRequestWorkers，MaxClients 和 ServerLimit 中最小的比例（来自 httpd.conf 文件 - 它们都相互作用，并且取得最小胜利）。还会记录来自日志的 HTTP 503 错误的计数和增量处理（错误 / 秒）。

应用服务器的黄金信号

应用程序服务器是应用程序的主要完成工作的地方。理想情况下，您可以在应用程序服务器上的代码中嵌入可观察性指标。这对错误率和延迟金信号特别有用，因为这将为您直接节省相当多的时间。特别是对于 Golang、Python 和 Node.js 语言，这是唯一的选择。

PHP

PHP 以 Apache mod_php 或 PHP-FPM 运行。对于 mod_php，没有好的外部信号，就像上面的 Web 服务器部分所述的 Apache 状态页面和日志。

对于 PHP-FPM，我们需要能够以 JSON，XML 和 HTML 格式启用状态页面。我们还需要 PHP-FPM 访问、错误和变慢的日志。

错误日志在主 PHP-FPM 配置文件中设置。访问日志很少使用，但将其打开并将格式设置为包含“ ％d ”，即为请求提供服务所需的时间（这在 POOL 配置中完成，通常在 www.conf 中，而不是主 php-fpm .conf 文件）。变慢的日志也在这个文件中设置。有关更多详细信息，请参阅此自助页面。

最后，你应该正确地配置你的PHP 日志。默认情况下，它们加入到Web 服务器的错误日志，与404 和其他HTTP 错误混在一起，使得它们很难分析或汇总。最好在PHP-FPM 池文件（通常为 www.conf ）中添加一个 error_log 重载设置（php_admin_value [error_log]）。

对于 PHP-FPM，我们的信号是：

• 请求率 - 除了读取访问日志并将其聚合为每秒请求数之外，没有可以直接实现此目的的办法。
• 错误率 - 计算每秒错误日志中的 PHP 错误（PHP-FPM 错误日志没有任何度量标准或错误信息）。
• 延迟 - 从 PHP-FPM 访问日志中获取响应时间并对计算其平均值。
• 饱和度 - 监视“监听队列”，因为当没有更多的 FPM 进程可用时，将会成为 non-zero 。这意味着它会饱和。
• 利用率 - 使用监视系统的过程计数器监视正在使用的 FPM 过程（“活动过程”），并与 FPM 配置中配置的最大过程进行比较。

Java

对于 Java，无论是在前端 Web 服务器还是负载均衡器中，都可以更好地监控上游的黄金信号。要直接监视Tomcat ，我们需要配置它进行监视，这意味着确保您在应用程序代码中具有良好的访问/ 错误日志记录，并启用了JMX 支持。在JVM 级别启用JMX 并重新启动Tomcat。出于安全原因要确保它是只读的，将本地计算机的访问权限限制为只读用户。

Tomcat 信号是：

• 请求率 - 通过 JMX，使用 GlobalRequestProcessor 的 requestCount 执行增量处理以获取每秒请求。
• 错误率 - 通过 JMX，使用 GlobalRequestProcessor 的 errorCount 对每秒错误进行增量处理。除非您按处理器过滤，否则包含非 HTTP 错误。
• 延迟 - 通过 JMX 获取 GlobalRequestProcessor 的处理时间，但这是自重启以来的总时间，这个时间除以 requestCount 会拿到长期的平均响应时间，这并不是很有用。理想情况下，您的监控系统或脚本可以在每次抽样时存储这些值，然后获取差异并将其分开。
• 饱和度 - 如果 ThreadPool 的 currentThreadsBusy 值等于 maxThreads 值，则 Tomcat 已饱和并将开始排队。
• 利用率 - 使用 JMX 计算与线程利用率相对应的 currentThreadsBusy / maxThreads。

Ruby

在 Passenger 下运行的 Ruby 提供了一个 passenger-status 页面，可以查询该页面以获取关键指标。

对于 Passenger 或 Apache mod_rails，我们的信号是：

• 请求率 - 获取每个“应用程序组”的“已处理”计数并进行增量处理以计算每秒请求数。
• 错误率 - 没有明显的方式来获得这个，因为 Passenger 没有单独的错误日志。
• 延迟 - 您需要从 Apache / Nginx 访问日志中获取此信息。以上部分请参阅 Web 服务器金色信号。
• 饱和度 - 每个“应用程序组”的“队列中的请求”的非零值将告诉您服务器已饱和。注意：根据文档，不要使用“顶层队列中的请求”，因为它应该始终为零。
• 利用率 - 没有明显的方式来获得这个信号。

Python，Node.js 和 Golang

对于 Python，Node.js 和 Golang，绝大多数情况下应用服务器非常难以监控

人们通过在代码中嵌入度量标准和 / 或使用特殊的包 / APM 工具（如 New Relic ）进行监控。诸如 DataDog 之类的一些服务可以为你做到这一点，但你仍然需要自己编写指标。

对于 Python，Django 有一个可用的 Prometheus 模块。

对于 Node.js，KeyMetrics 和 AppMetrics 提供了一个 API 来获取大部分这些数据。

对于 Golang，有些人使用 Caddy ，它可以通过{latency_ms}字段提供延迟

（类似于 Apache / Nginx），但不提供状态或请求速率数据（尽管有一个 Prometheus 插件有一些指标）。

如果您不使用现有的库 / 工具，则可以始终直接在您的代码中嵌入金色信号：

• 请求率 - 大多数代码是基于每个请求运行的，因此很难在全局范围内正确跟踪，因为代码在每次请求后都会结束并丢失状态。设置全局请求计数器并直接发送该请求计数器的最简单方法。
• 错误率 - 与请求率类似，可能最好使用全局计数器。
• 延迟 - 通过捕获开始和结束时间很容易得到每个请求，但可能需要保持经过时间的计数器以按请求率划分。
• 饱和度 - 从代码中很难获得，因为您没有简单的全局访问权限，全局服务器级别的服务不会跟踪此情况。
• 利用率 - 与饱和度相同。

数据库的金色信号

数据库是大多数在线系统的核心，因此他们的黄金信号对于良好的系统监控和故障排除通常是至关重要的。特别是数据库级别的高延迟通常是网站或应用程序问题的核心原因。

MySQL 的金色信号

根据您运行的版本以及您是自己运行 MySQL 还是使用 AWS RDS 或 Aurora 等云服务，获取 MySQL 的黄金信号的复杂程度各不相同。

下面所说的均适用于基于 MySQL 的 AWS RDS 服务，但必须要先激活性能模式，即通过您的AWS RDS 实例参数组开启这项功能，然后重新启动数据库。

对于AWS Aurora，CloudWatch 可以提供您所需的全部内容。

对于MySQL，我们的信号是：

• 请求率 - 每秒查询数，最容易度量了，合计MySQL 状态变量com_select，com_insert，com_update，com_delete 和Qcache_hits 即可，

然后进行差值处理以获得每秒的查询。

这里有一个SQL 代码片断，它检索所有执行的查询的总和：

SELECT sum(variable_value)

FROM information_schema.global_status

WHERE variable_name IN (“com_select”, “com_update”, “com_delete”, “com_insert”, “qcache_hits”) ;

• 错误率 - 从性能模式中获取全局错误计数，然后执行差值处理

这是一个检索全局错误计数的 SQL 代码片段：

SELECT sum(sum_errors) AS query_count

FROM performance_schema.events_statements_summary_by_user_by_event_name

WHERE event_name IN (‘statement/sql/select’, ‘statement/sql/insert’, ‘statement/sql/

update’, ‘statement/sql/delete’);

• 延迟 - 我们可以从性能模式中获得延迟。为了获得延迟，我们使用两条语句 SELECT 和 TRUNCATE，因为我们必须在读取之间清空表：

SELECT（avg_timer_wait）/ 1e9 AS avg_latency_ms FROM

performance_schema.events_statements_summary_global_by_event_name

WHERE event_name =‘statement / sql / select’;

TRUNCATE TABLE

performance_schema.events_statements_summary_global_by_event_name;

• 饱和度 - 这很难得到。最简单的方法是当出现急剧增长时监视正在运行的线程和警报

。这是一个即时测量，因此您应该在几个较短的监控时间间隔内进行平均。

SELECT sum(variable_value)

FROM information_schema.global_status

WHERE variable_name = “THREADS_RUNNING” ;

如果您拥有 I/O 限制的工作负载，则可以监视 Linux 或 AWS RDS 上的 DiskQueueDepth 中的 I/O 利用率。

• 利用率 - 直接从操作系统监控 CPU 和 I/O 的使用情况。在 AWS RDS 上，您还可以从 CloudWatch 获取 CPU 利用率。

操作系统的金色信号

操作系统当然是任何系统的关键部分，因为它是所有其他服务的基础。因此，监控 CPU，RAM，网络和磁盘以确保良好和可靠的服务通常至关重要。

Linux 的金色信号

应用程序服务依赖于它们底层的硬件，比如 CPU，RAM，网络和 I/O 的核心资源。因此理想情况下，我们可以从 Linux 或任何操作系统获取我们的金色信号。当上层服务对底层资源使用（特别是 I / O）敏感时，这一点尤为重要。

即使您没有对这些事情发出警报，它们也会提供有关更高级别度量标准中观察到的更改的有用详细信息。例如，如果 MySQL 延迟突然上升 - 在 SQL、数据或底层 I/O 系统中是否有变化？

对于 Linux 而言，我们主要对 CPU 和磁盘性能感兴趣，因为 RAM 和现代网络从金色信号的角度来看并不重要，因为它们速度很快，通常不是瓶颈。

中央处理器

对于 CPU 来说，唯一真正的信号是利用率和饱和度，因为错误、延迟和请求并不十分相关：

• 饱和度 - 我们想要 CPU 的运行队列长度，当进程必须等待 CPU 可用时，它会大于零。要获得准确的测量结果很难。

我们可以使用平均负载，但只有在 I / O 非常少的情况下才能使用，例如 Linux 的平均负载

包括 I/O 处理。负载平均值高于 1-（2*CPU 个数）通常被认为是饱和的。真正的 CPU 运行队列数据非常难以获得，因为所有工具只能获得相当嘈杂的瞬时测量数据。

为了解决这个问题，我创建了一个名为 runqstat 的新开源工具（仍在开发中）。

CPU 闲置（steal ）比例也可以表示 CPU 饱和度。对于运行队列不太精确的 HAProxy 或 Node.js 等单线程负载也很有用。

• 利用率 - 我们需要 CPU 百分比，但这也需要一些数学计算，所以您需要计算 CPU 百分比：

User + Nice + System + (probably) Steal

不要添加空闲时间百分比或 iowait 百分比。

对于容器来说，测量饱和度和利用率更加复杂和困难。获得饱和度的一个简单方法是使用 nr_throttled 指标读取每个容器的 / proc 文件系统以及 cpu.stat 文件，每次容器被 CPU 抑制时都会增加该指标。将此值进行差值处理以得到每秒抑制数，在 Docker 告诉您使用的 CPU 太多并且受到抑制时来进行。

磁盘使用情况

对于磁盘使用情况，金色信号来自 iostat 实用程序或直接来自 /proc/diskstats（大多数监控代理都这样做）。获取服务数据所在磁盘的数据。

• 请求速率 - 磁盘速率是磁盘系统的每秒 IO（请求合并之后），在 iostat 实用程序中是 r/s 和 w/s 列。
• 错误率 - 由于磁盘错误非常罕见，因此无用。
• 延迟 - 读取和写入时间，其中 iostat 是平均等待时间（等待）。它包括队列时间，因为当磁盘饱和时，这个时间会急剧增加。如果您有 I/O 敏感服务，您也可以测量 iostat 服务时间。
• 饱和度 - 最好由每个磁盘的 I/O 队列深度来衡量，它由 iostat 中的 aqu-sz 变量提供。
• 利用率 - 这对现代 SSD，云或 SAN 磁盘无用，因为它们并行处理 IO 请求。

结论

金色信号是一个丰富而有趣的探索领域，因为许多服务仍然缺乏监测，或者他们缺乏暴露正确的指标。

即使在云端和 DevOps 革命中，许多主流工具仍然没有真正提供我们有效管理和维护基础设施所需的全部数据，但我们一直在努力使其日臻完善。

关于作者

Steve Mushero 拥有超过 25 年的 IT 和软件经验，主要担任首席技术官或 IT 经理，从纽约到西雅图，硅谷和上海等众多初创公司和大公司。他目前是 OpsStack.io 和 ChinaNetCloud 的首席执行官，该公司是中国第一家也是最大的互联网管理服务提供商。史蒂夫位于上海和硅谷。

查看英文原文： Monitoring SRE’s Golden Signals