简化，直到不能再简化

将之前讨论的所有需求累加起来可能会形成一个非常复杂的监控系统—以下是几个复杂度的例子：

● 不同的延迟阈值，在不同的百分位上，基于各种各样不同的指标进行报警。

● 检测和揭示可能的故障原因。

● 给每种可能的原因构建对应的监控台页面。

复杂是没有止境的。就像任何其他软件系统一样，监控系统可能会变得过于复杂，以至于经常出现问题，变更非常困难，维护起来难度很大。

因此，设计监控系统时一定要追求简化。在选择需要检测什么的时候，将下列信息记在心里：

● 那些最能反映真实故障的规则应该越简单越好，可预测性强，非常可靠。

● 那些不常用的数据收集、汇总，以及警报配置应该定时删除（某些SRE团队的标准是一个季度没有用到一次即将其删除）。

● 收集到的信息，但是没有暴露给任何监控台，或者被任何警报规则使用的应该定时删除。

在Google的经验里，指标的收集和汇总，加上警报系统与监控台系统，作为一个相对独立的系统运行是比较好的。（事实上，Google的监控系统是作为多个二进制文件运行的，但是通常人们把它们当成一个整体来学习。）将监控系统与其他的复杂系统操作结合起来（例如系统性能统计，单独进程的调试，异常或者崩溃的跟踪，负载测试，日志收集和分析，流量检测等）会导致监控系统过于复杂，容易出现问题。和其他软件工程的理念一样，保持系统相对独立，清晰简单，松耦合的接口是更好的策略（例如，利用Web API来收集性能数据，采用一种可以持续很久不变的简单数据格式）。