流量暴涨擒凶记

流量暴涨擒凶记

田逸（sery@163.com） from《网络管理与运维》

某天，月黑风高，寒风凌厉。迷糊中，一阵急促的电话响起，来电告知，数个机房的带宽暴涨，需要立即处理，否则IDC服务商要拔网线了。一看时间，大概是凌晨2点了，真悲催啊！

先登录监控系统查看流量。平时流量最大的一个服务器的带宽跑满1G了（因为当时急着处理故障，没留下截图），而正常情况下，它的带宽峰值稳定在600M-700M/s的样子，如下图所示：

查看其它服务器，带宽图基本拉成一条直线，把100M跑满了（这些机器性能差，带宽为100M）。

尽管多个机房多个服务器带宽都超平常很多，基本可以确定是出问题了。但心里还是不放心，担心是cacti监控不准或者出了故障。因此又单独登录数个流量大的服务器，使用iptraf这样的工具实时查看，结果真的与cacti给出的结果一致。

这是一个下载业务，总带宽峰值大概在3Gb/s的样子。其结构分为三层：源站、中转层、边缘层。其业务流程如下图所示：

1、用户通过web借口编辑和上传文件到源站服务器；

2、源站用rsync同步文件到中转服务器；

3、边缘服务器配置成缓存，然后根据需要从中转服务器抓取所需的对象存储起来。

为了提高可用性和负载均衡，边缘服务器从2个中转服务器抓取文件。

一般来说，引起流量暴涨的原因无外乎有：遭受***、网站市场推广、系统或程序异常、***程序。通过询问相关市场人员，答复说近期没有任何市场推广；再问程序员，有没有修改程序或新增插件，答复都是否定的。再让管理人员查看后台统计数据，但统计数据并没有跟流量同步暴增。由此判断，出问题的原因只剩下系统异常和******两种情况。被植入***的几率很小：程序是通过***上传的，并且只有静态内容。

情况紧急，不可能每个服务器都登录一片。因此先从流量最大的查起，再查流量次大的。检查的项目包括：

(1)系统日志：看是否有内核报错；

(2)Web日志，统计ip来源是否过于集中；

(3)查看tcp状态，了解请求情况；

(4)用工具iptraf查看连接数最多的ip。

通过上述措施，得知连接数最多的ip不是来自用户，而是来自服务器之间的相互请求。通过查出来的ip，登录改服务器，看是否发生了什么？通过检查进程、系统日志、网络状况都未找到原因。随手执行了一下crontab –l 看有没有什么自动任务，结果发现有一个脚本，而且是每10钟执行一次。我印象中没写个这样一个脚本的。打开一看，内容如下：

#!/bin/bash Path=`grep proxy_cache_path  /usr/local/nginx/conf/vhosts/apk_cache.sery.com.conf |awk '{print $2}'|sed  1d` for i in `ls $Path`; do grep -a -r apk $Path/$i/* | strings |grep  "KEY:" >/tmp/cache_list$i.txt grep -v apk$ /tmp/cache_list$i.txt >>  /tmp/del$i.txt \rm -rf `grep -v apk$  /tmp/cache_list$i.txt|awk -F: '{print $1}'` #echo $Path/$i sleep 60 done \rm -rf /tmp/cache_list*

这个脚本要结合具体场景才能弄明白，因为某些原因，这里不再分析它；总之，这个脚本的作用，就是在缓存目录查询一些文件是否存在，如果存在，就删除它。

上述操作的结果，就是缓存文件刚存在，不久就被干掉。当用户需要下载这个文件时，边缘服务器却没有缓存，因此只好回源（向中转服务器抓取）。正常情况下，会缓存很长一段时间，但因为这个脚本，过一会又把它干掉了。这就导致不断的大量的回源，流量就暴涨了。未避免风险，没之间删除这个脚本，而在crontab计划任务里把它注释掉。逐一在边缘服务器排查，注释掉这个任务。

观察流量图，带宽耗费逐步下降，10-20分钟后，趋于正常了。打一通电话后，继续睡觉。