今天，结合《SRE Google运维解密》，尝试提炼出所有关于监控系统设计的精髓，希望能捕捉到对现有系统有建设性的改进意见。

脑图整理的很详细，若图看不清，想办法放大，下面开始重点讲解。

为什么要做监控？

在远程办公的当下，你所负责的系统，能正常提供服务显得尤其重要。倘若没有一套监控机制，犹如系统在线上裸奔，时不时需要靠人肉去判断系统是不是崩掉了，你肯定忍不了，你肯定会想要是打造一款监控系统。

监控为什么重要？Google SRE 解密，离开了监控系统，我们就没法辨别一个服务是不是在正常提供服务；没有一套设计周全的监控体系，就如同蒙着眼睛狂奔；监控系统是服务运维中不可或缺的一部分。

无论是研发、运维，估计几乎每天都会发问几句：什么东西出故障了？为什么出故障？

其实，什么东西出故障了，是问题的现象；为什么出故障，是问题的原因。例如，网站正在返回 HTTP 500 或者 404，究其原因是数据库服务器拒绝链接；接口响应速度很慢，分析原因是 CPU 被某个排序操作占满啦。

监控解决啥问题？Google SRE 解密，监控系统应该解决现象与原因两个主要问题。

为什么要监控呢？Google SRE 解密，监控一个系统有多个原因，主要包括如下几项。

1、分析长期趋势。例如数据库目前的数据量，以及增长速度；每日活跃用户的数量增长的速度等。

2、跨时间范围的比较。增加节点后，memcache 的缓存命中率是否增加；网站速度是否比上周速度要慢等。

3、报警。当某项东西出现故障了，需要立刻有人修复，或者需要有人尽快查看。

4、监控台页面 dashboard。用来回答有关服务的一些基本问题。

5、临时性的回溯分析。

做监控要搞懂哪些术语？

2020 年计划在 AIOps 上有所建树，相关概念性的东西还是要普及，底盘还是要打扎实一些。

有关监控的部分相关术语，脑图中整理的很详细了（一定要好好看图呦），不再赘述。

在这里，要重点说一下服务质量术语，尤其是当我们想在指标监控上有所尝试时，这些术语显得尤其重要。

什么是服务质量指标呢？服务的某项服务质量的一个具体量化指标，例如系统吞吐量，每秒请求数量；请求延迟，处理请求所消耗的时间。

如图中整理所示，不同类型的系统，指标也略有不同。例如，用户可见的服务系统的指标，通常关心可用性、延迟，以及吞吐量；存储系统的指标则强调延迟、可用性和数据持久性；大数据系统的指标，通常关心吞吐量和端到端的延迟。

Google SRE 建议我们，在设计时，要考虑指标的标准化，构建一套可以重用的指标模板。设计监控系统时一定要追求简化，指标简化，直到不能再简化。

什么是服务质量目标呢？服务质量目标说的是服务某个指标的目标值或者范围。

Google SRE 建议我们，在实践时，应该从思考用户最关心的方面入手，而非从现在能度量什么入手；另外，与其选择指标，再想出对应的目标，不如从想要的目标反向推导出具体的指标。

监控的四个黄金指标

监控系统的四个黄金指标分别是延迟、流量、错误和饱和度。

如果我们度量所有这四个黄金指标，同时在某个指标出现故障时，或者对于饱和度来说，快要发生故障时，能发出警报，若能做到这些，服务的监控就基本差不多了。

监控的三类重要输出

如开篇对话场景对应的系统，设计时采取的便是针对某个特定的情况或者监控值，一旦出现情况或者监控值超过阈值就触发 E-mail 警报，也就是所谓的最普遍和传统的报警策略。

SRE 解密：这样的报警策略并不是非常有效：一个需要人工阅读邮件和分析警报，来决定目前是否需要采取某种行动的系统，从本质上就是错误的。监控系统，不应该依赖人来分析警报信息，而是应该由系统自动分析，仅当需要用户执行某种操作时，才需要通知用户。

这或许就是现有很多监控系统可以优化改进之处。

另外，一个好的监控系统应该只有下列三种输出。

Google SRE 建议我们：每当收到紧急警报时，应该立即需要我执行某种操作；每天只能进入紧急状态几次，太多就会导致「狼来了」效应；每个紧急警报都应该是关于某个新问题的，不应该彼此重叠。

实践才是硬道理

十年磨一剑，Google 的监控系统 Borgmon 仍在不断的改进和完善。

虽然 Borgmon 仍是 Google 内部工具，但是近年来，监控系统也经历了爆发式增长：Prometheus、Riemann、Heka、Bosun 都是开源软件中与 Borgmon 理念类似的系统，尤其是 Prometheus。

所以，我们可以利用开源软件，尝试落地监控和报警的理念。

今天，结合《SRE Google运维解密》，尝试提炼出所有关于监控系统设计的精髓，希望能捕捉到对现有系统有建设性的改进意见。

脑图整理的很详细，若图看不清，想办法放大，下面开始重点讲解。

为什么要做监控？

在远程办公的当下，你所负责的系统，能正常提供服务显得尤其重要。倘若没有一套监控机制，犹如系统在线上裸奔，时不时需要靠人肉去判断系统是不是崩掉了，你肯定忍不了，你肯定会想要是打造一款监控系统。

监控为什么重要？Google SRE 解密，离开了监控系统，我们就没法辨别一个服务是不是在正常提供服务；没有一套设计周全的监控体系，就如同蒙着眼睛狂奔；监控系统是服务运维中不可或缺的一部分。

无论是研发、运维，估计几乎每天都会发问几句：什么东西出故障了？为什么出故障？

其实，什么东西出故障了，是问题的现象；为什么出故障，是问题的原因。例如，网站正在返回 HTTP 500 或者 404，究其原因是数据库服务器拒绝链接；接口响应速度很慢，分析原因是 CPU 被某个排序操作占满啦。

监控解决啥问题？Google SRE 解密，监控系统应该解决现象与原因两个主要问题。

为什么要监控呢？Google SRE 解密，监控一个系统有多个原因，主要包括如下几项。

1、分析长期趋势。例如数据库目前的数据量，以及增长速度；每日活跃用户的数量增长的速度等。

2、跨时间范围的比较。增加节点后，memcache 的缓存命中率是否增加；网站速度是否比上周速度要慢等。

3、报警。当某项东西出现故障了，需要立刻有人修复，或者需要有人尽快查看。

4、监控台页面 dashboard。用来回答有关服务的一些基本问题。

5、临时性的回溯分析。

做监控要搞懂哪些术语？

2020 年计划在 AIOps 上有所建树，相关概念性的东西还是要普及，底盘还是要打扎实一些。

有关监控的部分相关术语，脑图中整理的很详细了（一定要好好看图呦），不再赘述。

在这里，要重点说一下服务质量术语，尤其是当我们想在指标监控上有所尝试时，这些术语显得尤其重要。

什么是服务质量指标呢？服务的某项服务质量的一个具体量化指标，例如系统吞吐量，每秒请求数量；请求延迟，处理请求所消耗的时间。

如图中整理所示，不同类型的系统，指标也略有不同。例如，用户可见的服务系统的指标，通常关心可用性、延迟，以及吞吐量；存储系统的指标则强调延迟、可用性和数据持久性；大数据系统的指标，通常关心吞吐量和端到端的延迟。

Google SRE 建议我们，在设计时，要考虑指标的标准化，构建一套可以重用的指标模板。设计监控系统时一定要追求简化，指标简化，直到不能再简化。

什么是服务质量目标呢？服务质量目标说的是服务某个指标的目标值或者范围。

Google SRE 建议我们，在实践时，应该从思考用户最关心的方面入手，而非从现在能度量什么入手；另外，与其选择指标，再想出对应的目标，不如从想要的目标反向推导出具体的指标。

监控的四个黄金指标

监控系统的四个黄金指标分别是延迟、流量、错误和饱和度。

如果我们度量所有这四个黄金指标，同时在某个指标出现故障时，或者对于饱和度来说，快要发生故障时，能发出警报，若能做到这些，服务的监控就基本差不多了。

监控的三类重要输出

如开篇对话场景对应的系统，设计时采取的便是针对某个特定的情况或者监控值，一旦出现情况或者监控值超过阈值就触发 E-mail 警报，也就是所谓的最普遍和传统的报警策略。

SRE 解密：这样的报警策略并不是非常有效：一个需要人工阅读邮件和分析警报，来决定目前是否需要采取某种行动的系统，从本质上就是错误的。监控系统，不应该依赖人来分析警报信息，而是应该由系统自动分析，仅当需要用户执行某种操作时，才需要通知用户。

这或许就是现有很多监控系统可以优化改进之处。

另外，一个好的监控系统应该只有下列三种输出。

Google SRE 建议我们：每当收到紧急警报时，应该立即需要我执行某种操作；每天只能进入紧急状态几次，太多就会导致「狼来了」效应；每个紧急警报都应该是关于某个新问题的，不应该彼此重叠。

实践才是硬道理

十年磨一剑，Google 的监控系统 Borgmon 仍在不断的改进和完善。

虽然 Borgmon 仍是 Google 内部工具，但是近年来，监控系统也经历了爆发式增长：Prometheus、Riemann、Heka、Bosun 都是开源软件中与 Borgmon 理念类似的系统，尤其是 Prometheus。

所以，我们可以利用开源软件，尝试落地监控和报警的理念。