流量暴升擒凶记51CTO博客 - 牛牛娱乐

流量暴升擒凶记51CTO博客

2019-01-03 16:28:02 | 作者: 半双 | 标签: 流量,暴升,服务器 | 浏览: 945

流量暴升擒凶记

田逸(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分钟后,趋于正常了。打一通电话后,持续睡觉。


版权声明
本文来源于网络,版权归原作者所有,其内容与观点不代表牛牛娱乐立场。转载文章仅为传播更有价值的信息,如采编人员采编有误或者版权原因,请与我们联系,我们核实后立即修改或删除。

猜您喜欢的文章