监控一个复杂的应用程序本身就是一项复杂的工程项目。即使在具有大量现成的基础设施的情况下，标记、收集、显示，以及报警这些工作，通常需要10~12个人组成的标准Google SRE团队中的1~2个人全职进行监控的构建和维护工作。由于我们花了很多精力将通用的监控基础设施进行了改造和集中化，这个数字已经随着时间下降了。但是目前每个SRE团队一般至少有一个"监控专员"（虽然平时看看流量图表可能很有意思，但是SRE团队通常会小心地避免任何需要某个人"盯着屏幕寻找问题"的情况。）

一般来说，Google趋向于使用简单和快速的监控系统配合高效的工具进行事后分析。我们会避免任何"魔法"系统——例如试图自动学习阈值或者自动检测故障原因的系统。

这里可以举一个反例∶检测最终用户请求速率的意外变化的系统。我们坚持监控系统规则越简单越好，同时要求这些监控规则可以检测某个非常简单、具体，但是严重的异常情况。监控数据的其他用处还包括容量规划、流量预测，用于这些方面的监控规则对错误和稳定性的要求更低，也就可以稍微复杂一些。针对某个试验功能的数据观测，可能时间跨度非常长（数月甚至数年），取样率也很低，这种用途可以容忍一定的错误率，因为这些偶尔出现的错误不会掩盖真正的长期趋势。

Google SRE在应对复杂依赖关系时的成功经验并不多。我们偶尔会使用这样的规则∶"如果我知道数据库目前缓慢，那么发出一条数据库缓慢的警报，否则发出一条网站缓慢的警告"。针对依赖服务的监控规则，一般只用于系统中非常稳定的组件上。例如某个将用户流量从数据中心迁出的系统。"如果数据中心处于'排水状态'（drained），那么不要发出有关延迟的警报"是一个常见的数据中心警报规则。由于Google基础设施的重构速度很快，很少有团队会在监控系统中维护复杂的依赖关系。

本章中讨论到的某些想法还有想象的空间∶从现象到根源问题的定位速度可以更快，尤其是在一个不断改变的系统中。这一章给监控系统设立了一些目标，同时提供了一些达到这些目标的方法。但是监控系统中最重要的一点就是整个"生产故障，人工处理紧急警报，简单定位和深入调试"过程必须要保持非常简单，必须能被团队中任何一个人所理解。

同样的，监控系统信噪比应该很高，发出紧急警报的组件需要非常简单而且可靠。产生警报的监控系统规则应该非常容易理解，同时代表一个清晰的故障场景。

监控一个复杂的应用程序本身就是一项复杂的工程项目。即使在具有大量现成的基础设施的情况下，标记、收集、显示，以及报警这些工作，通常需要10~12个人组成的标准Google SRE团队中的1~2个人全职进行监控的构建和维护工作。由于我们花了很多精力将通用的监控基础设施进行了改造和集中化，这个数字已经随着时间下降了。但是目前每个SRE团队一般至少有一个"监控专员"（虽然平时看看流量图表可能很有意思，但是SRE团队通常会小心地避免任何需要某个人"盯着屏幕寻找问题"的情况。）

一般来说，Google趋向于使用简单和快速的监控系统配合高效的工具进行事后分析。我们会避免任何"魔法"系统——例如试图自动学习阈值或者自动检测故障原因的系统。

这里可以举一个反例∶检测最终用户请求速率的意外变化的系统。我们坚持监控系统规则越简单越好，同时要求这些监控规则可以检测某个非常简单、具体，但是严重的异常情况。监控数据的其他用处还包括容量规划、流量预测，用于这些方面的监控规则对错误和稳定性的要求更低，也就可以稍微复杂一些。针对某个试验功能的数据观测，可能时间跨度非常长（数月甚至数年），取样率也很低，这种用途可以容忍一定的错误率，因为这些偶尔出现的错误不会掩盖真正的长期趋势。

Google SRE在应对复杂依赖关系时的成功经验并不多。我们偶尔会使用这样的规则∶"如果我知道数据库目前缓慢，那么发出一条数据库缓慢的警报，否则发出一条网站缓慢的警告"。针对依赖服务的监控规则，一般只用于系统中非常稳定的组件上。例如某个将用户流量从数据中心迁出的系统。"如果数据中心处于'排水状态'（drained），那么不要发出有关延迟的警报"是一个常见的数据中心警报规则。由于Google基础设施的重构速度很快，很少有团队会在监控系统中维护复杂的依赖关系。

本章中讨论到的某些想法还有想象的空间∶从现象到根源问题的定位速度可以更快，尤其是在一个不断改变的系统中。这一章给监控系统设立了一些目标，同时提供了一些达到这些目标的方法。但是监控系统中最重要的一点就是整个"生产故障，人工处理紧急警报，简单定位和深入调试"过程必须要保持非常简单，必须能被团队中任何一个人所理解。

同样的，监控系统信噪比应该很高，发出紧急警报的组件需要非常简单而且可靠。产生警报的监控系统规则应该非常容易理解，同时代表一个清晰的故障场景。