nginx status active writing升高，分析日志

rtwer

最近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升高这段时间点的日志内容

1 2 3 4 5 6 7 8 9 10 11

# 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正常时的日志信息

1 2 3 4 5 6 7 8 9 10 11

# 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，被盗链首先需要在节点做防盗链，如果节点上禁止了或者是节点无缓存，会到源站获取数据。所以需要在源站加防盗链；

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

1 2 3 4 5 6 7 8

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

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



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