这是4月2日17:30~19:30之间发生在阿里云上的故事。
标题中的“看不见”是指阿里云的监控系统没有监控到;“CPU在坐过山车”是指CPU占用的瞬间波动(见下图);“磁盘IO在蹦极”是指磁盘IO的瞬间波动。
(图1)
4月2日17:30左右开始,访问博客园首页有时会遇到502 Bad Gateway错误,如下图:
这是由阿里云负载均衡SLB返回的错误信息。
发现这个问题后,我们立即登上负载均衡中的2台云服务器,查看Windows性能监视器发现CPU占用波动很大(见之前的图1),有如坐过山车,瞬间冲到100%(如果在这时访问网站就会遇到502错误),然后又回落。接着,打开阿里云网站上的管理控制台,查看系统资源监控,奇迹出现了——阿里云监控显示CPU占用平稳,最高也没超过60%。
当时以为是阿里云监控系统出了问题,于是向阿里云提交了工单。
18:00左右,我们与阿里云客服都未进行任何操作,CPU占用突然恢复了正常。
CPU坐完过山车后不久,18:30左右开始,我们收到用户的反馈,说在博客后台发布博文时出现提示:“Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.”(数据库写入超时)。我们对这个错误记忆犹新,3月14日经历过(详见云计算之路-迁入阿里云后:20130314云服务器故障经过),那次是由于云服务器所在的集群硬盘IO负载高引起的。我们断定这次肯定还是云服务器磁盘IO的问题。于是又进入阿里云网站上的管理控制台,查看系统资源监控以验证磁盘IO是否高,奇迹又一次出现——阿里云监控显示磁盘IO正常。
19:30左右,"Timeout expired"错误消失。
我们又向阿里云提交了工单,阿里云客服依据监控数据,认为阿里云自身的系统正常。我们当然不认同,我们的应用本身不会引发这个罕见的"Timeout expired"错误,而且这段时间数据库写入操作并不多。
我们查看了这段时间数据库中的数据,发现也有不少博文正常发布了。说明当时如果磁盘IO有问题,应该是处于一种波动情况。用户在波峰时提交,就会遇到数据库写入超时故障。
可奇怪的是为什么阿里云监控系统监控不到磁盘IO的波动?更奇怪的是两次问题,阿里云监控系统都没监控到。
。。。
第二天,接到阿里云客服的电话,说我们在阿里云网站的管理控制台上看到的监控数据是5分钟采一次样,阿里云客服看到的监控数据是1分钟采一次样(两处的监控都没监控到)。对于瞬间波动,阿里云监控系统的确很难监控到。
接了电话之后,我们分析了一下,然后豁然开朗。
阿里云监控系统每1分钟巡视一下我们的云服务器, CPU坐过山车、磁盘IO蹦极发生在秒级。阿里云监控过来巡视时,CPU已经或者还没坐过山车,磁盘IO已经或者还没蹦极。这种瞬间波动情况正好躲过了阿里云监控系统的监控,就好像CPU、硬盘IO和阿里云监控系统玩起了捉迷藏。
虽然问题只发生波动的瞬间,但确确实实多位用户遭遇了这个问题,这就是一种故障,是故障就要找出原因。我们不害怕问题,害怕的是不明不白的问题。
于是,我们将分析情况通过工单反馈给了阿里云。
一段时间之后,阿里云客服的回复终于让真相大白:在那段时间,云服务器所在的物理机出现了硬件故障,后来紧急修复了故障。