Nginx日志管理配置以及分析

nginx 日志格式如下：

  log_format    access_new      '$remote_addr|$remote_user|[$time_local]|$request|'
                                '$status|$body_bytes_sent|$http_referer|'
                                '$http_user_agent|$http_x_forwarded_for|$sent_http_content_range|$request_time|$host';

117.151.182.255|-|[28/Jun/2015:00:12:53 +0800]|GET URI HTTP/1.1|200|1077|-|Dalvik/1.6.0 (Linux; U; Android 4.4.4; 2014811 MIUI/V6.5.2.0.KHJCNCD)|-|-|0.064|211.155.84.158
125.85.116.161|-|[28/Jun/2015:00:12:53 +0800]|GET URI HTTP/1.1|200|136|-|Dalvik/1.6.0 (Linux; U; Android 4.2.2; Meitu2 Build/JDQ39)|-|-|0.017|211.155.84.158
115.203.218.125|-|[28/Jun/2015:00:12:53 +0800]|GET URI HTTP/1.1|200|55|-|Dalvik/1.6.0 (Linux; U; Android 4.4.4; M356 Build/KTU84P)|-|-|0.018|211.155.84.158
119.130.97.106|-|[28/Jun/2015:00:12:53 +0800]|GET URI HTTP/1.1|200|55|-|Dalvik/1.6.0 (Linux; U; Android 4.4.2;M355 Build/KOT49H)|-|-|0.017|211.155.84.158
14.204.95.122|-|[28/Jun/2015:00:13:02 +0800]|GET URI HTTP/1.1|200|1292|-|TopItMe/20150502 CFNetwork/711.0.6 Darwin/14.0.0|-|-|8.978|211.155.84.158
59.45.73.187|-|[28/Jun/2015:00:12:53 +0800]|GET URI HTTP/1.1|200|55|-|Dalvik/1.6.0 (Linux; U; Android 4.4.2; Lenovo A3800-d Build/LenovoA3800-d)|-|-|0.017|211.155.84.158
118.252.74.212|-|[28/Jun/2015:00:12:53 +0800]|GET URI HTTP/1.1|200|748|-|Dalvik/1.6.0 (Linux; U; Android 4.4.2; HUAWEI P7-L09 Build/HuaweiP7-L09)|-|-|0.038|211.155.84.158
182.241.148.60|-|[28/Jun/2015:00:12:53 +0800]|GET URI HTTP/1.1|200|192|-|TopItMe/20150502 CFNetwork/711.3.18 Darwin/14.0.0|-|-|0.020|211.155.84.158
183.14.107.152|-|[28/Jun/2015:00:12:53 +0800]|GET URI HTTP/1.1|200|758|-|Dalvik/1.6.0 (Linux; U; Android 4.3.3; HS-V101m Build/JDQ39)|-|-|0.035|211.155.84.158

下面的脚本是把nginx日志以天的单位进行切割，每天凌晨定期跑一次该脚本

#!/bin/bash
## 零点执行该脚本
# Nginx 日志文件所在的目录
LOGS_PATH=/usr/local/nginx/logs
# 获取昨天的 yyyy-MM-dd
YESTERDAY=$(date -d "yesterday" +%Y-%m-%d)
# 移动文件
mv ${LOGS_PATH}/access.log ${LOGS_PATH}/access_${YESTERDAY}.log
# 向 Nginx 主进程发送 USR1 信号。USR1 信号是重新打开日志文件
kill -USR1 $(cat /usr/local/nginx/nginx.pid)

上面这个脚本中的最后一行必须向 Nginx 的进程发送 USR1 信号以重新打开日志文件，如果不写的话，Nginx 会继续将日志信息写入 access_[yyyy-MM-dd].log 的那个文件中，这显然是不正确的。

USR1亦通常被用来告知应用程序重载配置文件；例如，向Apache HTTP服务器发送一个USR1信号将导致以下步骤的发生：停止接受新的连接，等待当前连接停止，重新载入配置文件，重新打开日志文件，重启服务器，从而实现相对平滑的不关机的更改。

脚本完成后将其存入 Nginx 安装目录的 sbin 中，取名为 cut-log.sh，之后使用 crontab -e 新增一个定时任务，在其中增加执行这个脚本：

0 0 * * * /bin/bash /usr/local/nginx/sbin/cut-log.sh

看总监又使用了zcat来分析打包的日志，然后又看到他用了类似于

awk '{ print$1 $2 }'$LOG| sort| uniq -c| sort -nr| head -10

的命令看切割排序统计等操作，太快没能看清（第一日志格式我没能看清，上面的命令也无法得到下面的结果），最后得到的结果是

6657266 uranus.self.get
5830517 item.getComments
5780047 item.get
4841841 misc.getVersion
4794596 user.getBio
1010859 album.get
 690036 search
 591701 uranus.items.get
 586160 uranus.msgs.get
 423718 misc.log

第一列是一天内访问的次数，第二列是app访问的api地址。这样就统计出来前十个访问最频繁的接口了，然后去着重查看并看能不能优化他们。

综合了这几篇文章： 

http://www.cnblogs.com/benio/archive/2010/10/13/1849935.html 

http://bbs.chinaunix.net/forum.php?mod=viewthread&tid=3582157

http://wenku.baidu.com/view/7376db76a26925c52cc5bfd1.html