×

扫描二维码登录本站

QQ登录

只需一步,快速开始

监控系统的长期维护应注意哪些事项

标签: 暂无标签
本帖最后由 FYIRH 于 2020-12-5 23:37 编辑

本章描述的理念整合起来就成为Google SRE广泛接受和遵循的监控与警报设计哲学。虽然这个设计哲学有一定理想性,但是书写和评审某个新警报时可以依赖的好方法。该哲学同时有助于鼓励团队在解决问题时向正确的方向进行。


当为监控系统和警报系统增加新规则时,回答下列问题可以帮助减少误报∶

● 该规则是否能够检测到一个目前检测不到的、紧急的、有操作性的,并且即将发生或者已经发生的用户可见故障?

● 是否可以忽略这条警报?什么情况可能会导致用户忽略这条警报,如何避免?

● 这条警报是否确实显示了用户正在受到影响?是否存在用户没有受到影响也可以触发这条规则的情况?例如测试环境和系统维护状态下发出的警报是否应该被过滤掉。

●收到警报后,是否要进行某个操作?是否需要立即执行该操作,还是可以等到第二天早上再进行?该操作是否可以被安 全地自动化?该操作的效果是长期的,还是短期的?

● 是否也会有其他人收到相关的紧急警报,这些紧急警报是否是不必要的?

以上这些问题其实反映了在应对紧急警报上的一些深层次的理念∶

●每当收到紧急警报时,应该立即需要我进行某种操作。每天只能进入紧急状态几次,太多就会导致"狼来了"效应。

● 每个紧急警报都应该是可以具体操作的。

● 每个紧急警报的回复都应该需要某种智力分析过程。如果某个紧急警报只是需要一个固定的机械动作,那么它就不应该成为紧急警报。

● 每个紧急警报都应该是关于某个新问题的,不应该彼此重叠。


从这种角度出发,我们可以得出以下结论∶如果某个紧急警报满足上述四点,那么不论是从白盒监控系统还是黑盒监控系统发出都一样。最好多花一些时间监控现象,而不是原因。针对"原因"来说,应该只监控那些非常确定的和非常明确的原因。

在现代生产环境中,监控系统需要跟随不断演变的软件一起变化,软件经常重构,负载特性和性能目标也经常变化。现在的某个不常见的、自动化比较困难的警报可能很快就会变成一个经常触发、需要一个临时的脚本来应对的问题。这时,某个人应该去寻找和消除背后的根源问题∶如果这种解决办法不可行,那么这条警报的应对就必须要完全自动化。

关于监控系统的设计决策应该充分考虑到长期目标。今天发出的每个紧急警报都会占用优化系统的时间,所以经常会牺牲一些短期内的可用性和性能问题,以换取未来系统性能的整体提升。以下是两个具体的案例。





上一篇:度量分布式系统监控的指标时采用怎样合适的精度
下一篇:分布式监控系统的警报过多的案例
萨达

写了 327 篇文章,拥有财富 1738,被 4 人关注

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

成为第一个吐槽的人

最新100贴|论坛版块|ITIL先锋论坛 |粤ICP备11099876号|网站地图
Powered by Discuz! X3.4 Licensed  © 2001-2017 Comsenz Inc.
返回顶部