如何挖掘Nginx日志中隐藏的金矿？
|
那些累计占用了更多响应时间的请求,通常也耗用了更多的CPU时间,是性能优化重点照顾的对象. 慢查询分析“服务号刚推送了文章,有用户反映点开很慢”,你刚端起桌子上的水杯,就听到产品经理的大嗓门从办公室角落呼啸而来.“用户用的什么网络”,你一边问着,一边打开服务号亲自尝试一下.是用户网络环境不好,还是后台系统有了访问压力?是这一个用户慢,还是很多用户都慢?你一边脑子里在翻腾,一边又打开命令行去查看日志. 与PC浏览器相比,微信服务号在网络环境、页面渲染上有较大的掣肘,在缓存策略上也不如APP自如,有时会遇到诡异的问题.如果手里恰好有Nginx日志,能做点什么呢? 考虑一下MySQL数据库,可以打开慢查询功能,定期查找并优化慢查询,与此类似,Nginx日志中的响应时间,不相当于自带慢查询功能嘛.利用这一特性,我们分步进行慢查询分析： 第一步：是不是用户的网络状况不好?根据既往的经验,如果只有少量的请求较慢,而前后其他IP的请求都较快,通常是用户手机或网络状况不佳引起的.最简单的方法,统计慢查询所占比例： less main.log | awk -v limit=2 '{min=substr($4,17);reqs[min]
++;if($11>limit){slowReqs[min]++}} END{for(m in slowReqs){printf("%s %s %s%s %sn",m,slowReqs[m]/reqs[m] * 100,"%",slowReqs[m],reqs [m])}}' | more ? ?
10/Apr/2016:12:51 0.367% 7 1905 ?
?10/Apr/2016:12:52 0.638% 12 1882 ? ?
10/Apr/2016:12:53 0.548% 14 2554
慢查询所占比例极低,再根据用户手机型号、访问时间、访问页面等信息看能否定位到指定的请求,结合前后不同用户的请求,就可以确定是否用户的网络状况不好了. 第二步：是不是应用系统的瓶颈?对比应用服务器的返回时间($upstream_response_time字段),与Nginx服务器的处理时间($request_time字段),先快速排查是否某一台服务器抽风. 我们遇到过类似问题,平均响应时间90ms,还算正常,但某台服务器明显变慢,平均响应时间达到了200ms,影响了部分用户的访问体验. less main.log | awk '{upServer=$13;upTime=$12;if(upServer == "-"){upServer="Nginx"};if(upTime == "-"){upTime=0};upTimes[upServer] +=upTime;count[upServer]++;totalCount++;} END{for(server in upTimes) {printf("%s %s%s %ss %sn",count[server],count[server]/totalCount * 100,upTimes[server]/count[server],server)}}' | sort -nr
不幸,市场部此次推广活动,访问压力增大,所有服务器都在变慢,更可能是应用系统的性能达到了瓶颈.如果此时带宽都没跑满,在硬件扩容之前,考虑优化重点API、缓存、静态化策略吧,达到一个基本的要求：“优化系统,让瓶颈落到带宽上”. 第三步：应用系统没有瓶颈,是带宽的问题?快速查看一下每秒的流量： less main.log | awk '{second=substr($4,20);bytes[second]+=$10;} END{for(s in bytes){printf("%sKB %sn",bytes[s]/1024,s)}}' | more` ? ?1949.95KB 10/Apr/2016:12:53:15 ? ?2819.1KB 10/Apr/2016:12:53:16 ? ?3463.64KB 10/Apr/2016:12:53:17 ? ?3419.21KB 10/Apr/2016:12:53:18 ? ?2851.37KB 10/Apr/2016:12:53:19
峰值带宽接近出口带宽最大值了,幸福的烦恼,利用前面介绍的不同URL的带宽统计,做定向优化,或者加带宽吧. 还能做哪些优化?SEO团队抱怨优化了那么久,为什么页面索引量和排名上不去.打印出不同爬虫的请求频次($http_user_agent),或者查看某个特定的页面,最近有没有被爬虫爬过： less main.log | egrep 'spider|bot' | awk '{name=$17;if(index ($15,"spider")>0){name=$15};spiders[name]++} END{for(name in spiders) {printf("%s %sn",spiders[name],name)}}' | sort -nr
数据告诉我们,页面索引量上不去,不一定是某个爬虫未检索到页面,更多的是其他原因. 市场团队要上一个新品并且做促销活动,你建议避开周一周五,因为周三周四的转化率更高：
周三、周四的转换率比周末高不少,可能跟平台的发货周期有关,客户周三四下单,希望周末就能收到货,开始快乐的周末.你猜测到用户的心理和期望,连数据一起交市场品团队,期待更好地改善. 这样的例子可以有很多.事实上,上述分析限于Nginx日志,如果有系统日志,并且日志格式定义良好,可以做的事情远不止于此：这是一个时间序列数据库,可以查询IT系统的运行情况,可以分析营销活动的效果,也可以预测业务数据的趋势；这是一个比较小但够用的大数据源,运用你学会的大数据分析方法,也可以像滴滴那样,分并预测不同天气、时间段下不同地区的车辆供需,并作出优化. 几点建议
技术团队应该像对待协议一样对待这些规范.仔细定义并严格遵守,相当于拿到了金矿的钥匙. （编辑：温州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
