SRE体系10----部署监控

监控系统是支撑我们运维工作的基石之一，它能够帮助我们分析系统的长期趋势，在发生故障时发送报警，甚至自动修复故障，同时也是我们分析系统性能和问题的第一手材料，所以监控系统的部署和优化是必不可少的。

监控原则

1. 监控有分级。可以通过监控项一旦发生故障产生的影响来分级，不致命的监控告警尽量优化，不要占用SRE的on-call工作时间。否则紧急告警太频繁会让SRE进入“狼来了”的状态，开始怀疑报警的有效性，以致于忽略了真正危险的告警
2. 监控要尽量简化。监控项及报警规则要容易理解，能够代表一个清晰的故障场景，监控模板要常更新，去除无用监控项
3. 监控现象，现象是指发生了什么，例如cpu利用率100%，延迟超过2s，探针返回404错误码等，实时抓取第一手数据，每个人对监控到的现象的理解是不一样的。如何分析监控数据是另一个系统的事，所以监控项尽量不要加自己的分析逻辑

监控方式：

白盒监控：
依靠业务系统内部暴露的一些指标进行监控，如日志接口，java虚拟机监控接口，或业务系统内部自己开发的http请求统计接口。白盒监控要求对业务系统内部架构非常熟悉，能够监控数据，预测趋势

黑盒监控：
通过测试某种外部用户可见的系统行为进行监控。例如监控一个商城系统，不需要了解系统内部架构。只需要模拟外部用户的下单行为，发送一个HTTP请求给系统，如果系统返回的数据正确则认为系统是正常的。

监控精度和阀值：

对于可用性较高的业务系统需要设置更高的监控精度，例如cpu每分钟检测1次。但对于一些低可用性非重要系统，监控频率可以调低到1小时1次。因为监控系统本身会消耗服务器资源和存储资源，不合理的精度会导致服务器负担加重，影响本机运行的业务。

监控时大多数人倾向于监控平均值并设置阀值，但对于波动比较大的监控项是明显不合适的。 例如监控HTTP请求延迟，950个请求延迟是10ms，50个请求延迟是10s。这明显是有问题的，如果按照平均值计算会认为延迟正常从而忽略这个问题。我们可以通过高百分位或者直方图的方式来监控波动率大的指标。例如90%的请求延迟小于30ms，99.9%的请求延迟小于60ms，以此来表示指标的分布情况

监控指标：

典型的有以下四类，剩余的均是在此四类指标上的拓展

1. 延迟：服务处理某个请求需要的时间
2. 流量：QPS,网络i/o，磁盘i/o
3. 错误：请求失败的数量和速率
4. 饱和度：服务容量的使用率，如CPU,内存，存储等使用率