43

监控SRE的黄金信号

 5 years ago
source link: http://www.infoq.com/cn/articles/monitoring-SRE-golden-signals?amp%3Butm_medium=referral
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

关键要点

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

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

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

什么是金色信号？

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

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

在本文中，我们将关注由五个信号组成的超集：

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

饱和度和利用率通常是最难获得的，但它们往往是搜索当前和未来问题最有价值的。

我们应该如何处理我们的信号？

这些是“黄金”信号的关键原因之一是，他们试图测量直接系统中影响最终用户和工作生产部分的东西 - 它们是对重要事情的直接测量。

这意味着它们比较直接的测量（如CPU，RAM，网络，复制延迟和其他等等若干事情）更有用。

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

  • 警报 - 告诉我们什么时候出现问题。
  • 疑难解答 - 帮助我们找到并解决问题。
  • 调整和容量规划 - 帮助我们让事情变得更好。

首先要关注的一个方面是如何在这些信号上进行警报。

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

但是，金色信号也很难警报，因为它们不适合传统的静态警报阈值，比如高CPU使用率、低可用内存或低磁盘空间。静态阈值很有用，但很难设置好且容易产生很多警报噪音，任何操作人员（以及任何与他们待在一起的人）都会这么跟你说。

但无论如何，还是要从静态警报开始着手，但是要将阈值设置为可以肯定某些异常或错误的阈值，例如，延迟时间超过10秒，长队列，错误率高于每秒几个。

如果您使用静态警报，请不要忘记下限警报，例如每秒接近零请求或延迟，因为这通常意味着出现问题，即使在凌晨3点，流量较轻时也是如此。

你是平均数还是百分数？

基本警报通常使用平均值与某个阈值进行比较，但是使用中值不会像使用大/小异常值的那么敏感，如果您的监控系统能够这样做的话。这将减少错误警报。

百分比更好。例如，您可以在95%的延迟上警报，这是一个非常好的衡量不良用户体验的方法。如果95%是好的，那么大多数人都是好的。你会经常震惊怎么你的百分比那么糟糕。

这是一个异常，还是只是个偶然事件？

理想情况下，您现在就可以开始对您的金色信号使用异常检测。这对于捕捉非高峰问题或非常低的度量值尤其有用，例如当您的Web上的请求速率凌晨3点比正常情况高5倍或在中午由于网络问题降至零时。此外，异常检测允许更紧密的警戒带，所以您可以比静态阈值（它必须相当宽以避免错误警报）更快地发现问题。

但是，异常检测可能具有挑战性，因为甚至很少有本地监控解决方案可以实现这一点。这也相当新和难以调整（特别是在金色信号中常见的“季节性”和趋势）。支持异常检测的工具包括一些SaaS /云监控解决方案，如DataDog或SignalFX，以及Prometheus或InfluxDB等本地工具。

无论您的工具是什么，如果您想更好地了解异常检测带来的各种选项、算法和挑战，您应该阅读Baron Schwartz的“ 监测异常检测”一书。

我可以看到你？

除了警报之外，您还应该可视化这些信号。尝试将一个给定服务的所有信号集中在一个页面上，以便您可以及时在视觉上对其建立关联关系，以查看错误率与延迟或请求速率以及其他信号有怎样的关联性。以下是Datadog的一个例子：

7321-1527958663534.png

您还可以使用标记/事件丰富您的指标，例如部署，自动缩放事件，重新启动等。理想情况下，将所有这些度量标准显示在系统图上，以查看服务是如何关联的，以及在哪里较低级别的延迟或错误可能会影响较高级别。

修复我，修复你

关于警报的最后要注意的是，我发现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。

启用状态监控

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

启用日志

您还需要打开日志并通过编辑您的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革命中，许多主流工具仍然没有真正提供我们有效管理和维护基础设施所需的全部数据，但我们一直在努力使其日臻完善。

关于作者

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

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


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK