Google内部的基础设施通常提供某个SLO（参见第4章），并且伴随有相应的SLO监控。很多年以前，Bigtable SLO是基于某个假想的客户端的平均性能得出的。由于Bigtable 和底层存储技术栈中的一些问题，平均性能受很大的"长尾"所影响∶请求中最差的5%比其他的请求要慢很多倍。 当接近SLO目标的时候，系统会 ...

本章描述的理念整合起来就成为Google SRE广泛接受和遵循的监控与警报设计哲学。虽然这个设计哲学有一定理想性，但是书写和评审某个新警报时可以依赖的好方法。该哲学同时有助于鼓励团队在解决问题时向正确的方向进行。 当为监控系统和警报系统增加新规则时，回答下列问题可以帮助减少误报∶ ● 该 ...

构建监控系统时，很多人都倾向于采用某种量化指标的平均值∶延迟平均值，节点的平均CPU使用率，数据库容量的平均值等。后两个例子中存在的问题是很明显的∶CPU和数据库的利用率可能波动很大，但是同样的道理也适用于延迟。如果某个Web服务每秒处理1000个请求，平均请求延迟为100ms。那么1%的请求可能会 ...

监控系统的4个黄金指标分别是延迟、流量、错误和饱和度（saturation）。如果我们只能监控用户可见系统的 4个指标，那么就应该监控这 4个。 延迟服务处理某个请求所需要的时间。这里区分成功请求和失败请求很重要。例如，某个由于数据库连接丢失或者其他后端问题造成的HTTP 500错误可能延迟很低。计算 ...

监控系统应该解决两个问题∶什么东西出故障了，以及为什么出故障。 "什么东西出故障了"即为现象（symptom）∶"为什么"则代表了原因（可能只是中间原因，并不是根源问题）。表6-1列出了一些现象，以及它们对应的原因。 表6-1∶ 现象与原因的示例 "现象"和"原因"的区分是构建信噪比高的监控系统时最 ...

监控一个复杂的应用程序本身就是一项复杂的工程项目。即使在具有大量现成的基础设施的情况下，标记、收集、显示，以及报警这些工作，通常需要10~12个人组成的标准Google SRE团队中的1~2个人全职进行监控的构建和维护工作。由于我们花了很多精力将通用的监控基础设施进行了改造和集中化，这个数字已经随 ...

监控一个系统有多个原因，包括如下几项。 分析长期趋势数据库目前的数据量，以及增长速度。又例如每日活跃用户的数量增长的速度。 跨时间范围的比较，或者是观察实验组与控制组之间的区别使用Acme Bucket of Bytes2.72 或者Ajax DB3.14（都是虚构的系统名称名字）哪个请求速度更快?增加新节点后 ...

Google的SRE团队在构建监控系统和报警系统方面遵循一些核心思想和最佳实践。本章在决定何时需要人工干预（发出紧急警报）的问题上提供了一些指导意见，同时也讨论了如何应对那些不那么严重的警报。 在讨论监控系统时，目前几乎没有通用的术语。即使在 Google内部，不同的团队也在使用不同的术语，以 ...