如何挖掘Nginx日志中隐藏的金矿？

《如何挖掘Nginx日志中隐藏的金矿？》要点：
本文介绍了如何挖掘Nginx日志中隐藏的金矿？，希望对您有用。如果有疑问，可以联系我们。

Nginx(读作Engine-X)是现在最流行的负载均衡和反向代理服务器之一.如果你是一名中小微型网站的开发运维人员,很可能像我们一样,仅Nginx每天就会产生上百M甚至数以十G的日志文件.如果没有出什么错误,在被logrotate定期分割并滚动删除以前,这些日志文件可能都不会被看上一眼.

实际上,Nginx日志文件可以记录的信息相当丰富,而且格式可以定制,考虑到`$time_local`请求时间字段几乎必有,这是一个典型的基于文件的时间序列数据库.Nginx日志被删除以前,或许我们可以想想,其中是否蕴含着未知的金矿等待挖掘?

// 请求总数 ? ? 
?less main.log | wc -l ? 
?1080577 ? ? ? ? 
?// 平均每秒的请求数 ? ?
less main.log | awk '{sec=substr($4,2,20);reqs++;reqsBySec[sec]++;} END{print reqs/length(reqsBySec)}' ? ?14.0963 ? ? ? ? ?
// 峰值每秒请求数 ? 
?less main.log | awk '{sec=substr($4,20);requests[sec]++;} END{for(s in requests){printf("%s %s\n",requests[s],s)}}' | sort -nr | head -n 3 ? ?
Page Visits ?Response Size ?Time Spent/req ?Moment ? ?
182 10/Apr/2016:12:53:20 ? ? ?
161 10/Apr/2016:12:54:53 ? ?
160 10/Apr/2016:10:47:23

请求总数、平均每秒请求数、峰值请求数,可以大体了解系统压力,作为系统扩容、性能及压力测试时的直接参考.查询特定的URL,比如下单页面,了解每天的下单状况,导出CSV格式,或使用可视化工具,更直观地了解一段时间内的请求、下单数据：

备注：本文使用awk命令处理,与Nginx日志的格式有关,如果您格式不同,请酌情修改命令.本文所用的Nginx日志格式：

$remote_addr - $remote_user [$time_local] "$request" 
$status? $body_bytes_sent $request_time $upstream_response_time 
$upstream_addr "$http_referer" "$http_user_agent" "$http_x_forwarded_for"';

示例：

42.100.52.XX - - [10/Apr/2016:07:29:58 +0800] "GET /index
 HTTP/1.1" 200 7206 0.092 0.092 "-" "Mozilla/5.0 (iPhone; CPU iPhone OS 
7_1_2 like Mac OS X) AppleWebKit/537.51.2 (KHTML,like Gecko) Mobile/11D257" "-"

等等,你可能会有疑问,上面的请求访问分析,这里的流量速率分析,按时间轴画出来,不就是监控系统干的事儿吗,何苦这么麻烦查询Nginx日志?

的确如此,监控系统提供了更实时、更直观的方式.而Nginx日志文件的原始数据,可以从不同维度分析,使用得当,会如大浪淘沙般,发现属于我们的金子.

对一般网站来说,带宽是最珍贵的资源,可能一不小心,某些资源如文件、图片就占用了大量的带宽,执行命令检查一下：

less static.log | awk 'url=$7; requests[url]++;bytes[url]+=$10} 
END{for(url in requests){printf("%sMB %sKB/req %s %s\n",bytes[url] / 
1024 / 1024,bytes[url] /requests[url] / 1024,requests[url],url)}}' | sort -nr | head -n 15

备注：Nginx配置文件中日志格式使用了$body_sent_size,指HTTP响应体的大小,如果想查看整个响应的大小,应该使用变量$sent_size.

不出意外,静态资源、图片类(如果还没有放CDN)占据榜首,自然也是优化的重点：是否可以再压缩,某些页面中是否可以用缩略图片代替等.

与之相比,后台调用、API接口等通常消耗更多的CPU资源,按照一贯“先衡量、再优化”的思路,可以根据响应时间大体了解某个URL占用的CPU时间：

less main.log | awk '{url=$7; times[url]++} END{for(url in times){printf("%s %s\n",times[url],url)}}' | sort -nr | more` 

?40404 /page/a?from=index ? 

?1074 /categories/food ? 

?572 /api/orders/1234.json

不对,发现一个问题：由于拥有服务号、App、PC浏览器等多种前端,并且使用不规范,URL的格式可能乱七八糟.比如`/page/a`页面,有的带有.html后缀,有的未带,有的请求路径则带有参数；分类页/categories/food带有`slug`等信息；订单、详情或个人中心的URL路径则有`ID`等标记….

借助sed命令,通过三个方法对URL格式进行归一化处理：去掉所有的参数；去掉`.html`及`.json`后缀；把数字替换为`*`.可以得到更准确的统计结果,：

less main.log | awk '{print $7}' |sed -re 's/(.*)\?.*/\1/g' -e

 's/(.*)\..*/\1/g' -e 's:/[0-9]+:/*:g' | awk '{requests[$1]++;time[$1] 

+=$2} END{for(url in requests){printf("%smin %ss/req %s %s\n",time

 [url] / 60,time[url] /requests[url],url)}}' | sort -nr | head -n 50

备注：这里使用了扩展正则表达式,GNU sed的参数为-r,BSD sed的参数为-E.

（编辑：ASP站长网）