监控分布式系统 3 -- 尾延迟·监控哲学·长期监控

担心你的尾巴

当我们建立一个监控系统时，会倾向基于某些数据的平均值来设计。比如，latency的均值，CPU使用率的均值，或者数据库填充率的均值。后面两项的危险不言而喻，因为CPU和数据库很容易被以一种很不均衡的方式使用。对于latency也一样，如果在每秒1000次请求时，web服务的平均latency是100，很容易有1%的请求超过5秒。而如果你的前端用户为了显示网页依赖于好几个这样的web服务的话，一个后端服务的99th percentile很容易成为前端请求时间的中位数（尾延迟放大）。

所以对于请求时间的测量应该把请求数与请求时间合起来看：有多少请求用了0ms到10ms, 10ms到30ms, 30ms到100ms, 100ms到300ms，等等，然后画成柱状图让分布情况一目了然。

选择合适的测量粒度

系统的不同方面应该由不同层级的粒度来测量，但是要根据需求与成本对数据的收集策略作取舍。

简单到不能再简单

如果把上面提到的所有原则都考虑进去，你的系统可能会异常复杂。因此，要记住把你的监控系统向简单的方向设计，可以遵循以下原则：

• 对于最常发生问题的监控规则要简单，可靠，可预期
• 对于很少被使用（一季度不足一次）的监控数据和配置应考虑移除

监控哲学

当建立监控报警系统时，问一问下面的问题：

• 这条规则监测的内容是不是在其他情况下没有监测到的？
• 需要应对的情况是否紧急？是否可应对？现在对用户可见？即将对用户可见？
• 在知道一个报警是良性时，我是否可以忽略它？在那种情况下我可以忽略？为什么？如何可以避免这种情况发生？
• 通过这条报警能否肯定有用户受到了负面影响？有没有一些应该过滤掉的用户并没有受到负面影响的案例？
• 受到这条报警时，我能做些什么？这个操作是否紧急，或者可以等到第二天早上？这个操作能否安全地自动化？这个操作是一个长期的解决方案，或者只是一个短期的变通方法？
• 其他人是否也收到了这个问题的报警，也就是说至少联系了一个非必要的人？

这些问题反应了待机运维人员的基本想法：

• 每一次收到报警时，我应该能够做出紧急应对，并且这样的紧急应对我一天只能做几次，否则会厌烦。
• 每一次报警都应该是可以应对的。
• 每一次报警的回复应该是需要一定智商的。如果一个报警只需要一个机械的回复，拿它就不应该是一个报警。
• 报警对应的应该是一个之前没有发生过的新问题或事件。

通过以上想法可以看出：

• 当一个报警满足上面4点时，它是由白盒监控或者黑盒监控触发的并不重要
• 相对于原因，应该花费更多的努力在抓住症状上

长期监控

面对一个问题时，我们往往会有短期方案与长期方案。短期方案可能能够迅速让系统恢复稳定性， 但往往伴随着潜在风险。长期方案往往会是一个痛苦的选择，因为它代表着为了系统未来的长期稳定而暂时牺牲系统当前的可用性。另外要注意的是不要把每次报警当成独立的事件看，我们要用长远的眼光，从报警的整体层面来看系统是否变得更加健康。

案例1：Bigtable SRE

谷歌Bigtable服务的SLO本来是基于性能平均值的，但是由于bigtable自身以及更下层存储栈里的问题，均值的分布是被一个“大尾巴”主导的：最慢的那5%的请求要比其他请求慢很多很多。
这就造成报警邮件和报警传呼的数量激增，占用了工程师大量的时间，但是这些报警里许多并没有直接对用户造成影响，也并不紧急。
为了解决这个问题，团队采取了三项措施：

• 尽最大努力提升bigtable的性能
• 把SLO的目标调到75th percentile
• 关闭邮件报警

以上措施让团队有时间去真正解决bigtable的长期问题，待机的工程师在没有报警传呼时也可以完成更多的工作。最终，暂时调低报警等级让团队能够更快地改善服务。

参考资料
https://landing.google.com/sre/sre-book/chapters/monitoring-distributed-systems/