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

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

对不少开发运维人员来讲，Nginx 日志文件在被删除前可能都不会看上一眼。但实际上，Nginx 隐藏了至关丰富的信息，或许其中便蕴含着未知的金矿等你挖掘！

写在前面
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 的请求都较快，一般是用户手机或网络情况不佳引发的。最简单的方法，统计慢查询所占比例：
慢查询所占比例极低，再根据用户手机型号、访问时间、访问页面等信息看可否定位到指定的请求，结合先后不一样用户的请求，就能够肯定是否用户的网络情况很差了。

第二步：
是否是应用系统的瓶颈？对比应用服务器的返回时间 ($upstream_response_time 字段），与 Nginx 服务器的处理时间 ($request_time 字段)，先快速排查是否某一台服务器抽风。
咱们遇到过相似问题，平均响应时间 90ms，还算正常，但某台服务器明显变慢，平均响应时间达到了 200ms，影响了部分用户的访问体验。
不幸，市场部这次推广活动，访问压力增大，全部服务器都在变慢，更多是应用系统的性能达到了瓶颈。若是此时带宽都没跑满，在硬件扩容以前，考虑优化重点 API、缓存、静态化策略吧，达到一个基本的要求：“优化系统，让瓶颈落到带宽上”。

第三步：
应用系统没有瓶颈，是带宽的问题？快速查看一下每秒的流量：
峰值带宽接近出口带宽最大值了，幸福的烦恼，利用前面介绍的不一样 URL 的带宽统计，作定向优化，或者加带宽吧。
还能作哪些优化？
SEO 团队抱怨优化了那么久，为何页面索引量和排名上不去。打印出不一样爬虫的请求频次（$http_user_agent），或者查看某个特定的页面，最近有没有被爬虫爬过：
数据告诉咱们，页面索引量上不去，不必定是某个爬虫未检索到页面，更多的是其余缘由。
市场团队要上一个新品而且作促销活动，你建议避开周一周五，由于周三周四的转化率更高：

周3、周四的转换率比周末高很多，可能跟平台的发货周期有关，客户周三四下单，但愿周末就能收到货，开始快乐的周末。你猜想到用户的心理和指望，连数据一块儿交市场品团队，期待更好地改善。
这样的例子能够有不少。事实上，上述分析限于 Nginx 日志，若是有系统日志，而且日志格式定义良好，能够作的事情远不止于此：这是一个时间序列数据库，能够查询 IT 系统的运行状况，能够分析营销活动的效果，也能够预测业务数据的趋势；这是一个比较小但够用的大数据源，运用你学会的大数据分析方法，也能够像滴滴那样，分并预测不一样天气、时间段下不一样地区的车辆供需，并做出优化。

几点建议

规范日志格式。这是不少团队容易忽略的地方，有时候多一个空格会让日志分析的复杂度大为增长。
不管如何，使用时间戳字段。以时间序列的方式看待日志文件，这也是不少公司把系统日志直接写入到时间序列数据库的缘由；
若有可能，记录如下字段：用户（或者客户端）标识、单次请求标识、应用标识（若是单次请求会走到多个应用）。可以方便地查出用户链路、请求链路，是排查错误请求、分析用户行为的基础；
关注写的操做。就像业务建模时，须要特别关注具备时标性、状态会发生改变的模型同样，任何写的操做，都应记录到日志系统中。万一某个业务出错，不但能够经过业务模型复演，也能够经过日志系统复演。
规范 URL 格式。这一点一样容易遭到忽略，商品详情页面要不要添加"?from=XXX"来源参数？支付页面采用路径标记“payment/alipay”，仍是参数标记“/payment?type=alipay”更合适？区别细微但影响不可忽略。
技术团队应该像对待协议同样对待这些规范。仔细定义并严格遵照，至关于拿到了金矿的钥匙。
还须要寻找一个合适的日志分析工具，基于 Python、Go、Lua，都有免费的日志分析工具可供使用；想更轻量，准备几条经常使用的 shell 脚本，好比做者整理了一些到 GitHub 的这个项目上（https://github.com/aqingsao/nana）；或者基于 ELK 技术栈，把 Nginx 访问日志、业务日志统一存储，并经过 Kibana 进行不一样维度的聚合分析，都是不错的办法。