编辑｜小智
对很多开拓运维职员来说，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），或者查看某个特定的页面，最近有没有被爬虫爬过：
数据见告我们，页面索引量上不去，不一定是某个爬虫未检索到页面，更多的是其他缘故原由。
市场团队要上一个新品并且做匆匆销活动，你建议避开周一周五，由于周三周四的转化率更高：
周三、周四的转换率比周末高不少，可能跟平台的发货周期有关，客户周三四下单，希望周末就能收到货，开始快乐的周末。你预测到用户的生理和期望，连数据一起交市场品团队，期待更好地改进。
这样的例子可以有很多。事实上，上述剖析限于 Nginx 日志，如果有系统日志，并且日志格式定义良好，可以做的事情远不止于此：这是一个韶光序列数据库，可以查询 IT 系统的运行情形，可以剖析营销活动的效果，也可以预测业务数据的趋势；这是一个比较小但够用的大数据源，利用你学会的大数据剖析方法，也可以像滴滴那样，分并预测不同景象、韶光段下不同地区的车辆供需，并作出优化。
几点建议
规范日志格式。这是很多团队随意马虎忽略的地方，有时候多一个空格会让日志剖析的繁芜度大为增加。
无论如何，利用韶光戳字段。以韶光序列的办法看待日志文件，这也是很多公司把系统日志直接写入到韶光序列数据库的缘故原由；
如有可能，记录以下字段：用户（或者客户端）标识、单次要求标识、运用标识（如果单次要求会走到多个运用）。能够方便地查出用户链路、要求链路，是排查缺点要求、剖析用户行为的根本；
关注写的操作。就像业务建模时，须要特殊关注具有时标性、状态会发生改变的模型一样，任何写的操作，都应记录到日志系统中。万一某个业务出错，不但可以通过业务模型复演，也可以通过日志系统复演。
规范 URL 格式。这一点同样随意马虎遭到忽略，商品详情页面要不要添加\"大众?from=XXX\"大众来源参数？支付页面采取路径标记“payment/alipay”，还是参数标记“/payment?type=alipay”更得当？差异细微但影响不可忽略。
技能团队该当像对待协议一样对待这些规范。仔细定义并严格遵守，相称于拿到了金矿的钥匙。
还须要探求一个得当的日志剖析工具，基于 Python、Go、Lua，都有免费的日志剖析工具可供给用；想更轻量，准备几条常用的 shell 脚本，比如作者整理了一些到 GitHub 的这个项目上（https://github.com/aqingsao/nana）；或者基于 ELK 技能栈，把 Nginx 访问日志、业务日志统一存储，并通过 Kibana 进行不同维度的聚合剖析，都是不错的办法。
或许你早就利用 Nginx 日志了，你是怎么利用的，有什么好的方法呢，欢迎一起互换。
今日荐文
点击下方图片即可阅读
蚂蚁金服 CTO 程立：技能的代价与意义，在我看来是这样的
