监控一个系统有多个原因，包括如下几项。

分析长期趋势

数据库目前的数据量，以及增长速度。又例如每日活跃用户的数量增长的速度。

跨时间范围的比较，或者是观察实验组与控制组之间的区别

使用Acme Bucket of Bytes2.72 或者Ajax DB3.14（都是虚构的系统名称名字）哪个请求速度更快?增加新节点后，memcache的缓存命中率是否增加?网站是否比上周速度要慢?

报警

某项东西出现故障了，需要有人立刻修复!或者某项东西可能很快会出故障，需要有人尽快查看。

构建监控台页面

监控台页面应该可以回答有关服务的一些基本问题，通常会包括常见的4个"黄金指标"（参见本章后面"4 个黄金指标"一节中的详细讨论）。

临时性的回溯分析（也就是在线调试）

我们的请求延迟刚刚大幅增加了，有没有其他的现象同时发生?

系统监控在给业务分析提供原始数据和分析安全入侵的场景时也有一定作用。但是由于本书关注的焦点是SRE所关注的工程领域，我们就不在这里讨论这些方面的应用了。

监控与报警可以让一个系统在发生故障时主动通知我们，或者能够告诉我们即将发生什么。当系统无法自动修复某个问题时，需要一个人来调查这项警报，以决定目前是否存在真实故障，采取一定方法缓解故障，最终找出导致故障的根源问题。除了是在针对某个非常具体的组件进行安全审计的情况以外，我们不应该仅仅因为"某东西看起来有点问题"就发出警报。

紧急警报的处理会占用员工的宝贵时间。如果该员工正在工作时间段，该警报的处理会打断他原本的工作流程。如果该员工正在家，紧急警报的处理则会影响他的个人生活，甚至是把他从睡眠中叫醒。当紧急警报出现得太频繁时，员工会进入"狼来了"效应，怀疑警报的有效性甚至忽略该警报，有的时候在警告过多的时候甚至会忽略掉真实发生的故障。由于无效信息太多，分析和修复可能会变慢，故障时间也会相应延长。高效的警报系统应该提供足够的信息，并且误报率非常低。

监控一个系统有多个原因，包括如下几项。

分析长期趋势

数据库目前的数据量，以及增长速度。又例如每日活跃用户的数量增长的速度。

跨时间范围的比较，或者是观察实验组与控制组之间的区别

使用Acme Bucket of Bytes2.72 或者Ajax DB3.14（都是虚构的系统名称名字）哪个请求速度更快?增加新节点后，memcache的缓存命中率是否增加?网站是否比上周速度要慢?

报警

某项东西出现故障了，需要有人立刻修复!或者某项东西可能很快会出故障，需要有人尽快查看。

构建监控台页面

监控台页面应该可以回答有关服务的一些基本问题，通常会包括常见的4个"黄金指标"（参见本章后面"4 个黄金指标"一节中的详细讨论）。

临时性的回溯分析（也就是在线调试）

我们的请求延迟刚刚大幅增加了，有没有其他的现象同时发生?

系统监控在给业务分析提供原始数据和分析安全入侵的场景时也有一定作用。但是由于本书关注的焦点是SRE所关注的工程领域，我们就不在这里讨论这些方面的应用了。

监控与报警可以让一个系统在发生故障时主动通知我们，或者能够告诉我们即将发生什么。当系统无法自动修复某个问题时，需要一个人来调查这项警报，以决定目前是否存在真实故障，采取一定方法缓解故障，最终找出导致故障的根源问题。除了是在针对某个非常具体的组件进行安全审计的情况以外，我们不应该仅仅因为"某东西看起来有点问题"就发出警报。

紧急警报的处理会占用员工的宝贵时间。如果该员工正在工作时间段，该警报的处理会打断他原本的工作流程。如果该员工正在家，紧急警报的处理则会影响他的个人生活，甚至是把他从睡眠中叫醒。当紧急警报出现得太频繁时，员工会进入"狼来了"效应，怀疑警报的有效性甚至忽略该警报，有的时候在警告过多的时候甚至会忽略掉真实发生的故障。由于无效信息太多，分析和修复可能会变慢，故障时间也会相应延长。高效的警报系统应该提供足够的信息，并且误报率非常低。