《监控运维实践：原则与策略》读书笔记

• 监控不是一个单一问题，无法通过某一个工具来解决

  + 如果想在代码级别分析并监控应用程序，你可能需要 APM 工具，或者自行测量应用程序（例如，通过 StatsD）。
  + 如果需要监控云基础设施的性能，你需要寻找现代化的服务器监控解决方案。
  + 如果需要监控生成树拓扑结构的变化或路由变更，你需要寻找专注于网络的工具。
  

  1. 合并提供相同信息的工具

  2. 不要害怕引入专用工具

     团队希望使用能够解决问题的工具，而不是以“整合工具”之名被迫使用不能满足其需求的工具

• 盲目崇拜更成功的团队以及公司的工具和程序

  团队需要花很多时间去理解为什么一个工具或程序是有效的。工具是工作方式、假设、文化和社会规范的表现。这些规范不太可能直接适用于你的团队。

监控本身与被监控对象息息相关，不了解被监控对象就无法为其创建监控体系， 因此监控不是一份工作，而是一项技能，并且是团队中每位成员都需要在一定程度上掌握的技能

  在监控过程中，请坚持让每个人都对监控负责。DevOps 运动的一个核心宗旨就是让所有人而不只是运营团队对产品负责。
  网络工程师最了解应该监控网络中的哪个部分以及热点的分布。
  软件工程师比任何人都了解应用程序，所以应该将他们放在最合适的位置上，以便为应用程序设计最好的监控。

• 确保监控的首要地位，只有部署好监控的产品才具备上线条件
• 可以有专人创建监控工具，但监控本身不由其负责。

如何判断自己是否已经成为这种反模式的受害者呢？可以通过以下几种迹象来判断。

+ 虽然你记录系统负载、CPU 使用率和内存利用率这样的指标，但是服务还是在你不知道原因的情况下停止运行。
+ 你习惯性地忽略告警信息，因为它们多数时候是误报。
+ 你每隔 5 分钟或者更短的时间就要检查系统的指标。
+ 你没有存储历史指标数据（说的就是你，Nagios）。

这个反模式通常和上一个反模式（监控岗位化）一同出现。因为配置监控的人员没有完全理解系统的工作原理，所以他们经常只配置最简单和最容易的检查项

• 弄清正常运行的真正含义

• 系统资源类的告警不是很有用

      如果 MySQL 总是使用全部的 CPU，但是响 应时间在可接受范围内，那其实没有问题。
      这就是为什么与 CPU 和内存使用率这样的低级别指标相比，了解“正常运行”的含义要有用得多。
  
      当然，并不是说这些指标没有用。操作系统指标对于诊断和性能分析至关重要，因为它们能让你在可能影响性能的底层系统行为中发现波动和趋势。
      但在大多数情况下，它们并不意味着真正有问题
  

• 增加收集指标数据的频率

      在一个复杂的系统（比如现在运行的这个）中，几分钟甚至几秒钟内就能发生很多事。
      考虑这样一个例子：假设不管什么原因ÿ