Nginx（读作Engine-X）是现在最流行的负载均衡和反向代理服务器之一。如果你是一名中小微型网站的开发运维人员，很可能像我们一样，仅Nginx每天就会产生上百M甚至数以十G的日志文件。如果没有出什么错误，在被logrotate定期分割并滚动删除以前，这些日志文件可能都不会被看上一眼。 实际上，Nginx日志文件可以记录的信息相当丰富，而且格式可以定制，考虑到`$time_local`请求时间字段几乎必有，这是一个典型的基于文件的时间序列数据库。Nginx日志被删除以前，或许我们可以想想，其中是否蕴含着未知的金矿等待挖掘？ 请求访问分析 Nginx中的每条记录是一个单独的请求，可能是某个页面或静态资源的访问，也可能是某个API的调用。通过几条简单的命令，了解一下系统的访问压力：
请求总数、平均每秒请求数、峰值请求数，可以大体了解系统压力，作为系统扩容、性能及压力测试时的直接参考。查询特定的URL，比如下单页面，了解每天的下单状况，导出CSV格式，或使用可视化工具，更直观地了解一段时间内的请求、下单数据： 备注：本文使用awk命令处理，与Nginx日志的格式有关，如果您格式不同，请酌情修改命令。本文所用的Nginx日志格式：
示例：
流量速率分析 Nginx日志如果开启，除了请求时间，一般会包含响应时间、页面尺寸等字段，据此很容易计算出网络流量、速率。 等等，你可能会有疑问，上面的请求访问分析，这里的流量速率分析，按时间轴画出来，不就是监控系统干的事儿吗，何苦这么麻烦查询Nginx日志？ 的确如此，监控系统提供了更实时、更直观的方式。而Nginx日志文件的原始数据，可以从不同维度分析，使用得当，会如大浪淘沙般，发现属于我们的金子。 对一般网站来说，带宽是最珍贵的资源，可能一不小心，某些资源如文件、图片就占用了大量的带宽，执行命令检查一下：
备注：Nginx配置文件中日志格式使用了$body_sent_size，指HTTP响应体的大小，如果想查看整个响应的大小，应该使用变量$sent_size。 不出意外，静态资源、图片类（如果还没有放CDN）占据榜首，自然也是优化的重点：是否可以再压缩，某些页面中是否可以用缩略图片代替等。 与之相比，后台调用、API接口等通常消耗更多的CPU资源，按照一贯“先衡量、再优化”的思路，可以根据响应时间大体了解某个URL占用的CPU时间：
不对，发现一个问题：由于拥有服务号、App、PC浏览器等多种前端，并且使用不规范，URL的格式可能乱七八糟。比如`/page/a`页面，有的带有.html后缀，有的未带，有的请求路径则带有参数；分类页/categories/food带有`slug`等信息；订单、详情或个人中心的URL路径则有`ID`等标记...。 借助sed命令，通过三个方法对URL格式进行归一化处理：去掉所有的参数；去掉`.html`及`.json`后缀；把数字替换为`*`。可以得到更准确的统计结果，：
备注：这里使用了扩展正则表达式，GNU sed的参数为-r，BSD sed的参数为-E。 那些累计占用了更多响应时间的请求，通常也耗用了更多的CPU时间，是性能优化重点照顾的对象。 慢查询分析 “服务号刚推送了文章，有用户反映点开很慢”，你刚端起桌子上的水杯，就听到产品经理的大嗓门从办公室角落呼啸而来。“用户用的什么网络”，你一边问着，一边打开服务号亲自尝试一下。是用户网络环境不好，还是后台系统有了访问压力？是这一个用户慢，还是很多用户都慢？你一边脑子里在翻腾，一边又打开命令行去查看日志。 与PC浏览器相比，微信服务号在网络环境、页面渲染上有较大的掣肘，在缓存策略上也不如APP自如，有时会遇到诡异的问题。如果手里恰好有Nginx日志，能做点什么呢？ 考虑一下MySQL数据库，可以打开慢查询功能，定期查找并优化慢查询，与此类似，Nginx日志中的响应时间，不相当于自带慢查询功能嘛。利用这一特性，我们分步进行慢查询分析： 第一步：是不是用户的网络状况不好？根据既往的经验，如果只有少量的请求较慢，而前后其他IP的请求都较快，通常是用户手机或网络状况不佳引起的。最简单的方法，统计慢查询所占比例：
|
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
