nginx status active writing升高,分析日志

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

wKioL1SRMWLyTlM9AARt_Q3iXkI933.jpg


而各个参数含义如下:

     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://images.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已经降下来!

wKiom1SRNnGCm_KdAAWJ3bSK4P0853.jpg


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

你可能感兴趣的:(nginx,防盗链,writing,$http_referer)