Author: Hu, Elvin
摘要
监控(Monitor)对服务(Service)的重要性不言而喻。一个配置了有效以及可靠的监控的系统,就像拥有不间断雷达和卫星跟踪保护的民航飞机一样, 让人放心,在关键时刻亦能最大程度的发出警报并减少灾难带来的后果。
智能判断样本是否超越警戒线不是一件容易的事情。漏报和过多的误报都不可取。而样本通常由用户行为产生,且不符合严格的解析规律,这对阀值的设置造成很大困难。为了解决这个问题,我们采用观察变化率的方法,把不可解析的样本曲线转换成可解析的曲线,从而简化分析和判断过程,有效地捕捉突发异常事件,并降低误报率。
本文以eBay的支付流程为例,介绍我们的系统监控实践。
一.简介
eBay依靠 PayPal作为支付平台,而Payment系统处于eBay在线网站和PayPal之间。简单来看就是这个样子:
我们负责开发和维护就是其中的“Payment”部分。通常与钱相关的系统都比较重要,稳定性要求也相对比较高。所以 Payment 这条线必须保持时刻畅通以保障终端用户的支付体验。一旦发生了系统问题我们必须在第一时间知道并予以解决,同时把对用户的影响降低到最小。这一切都仰仗对其的监控能力。
二. 目标
一个合格有效的监控,在具有定性感知错误的能力外还要能定量的回答:什么时间(when),在哪一个环节(where),出了什么错(what)。
When(实时):实时性可理解为灾难发生到被感知的延迟时间 。这个时间当然是越短约好。但是出于对资源的考虑,对不同功能的系统,实时性的要求不完全一样。目前我们对Payment定义的实时为5分钟延迟。
Where(定位):下游系统被理解为上游系统的依赖(Dependency),所以PayPal是Payment 的依赖,Payment又是Checkout的依赖。当支付无法完成的时候,有可能是Payment本身出了问题,也有可能是PayPal出了问题。迅速的定位是解决问题的关键。
通常的做法是对自己监控,同时对下游做监控,因为当别人问起来的时候,我们就可以告诉他Payment有没有问题,是否是由于PayPal不Work而导致的,等等。常常被忽略的是对上游系统的监控,作为身在同一个战壕里的战友,Checkout 出了状况Payment也有责任及时感知并通知,毕竟都是对用户体验的影响。
What(症结):也理解为Root Cause。有可能是数据库连接失败,有可能是HTTPS证书过期,有可能是集群中一台机器掉线,等等。监控系统给出的信息量越多越能帮助我们找到这个Root Cause,从而更迅速的解决问题。
另外还有两点,也非常重要。
多重保护:最好有两套或更多不同监控机制,互相参考,互为备份,以防其中一个出现失误。