×

微信扫一扫,快捷登录!

为什么要对监控系统设置合理预期

标签: 暂无标签
监控一个复杂的应用程序本身就是一项复杂的工程项目。即使在具有大量现成的基础设施的情况下,标记、收集、显示,以及报警这些工作,通常需要10~12个人组成的标准Google SRE团队中的1~2个人全职进行监控的构建和维护工作。由于我们花了很多精力将通用的监控基础设施进行了改造和集中化,这个数字已经随着时间下降了。但是目前每个SRE团队一般至少有一个"监控专员"(虽然平时看看流量图表可能很有意思,但是SRE团队通常会小心地避免任何需要某个人"盯着屏幕寻找问题"的情况。)

一般来说,Google趋向于使用简单和快速的监控系统配合高效的工具进行事后分析。我们会避免任何"魔法"系统——例如试图自动学习阈值或者自动检测故障原因的系统。

这里可以举一个反例∶检测最终用户请求速率的意外变化的系统。我们坚持监控系统规则越简单越好,同时要求这些监控规则可以检测某个非常简单、具体,但是严重的异常情况。监控数据的其他用处还包括容量规划、流量预测,用于这些方面的监控规则对错误和稳定性的要求更低,也就可以稍微复杂一些。针对某个试验功能的数据观测,可能时间跨度非常长(数月甚至数年),取样率也很低,这种用途可以容忍一定的错误率,因为这些偶尔出现的错误不会掩盖真正的长期趋势。

Google SRE在应对复杂依赖关系时的成功经验并不多。我们偶尔会使用这样的规则∶"如果我知道数据库目前缓慢,那么发出一条数据库缓慢的警报,否则发出一条网站缓慢的警告"。针对依赖服务的监控规则,一般只用于系统中非常稳定的组件上。例如某个将用户流量从数据中心迁出的系统。"如果数据中心处于'排水状态'(drained),那么不要发出有关延迟的警报"是一个常见的数据中心警报规则。由于Google基础设施的重构速度很快,很少有团队会在监控系统中维护复杂的依赖关系。

本章中讨论到的某些想法还有想象的空间∶从现象到根源问题的定位速度可以更快,尤其是在一个不断改变的系统中。这一章给监控系统设立了一些目标,同时提供了一些达到这些目标的方法。但是监控系统中最重要的一点就是整个"生产故障,人工处理紧急警报,简单定位和深入调试"过程必须要保持非常简单,必须能被团队中任何一个人所理解。

同样的,监控系统信噪比应该很高,发出紧急警报的组件需要非常简单而且可靠。产生警报的监控系统规则应该非常容易理解,同时代表一个清晰的故障场景。





上一篇:为什么要对分布式系统进行监控
下一篇:监控系统应该解决两个什么问题
Wendy

写了 336 篇文章,拥有财富 434,被 3 人关注

您需要登录后才可以回帖 登录 | 立即注册
B Color Link Quote Code Smilies

成为第一个吐槽的人

返回顶部