sre8 sre10_监控SRE的黄金信号

sre8 sre10

重要要点

• 黄金信号对于运营团队监视其系统并发现问题至关重要。
• 当我们转向微服务和容器时，这些信号尤为重要，在这些服务和容器中，更多的功能（包括第三方）分布得越来越薄。
• 有许多指标需要监控，但行业经验表明，这5个指标：速率，错误，延迟，饱和度和利用率，实际上包含了您需要了解发生的一切以及发生在哪里的所有信息。
• 获取这些信号非常具有挑战性，并且会因可用的服务和工具而异。
• 这些信号最有效地用作异常检测的一部分，以查找异常模式，因为这些指标会随时间和日期而变化很大。

如今，黄金信号越来越受欢迎，部分原因是网站可靠性工程（SRE）的兴起以及相关的Google图书以及有关改善网站 ， 性能和监控的各种博客 。

监视黄金信号很重要，但是关于如何实际监视和使用它们的内容很少。 本文概述了什么是黄金信号，以及如何在各种常见服务的上下文中获取和使用它们。

什么是黄金信号？

目前尚无最终协议，但这是当今黄金信号的三个主要清单：

• 来自Google SRE的书 ：延迟，流量，错误，饱和度
• USE方法 （来自Brendan Gregg）：使用率，饱和度，错误
• RED方法 （来自Tom Wilkie）：速率，错误和持续时间

您可以看到重叠。 USE是具有内部视图的资源，而RED是具有外部视图的请求和实际工作。

在本文中，我们将重点介绍由五个信号组成的超集：

• 请求速率 -请求速率，以请求/秒为单位。
• 错误率 —错误率，以错误/秒为单位。
• 延迟 -响应时间，包括队列/等待时间，以毫秒为单位。
• 饱和度 -某种程度的超载，直接由队列深度（或有时并发）之类的东西来衡量。 当系统饱和时变为非零。
• 利用率 -资源或系统的繁忙程度。 通常表示为0–100％，对预测最有用（饱和度通常对警报更有用）。

饱和度和利用率通常是最难获得的，但对于解决当前和将来的问题，它们通常也是最有价值的。

我们该如何处理信号？

这些是“黄金”信号的主要原因之一是它们试图测量直接影响系统的最终用户和工作量部分的事物，它们是对重要事物的直接测量。

这意味着它们比诸如CPU，RAM，网络，复制滞后和无尽其他事物之类的直接测量更有用。

我们以几种方式使用黄金信号：

• 警报 -告诉我们什么时候出了问题。
• 故障排除 —帮助我们发现并解决问题。
• 调整和容量规划 -帮助我们随着时间的推移使事情变得更好。

首先要关注的是如何对这些信号发出警报。

大致上，您可以并且应该对这些信号使用当前的警报方法，因为它们比通常监视的CPU，RAM和其他较低级别的指示器更有用。 获得数据后，观察一段时间，然后开始将基本警报添加到正常工作流程中，以查看这些信号如何影响您的系统。

但是，黄金信号也更难以发出警报，因为它们不符合传统的静态警报阈值，并且CPU使用率高，可用内存不足或磁盘空间不足。 静态阈值可以工作，但是很难设置好并产生大量警报噪音，正如任何操作人员（以及与之生活在一起的任何人）都会告诉您的那样。

无论如何，从静态警报开始，但是将阈值设置为我们可以肯定某些异常或错误的水平，例如，超过10秒的等待时间，较长的队列，每秒几秒钟的错误率。

如果您使用静态警报，请不要忘记下限警报，例如每秒接近零的请求或延迟，因为这通常表示出了问题，即使在流量很小的凌晨3点也是如此。

您是平均还是百分位数？

基本警报通常使用平均值与某个阈值进行比较，但是-如果您的监控系统可以做到-则使用中间值代替，该中间值对大/小离群值不太敏感。 这将减少错误警报。

百分位数甚至更好。 例如，您可以警告95％的延迟，这是对不良用户体验的更好度量。 如果第95个百分点很好，那么大多数人都很好。 您的百​​分位数有多糟糕会经常使您感到震惊。

您是反常还是怪异？

理想情况下，您可以对黄金信号开始使用异常检测。 这对于捕获非高峰问题或异常低的度量标准值特别有用，例如，当您凌晨3点的Web请求速率比正常高5倍，或者由于网络问题而在中午降至零时。 此外，异常检测允许更紧密的警报范围，因此您发现问题的速度要比使用静态阈值（该阈值必须足够宽才能避免错误警报）快得多。

但是，异常检测可能具有挑战性，因为几乎没有本地监控解决方案可以做到这一点。 这也很新，很难调优（尤其是黄金信号中常见的“季节性”和趋势）。 很好地支持异常检测的工具包括一些SaaS /云监控解决方案，例如DataDog或SignalFX，以及本地工具，例如Prometheus或InfluxDB。

无论使用哪种工具，如果您想更好地了解异常检测所带来的各种选项，算法和挑战，都应该阅读Baron Schwartz的有关异常检测的书 用于监视 。

我可以看到你？

除了警报之外，您还应该可视化这些信号。 尝试将所有给定服务的信号汇总在一页上，以便您可以在视觉上及时将它们关联起来，以查看错误率与延迟或请求率以及其他信号之间的关系。 这是Datadog的示例：

您还可以使用标记/事件（例如部署，自动扩展事件，重新启动等）来丰富指标。 理想情况下，将所有这些指标显示在系统图上，以查看服务之间的关系以及较低级别的延迟或错误可能会影响较高级别的位置。

修复我，修复你

作为有关警报的最后说明，我发现SRE黄金信号警报响应起来更具挑战性，因为它们是潜在问题的症状，很少会直接被警报暴露。 例如，低级服务上的一个高延迟问题很容易在整个系统上引起许多延迟和错误警报。

这通常意味着工程师必须具有更多的系统知识，并且必须更擅长于深入研究问题，而这些问题很容易存在于十几种服务或资源中。

工程师始终必须将所有问题都联系起来并挖掘警报下方的内容，即使是基本的高CPU或低RAM问题。 但是，黄金信号通常更加抽象，很容易拥有大量信号。

幸运的是，黄金信号通过在每个服务和堆栈的每个层上提供清晰的指标来提供帮助。 这有助于确定哪些服务最有可能导致问题（尤其是如果您具有准确的依存关系信息），以及因此将精力集中在什么地方。

现在，让我们看一下如何从通用服务中获取黄金信号数据。

从多个服务获取数据

以可用的方式获取此数据存在一些细微差别和挑战，并且出于空间的考虑，下面的元素已得到了一些简化。 还要注意，在某些情况下，当您使用基于计数器的指标（例如网络字节，日志行，总请求数和其他指标）时，您必须进行自己的处理，例如增量计算（每秒变化）（大多数监视系统会自动执行此操作）。

负载均衡器的黄金信号

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

当前有几种流行的负载均衡器正在使用，因此我们将介绍三种最常见的负载均衡器： HAP r oxy ， AWS ELB和AWS ALB 。

负载均衡器前端和后端

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

另外，正如您将在下面看到的那样，负载均衡器通常具有比从Web /应用程序服务器本身获得的更好的后端数据，以用于各种Web /应用程序服务器。 因此，您可以选择基于哪个更易于监视。

HAProxy

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

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

• 请求速率 -使用REQ_TOT并进行增量处理以获取速率。 对服务器使用RATE（尽管仅在最后一秒内使用）。
• 错误率 -使用响应错误ERESP，这意味着后端错误。 这是一个计数器，因此您必须对其进行增量处理。 您还可以在每个后端服务器上获取此信息。 您还可以获得对任何系统都至关重要的HTTP 5xx错误计数。
• 延迟 -使用响应时间RTIME（每个后端），该响应时间计算最近1024个请求的平均值。 每个服务器也可用。
• 饱和 —使用排队的请求数QCUR。 应该为零，因此请提高警惕。
• 利用率 -这对HAProxy没什么用，因为它很难衡量，并且在大多数系统上，HAProxy的容量远远超过了后端系统。 因此，几乎不可能过载。

AWS ELB和ALB

AWS Elastic Load Balancing和Application Load Balancing服务的所有数据点均通过CloudWatch提供。 如果对ELB / ALB信号进行百分位数和统计，请确保仔细阅读文档的“ Classic Load Balancer指标的统计”部分。

ELB指标可用于整个ELB，但不适用于每个后端组或服务器。 ALB数据非常相似，但可用数据更多，度量标准名称也有所不同。 整个ALB和目标组（通过维度过滤）都可以使用度量标准，您可以在其中获取后端服务器的数据，而不必直接监视Web /应用程序服务器。 每个服务器的数据都无法从ALB中获得（尽管您可以按可用区域进行过滤，如果每个可用区域中只有一个目标后端服务器，则按可用服务器进行过滤）。

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

• 请求速率 -每秒使用的请求数，以总和（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：平均值（延迟）

ALB：平均值（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。 见数据 d OG的 Apache有用的指南了解更多详情。
• Nginx —启用stub_status_module。 有关更多详细信息，请参见DataDog的 有用的 Nginx指南 。

启用记录

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

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

指标的日志处理

延迟和其他关键指标只能从日志中获取，这些日志难以读取，解析和汇总。 本节介绍如何最好地对各种服务器执行此操作。

HTTP日志工具很多，但是它们无法计算出黄金信号-我们需要能够读取和汇总日志的工具。 ELK堆栈可以做到这一点（ Splunk ， Sumologic ， Log z等），也可以通过详细的汇总查询来查询响应时间，状态计数等。当今大多数SaaS监视工具（例如DataDog ）也可以提取这些内容。

诸如Zabbix之类的传统监视系统无法轻松做到这一点，尤其是当我们需要日志聚合指标而不是实际的日志行时。 理想情况下，您可以找到本机支持Web服务器日志指标的监视系统或工具。

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

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

Apache-Apache提供了Total Accesss，您需要对Total Accesss进行增量处理以每秒获取请求（只是当前指标与最后一个指标之间的差，除以它们之间的秒数，例如（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，没有良好的外部信号，只有Apache状态页和Web服务器上一节中所述的日志。

对于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，我们的信号是：

• Request Rate （ 请求速率） —除了读取访问日志并每秒聚合成请求之外，没有其他直接方法。
• 错误率 -每秒在错误日志中计数php错误（PHP-FPM错误日志没有任何指标或错误信息）。
• 延迟 -从PHP-FPM访问日志中获取响应时间并取平均值。
• 饱和度 —监视“侦听队列”，因为当没有更多的FPM进程可用时，它将不为零。 这意味着它将饱和。
• 利用率 —使用监视系统的进程计数器监视使用中的FPM进程（“活动进程”），并与FPM配置中配置的最大进程进行比较。

Java

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

Tomcat信号是：

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

Ruby

在“乘客”下运行的Ruby提供了一个“乘客状态”页面，可以查询该页面以获取关键指标。

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

• 请求速率-获取每个“应用程序组”的“已处理”计数，并进行增量处理以计算每秒请求。
• 错误率-由于旅客没有单独的错误日志，因此没有明显的方法来获取此信息。
• 延迟-您需要从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的黄金信号的复杂性因您所运行的版本以及您自己运行MySQL还是使用云服务（如AWS RDS或Aurora）而异。

下面的一切都应该适用于基于MySQL的AWS RDS服务，只要性能模式被激活-必须在通过您的AWS RDS把这个 我 nstance p arameter 摹 roup和重新启动数据库。

对于AWS Aurora，CloudWatch可以提供您所需的一切 。

对于MySQL，我们的信号是：

• 请求速率 -每秒查询量，最容易由MySQL状态变量com_select，com_insert，com_update，com_delete和Qcache_hits的总和来衡量，

然后进行增量处理以每秒获取查询。

这是一个SQL代码段，用于检索所有已执行查询的总和：

SELECT sum（变量值）

从information_schema.global_status

在哪里variable_name IN（“ com_select”，“ com_update”，“ com_delete”，“ com_insert”，“ qcache_hits”）；

• 错误率 -从性能模式中获取全局错误计数，然后执行增量

处理中

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

SELECT sum（sum_errors）AS query_count

从performance_schema.events_statements_summary_by_user_by_event_name

在哪里event_name IN（'statement / sql / select'，'statement / sql / insert'，'statement / sql /

更新”，“语句/ sql /删除”）；

• 延迟 -我们可以从性能模式中获取延迟。 为了获得等待时间，我们使用两个语句SELECT和TRUNCATE，因为我们必须在两次读取之间截断表：

选择（avg_timer_wait）/ 1e9 AS avg_latency_ms FROM

performance_schema.events_statements_summary_global_by_event_name

WHERE event_name ='statement / sql / select';

截断表

performance_schema.events_statements_summary_global_by_event_name;

• 饱和度 -这很难实现。 最简单的方法是监视正在运行的线程并发出警报

当急剧增加时。 这是一个瞬时测量，因此您应该在几个较短的监视时间间隔内对其求平均值。

SELECT sum（变量值）

从information_schema.global_status

WHERE variable_name =“ THREADS_RUNNING”；

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

• 利用率 —直接从操作系统监视CPU和I / O的利用率。 在AWS RDS上，您还可以从CloudWatch获取CPUUtilization。

操作系统的黄金信号

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

Linux的黄金信号

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

即使您没有对这些事情提出警告，它们也会为观察到的高级指标变化提供有价值的细节。 例如，如果MySQL延迟突然增加-SQL，数据或底层I / O系统是否发生了变化？

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

中央处理器

对于CPU，唯一的真实信号是利用率和饱和度，因为错误，延迟和请求不是很相关：

• 饱和度 -我们希望CPU [R 未 q ueue长度，成为高于零，当进程必须等待CPU是可用的。 很难获得准确的测量结果。

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

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

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

CPU STE 人比例也表示CPU饱和。 对于运行队列不太准确的单线程负载（例如HAProxy或Node.js），它也很有用。

• 利用率 -我们需要CPU百分比，但这还需要一点数学运算，因此您需要将CPU百分比计算为：

用户+尼斯+系统+（可能）偷

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

对于容器来说， 饱和度和利用率 更难测量 。 一种获得饱和的简单方法是使用nr_throttled指标读取每个容器的/ proc文件系统和cpu.stat文件，该度量将在每次容器受到CPU限制时增加。 Delta可以获取节流/秒，这是在Docker告诉您您使用过多的CPU和节流时发生的。

磁盘使用情况

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

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

结论

由于许多服务仍缺乏监控，或者它们缺乏公开正确的指标，因此，黄金信号是一个丰富而有趣的探索领域。

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

翻译自: https://www.infoq.com/articles/monitoring-SRE-golden-signals/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

sre8 sre10