本文主要是介绍SRE方法论之监控设计,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!
监控的4个黄金指标
《SRE:Google运维解密》中提出,监控系统的四个黄金指标是:延迟(Latency)、流量(Traffic)、错误(Errors)、饱和度(Saturation)。
- 延迟:服务处理某个请求所需要的时间。在微服务中通常提倡快速失败,服务不要憋着,这些延迟请求要尽快反馈给开发人员分析,这些缓慢的错误会消耗系统性能,所以需要对这些错误延迟进行长期跟踪处理。
- 流量:当前系统的数据流入流出的数据统计,用来衡量服务的承载能力,不同系统的流量有不同的含义,比如对web服务来说,流量指每秒的 HTTP 请求数。
- 错误:当前系统发生错误请求的数量,一般单纯看数量不太直观,经常会对错误进行计算处理,换算成错误率。
- 饱和度:饱和度用来衡量当前服务的承载能力,一般是使用率和空闲率。如果系统主要受内存影响,那就主要关注系统的内存状态,如果系统主要受限与磁盘I/O,那就主要观测磁盘I/O的状态。因为通常情况下,当这些资源达到饱和后,服务的性能会明显下降。同时还可以利用饱和度对系统做出预测,比如,当前内存使用率已经达到 80% ,很快就要满了,这时就可以发出告警及时处理。
监控指标设计原则
长尾问题
假设一个web服务的http请求平均耗时为100ms,单看这个数据觉得服务性能没问题,但可能有1%的请求耗时超过5s,而这1%的请求就有可能引发用户投诉或其它风险。由于是计算的平均值而容易被忽略,最好的方法是将请求延迟分段统计。
采用合适的精度
监控数据的高频率收集、存储、分析成本很高,要根据监控对象以及监控目标合理设置监控周期、监控频率等。
减少告警误报
现在很多公司抱着“宁可错杀一万,也不能放走一个”的原则制定监控标准,这样做的后果就是运维人员疲于奔命,时间一长就会造成"狼来了"的后果。增加新的监控规则时,可以遵循以下原则:
- 收到紧急告警时,应该立即需要进行某种操作。每天只能进入紧急状态几次,太多就会导致“狼来了”效应。
- 紧急告警都应该是可以具体操作的。
- 紧急告警的回复都应该需要某种智力分析过程。如果某个紧急告警只是需要一个固定的机械动作,那么它就不应该成为紧急告警。
- 紧急告警都应该是关于某个新问题的,不应该彼此重叠。
监控系统建设原则
以上关于监控指标的讨论累加起来就会形成一个复杂的监控系统。
监控系统尽量简化
复杂是没有止境的,过于复杂的监控系统维护起来麻烦,而且经常出问题。
- 那些最能反映真实故障的规则应该越简单越好。
- 那些不常用的数据收集、汇总,以及告警配置应该定时删除。
- 收集到的信息,但是没有暴露给任何监控台,或者被任何告警规则使用的应该定时删除。
监控系统应作为一个独立的系统运行
保持监控系统相对独立、清晰简单。和其他系统保持松耦合,可以采用API来收集性能数据。
监控系统需要长期维护
监控系统需要跟随不断演变的软件一起变化,软件经常重构,负载特性和性能目标也经常变化。现在的某个不常见的、自动化比较困难的告警可能很快就会变成一个经常触发、需要一个临时的脚本来应对的问题。这时,应该去寻找和消除背后的根源问题:如果这种解决办法不可行,那么这条告警的应对就必须要完全自动化。
这篇关于SRE方法论之监控设计的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!