nginx status active writing升高，分析日志

最近cacti 监控的nginx status显示不正常，分析了日志并记录下来自己的操作步骤，希望大家能提供更好的建议！

而各个参数含义如下：

     Active -- nginx 当前正活动连接数。

reading -- nginx 读取到客户端的 Header 信息数。 

writing -- nginx 返回给客户端的 Header 信息数。 

waiting -- 开启 keep-alive 的情况下，这个值等于 active - (reading + writing)，意思就是 Nginx 已经处理完正在等候下一次请求指令的驻留连接。

如果reading或writing的值很高,说明正在处理的数据量很大,可能后端的php程序处理慢,而一般来说,PHP之后以慢,是因为MYSQL,另一个原因很可能就是IO慢,或者客户端的网络慢。

而我这种现象只有writing值比较高，后端的php也很正常，数据库io也很低，所以不是系统和程序的问题。然后就分析下当前的日志内容。

分析wirting升高这段时间点的日志内容

# awk '$4~"13/Dec/2014:21:5[0-9]:*"' access_20141213.log |awk '{print $11}' |sort |uniq -c |sort -nr |head -10
   9103 "-"
    229 "http://static.atm.youku.com/Youku2013/201305/0521/test/ugc-300-250.html"
    204 "http://static.atm.youku.com/YouKu2014/201411/1117/60281/tbloader2.7_400300.swf?show=1&pid=mm_10982364_973726_20654794&u=http://www.youku.com"
    123 "http://static.youku.com/v1.0.0490/v/swf/loader.swf"
    117 "http://js.tudouui.com/bin/lingtong/PortalPlayer_141.swf"
     84 "http://www.1905.com/coll/adproxy.html?aid=92925"
     81 "http://gb.cri.cn/gg/news2013/ad1.htm"
     62 "http://p_w_picpaths.sohu.com/ytv/BJ/BJSC/40030020141118100226.swf?pid=mm_26632206_2690592_14776600&w=400&h=300&u=http%3A%2F%2Fsohu.com%2F"
     59 "http://www.tappal.com/index.php/index/cakebrand"
     41 "

分析writing正常时的日志信息

# awk '$4~"13/Dec/2014:22:5[0-9]:*"' access_20141213.log |awk '{print $11}' |sort |uniq -c |sort -nr |head -10
   1286 "-"
     46 "http://www.tappal.com/index.php/activity/wap_exchange_area.html?city_code=FWAXW1fsVRXH8e4"
     39 "http://www.tappal.com/index.php/index/cakebrand"
     27 "http://www.tappal.com/"
     20 "http://www.tappal.com/index.php/index/user_login"
     20 "http://www.tappal.com/index.php/index/index"
     17 "http://www.tappal.com/index.php/activity/wap_newwelfare.html?token"
     13 "http://www.mplife.com/"
     11 "http://www.tappal.com/index.php/goods/collection/id/32"
     11 "http://www.tappal.com/index.php/activity/wap_newwelfare.html?token=8d6aade1f948a8135839a5c0e2fd6341487181282"

从中可以看出，writing高峰时，$http_referer 的来源不正常，估计是被盗链了。

由于使用cdn，被盗链首先需要在节点做防盗链，如果节点上禁止了或者是节点无缓存，会到源站获取数据。所以需要在源站加防盗链；

防盗链有三种方法，随便找了一个加上

location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$
                        {
                                valid_referers none blocked *.tappal.com tappal.com;
                                if ($invalid_referer) {
                                        return 404;
                        }
                                expires      30d;
                        }

    观察一段时间后发现writing已经降下来！

如果大家有很快速找出问题的办法，可以拿出来分享，我太水了，也是找了比较久才发现问题。