欢迎您访问 最编程 本站为您分享编程语言代码,编程技术文章!
您现在的位置是: 首页

NGINX 日志配置。如何查看和分析访问日志和错误日志

最编程 2024-06-03 13:51:05
...

nginx logs

NGINX是最广泛使用的反向代理服务器、网络服务器和负载均衡器之一。它具有TLS卸载等功能,可以对后端进行健康检查,并提供对HTTP2、gRPC、WebSocket和大多数基于TCP协议的支持。

当运行像NGINX这样的工具时,它通常位于你的应用程序前面,了解如何调试问题很重要。而且因为你需要看到日志,你必须了解不同的NGINX日志机制。除了你的应用程序或Web服务器中的错误外,你还需要研究NGINX的性能问题,因为它们会导致SLA的破坏、负面的用户体验等等。

在这篇文章中,我们将探讨NGINX提供的日志类型,以及如何正确配置它们以使故障排除更容易

什么是NGINX日志?

NGINX日志是包含与NGINX服务器执行的任务有关的信息的文件,比如谁试图访问哪些资源,是否有任何错误或问题发生。

NGINX提供两种类型的日志:访问日志和错误日志。在我们向你展示如何配置它们之前,让我们看看可能的日志类型和不同的日志级别。

这里是最基本的NGINX配置。

http{
    server {
        listen       80;
        server_name  example.com www.example.com;
        access_log   /var/log/nginx/access.log  combined;
        root         /var/www/virtual/big.server.com/htdocs;
    }
}

对于这个服务器,我们打开了80端口。服务器名称是 "example.com www.example.com"。你可以看到访问日志和错误日志的配置,以及指令的根,它定义了从哪里提供文件。

什么是NGINX访问日志?

NGINX访问日志是拥有客户端在NGINX服务器*问的所有资源信息的文件,例如关于正在访问的内容和如何响应请求的细节,包括客户端IP地址、响应状态代码、用户代理等等。所有发送到NGINX的请求在请求被处理后就会被记录到NGINX的日志中。

下面是你应该注意的一些重要的NGINX访问日志字段

  • remote_addr: 请求资源的客户端的IP地址
  • http_user_agent。发送请求的用户代理
  • time_local。服务器的本地时区
  • request。客户端请求的资源(一个API路径或任何文件)。
  • status。响应的状态代码
  • body_bytes_sent。响应的大小,以字节为单位
  • request_time:处理该请求的总时间
  • remote_user:关于提出请求的用户的信息
  • http_referer。HTTP引用者的IP地址
  • gzip_ratio。如果gzip被启用,gzip的压缩率。

NGINX访问日志的位置

你可以在logs/access.log文件中找到访问日志,并通过使用NGINX配置文件中的access_log指令改变其位置。

access_log path [format [buffer=size] [gzip[=level]] [flush=time] [if=condition]];
access_log /var/log/nginx/access.log combined

通过改变access_log指令中的路径字段,你也可以改变你想保存访问日志的位置。

一个NGINX访问日志配置可以被另一个更低层次的配置所覆盖。比如说。

http {
  access_log  /var/log/nginx/access.log  main;
  server {
    listen 8000;
    location /health {
      access_log off; # <----- this WILL work
      proxy_pass http://app1server;
    }
  }
}

这里,任何对/health的调用都不会被记录,因为这个路径的访问日志被禁用。所有其他的调用将被记录到访问日志中。有一个全局配置,也有不同的本地配置。NGINX配置文件中的其他配置也是如此。

如何启用NGINX访问日志

大多数情况下,NGINX访问日志是默认启用的。要手动启用它们,你可以使用access_log指令,如下所示。

access_log /var/log/nginx/access.log combined

第一个参数是文件的位置,第二个参数是日志的格式。如果你把access_log指令放在任何一个服务器目录中,它将启动访问日志。

设置NGINX自定义日志格式

要轻松地预先定义NGINX访问日志格式,并与access_log指令一起使用,请使用log_format指令。

log_format upstream_time '$remote_addr - $remote_user [$time_local] '
    '"$request" $status $body_bytes_sent '
    '"$http_referer" "$http_user_agent"'
    'rt=$request_time uct="$upstream_connect_time" uht="$upstream_header_time" urt="$upstream_response_time"';

这里的大部分字段都是不言自明的,但如果你想了解更多,可以查阅NGINX的日志配置你可以在/etc/nginx/nginx.conf文件的HTTP上下文中指定日志格式,然后在服务器上下文中使用它们。

默认情况下,NGINX访问日志是以组合格式写入的,看起来像这样。

log_format combined '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent"';

一旦你定义了日志格式,你就可以用access_log指令来使用它们,比如下面的例子。

server {
    access_log /var/log/nginx/access.log combined
    access_log /var/log/nginx/access.log upstream_time #defined in the first format
    …
}

将日志格式化为JSON

当你想发送NGINX日志时,记录为JSON是很有用的,因为JSON使日志解析非常容易。因为你有键值信息,消费者理解起来会更简单。否则,解析就必须理解NGINX的日志格式。

NGINX 1.11.8有一个escape=json设置,它可以帮助你定义NGINX的JSON日志格式。比如说。

log_format json_combined escape=json
  '{'
    '"time_local":"$time_local",'
    '"remote_addr":"$remote_addr",'
    '"remote_user":"$remote_user",'
    '"request":"$request",'
    '"status": "$status",'
    '"body_bytes_sent":"$body_bytes_sent",'
    '"http_referrer":"$http_referer",'
    '"http_user_agent":"$http_user_agent",'
    '"request_time":"$request_time"'
  '}';

你现在可以使用这个预定义的JSON日志格式,用access_log指令来获取JSON格式的日志。

你也可以使用一个开源的NGINX模块,比如github.com/jiaz/nginx-…来做JSON日志记录。

配置NGINX的条件性日志

有时,你想只在满足某个条件时写日志。NGINX称这为条件性日志。比如说。

map $remote_addr $log_enable {
    "192.168.4.1" 0;
    "192.168.4.2" 0;
    "192.168.4.3" 0;
    "192.168.4.4" 0;
    default 1;
}
access_log /var/log/nginx/access.log combined if=$log_enable

这意味着,只要请求来自192.168.4.1到192.168.4.4的IP,访问日志就不会被填充。对于其他每一个IP,日志将被记录。

你可以在多种情况下使用NGINX的条件性日志记录。例如,如果你受到攻击并能确定攻击者的IP,你可以将请求记录到一个不同的文件。这使你能够处理该文件,并在以后获得关于攻击的相关信息。

如何查看NGINX访问日志

Linux工具,如LESS或TAIL,可以让你轻松查看NGINX的日志。你也可以从配置文件中看到NGINX访问日志的位置。对于运行systemd的新系统,journalctl功能可以跟踪日志。要查看日志,请使用此命令。

journalctl -fu nginx.service

你也可以跟踪日志的位置,如图所示。

tail -f /var/log/nginx/access.log

也可以使用 journalctl,但这样会把所有的日志都显示在一起,可能会有点混乱。

如何禁用访问日志

要禁用NGINX的访问日志,可以向access_log指令传递off参数。

access_log off;

当有太多的日志时,这可能是有用的,这可能会使磁盘IO过载,在极少数情况下,会影响你的NGINX服务器的性能。然而,通常不建议禁用NGINX访问日志,因为它可能使故障排除变得困难。

什么是NGINX错误日志?

NGINX错误日志是记录所有错误信息的文件,包括权限错误或任何NGINX配置相关的访问错误。虽然访问日志用于查看服务器收到的HTTP请求,但错误日志带来了更多的价值,因为当出现问题时,它们会准确显示发生了什么,并提供关于问题的详细信息。

每当请求出现错误,或者NGINX出现故障时,这些问题将被记录在NGINX配置文件中配置的错误日志文件中。

NGINX错误日志存放在哪里?

NGINX错误日志的位置可以在NGINX配置的error_log指令中进行配置。默认情况下,这些日志是在/var/log/nginx目录下。你可以为你可以在NGINX配置中运行的不同服务器组件分别配置位置。

默认的位置是。

 /var/log/nginx/error.log

NGINX错误日志配置

NGINX错误日志的配置与access_log在同一个地方。你可以使用error_log指令来启用和配置日志级别和日志文件的位置。下面是启用error_log的配置行。

error_log log_file_location log_level;

NGINX错误日志级别

NGINX有八个日志级别,用于不同程度的严重性和粗暴性。

  1. emerg:这些是紧急日志。它们意味着系统无法使用。
  2. alert: 需要立即采取行动。
  3. crit。一个关键条件发生了。
  4. 错误。在处理一个请求时发生了一个错误或失败。
  5. warn。有一个意外的事件,或者有些东西需要修复,但NGINX按照预期完成了请求。
  6. 通知。发生了一些正常但重要的事情,需要加以注意。
  7. 信息。这些是给你提供有关进程信息的消息。
  8. debug。这些是有助于调试和排除故障的信息。除非需要,一般不启用它们,因为它们会产生大量的噪音。

注意,log_level参数是一个阈值,因为每个日志级别也包括之前的日志级别。例如,如果你的日志级别是6(注意),你的日志将包含从1到6级的条目。

启用调试日志和其他级别

你可以用error_log指令中的log_level参数来指定日志级别。随着日志级别数的增加,日志将包含更多的信息。如果应用程序行为不正常,你可以启用调试日志来帮助你进行故障排除。有了它们提供的额外信息,你将能够更容易地确定问题的所在。[c]你可以在NGINX文档中更深入地阅读这方面的内容。

不建议持续启用NGINX调试日志,因为它将通过打印一般不需要的信息使日志变得非常嘈杂和庞大。如果你看到一个问题,你可以临时改变日志级别,解决这个问题,然后再把它恢复到更严格的级别。

记录到多个文件

你可以根据不同的日志级别将NGINX错误日志转发到不同的文件。在下面的配置中,你是根据日志的严重程度将日志发送到所有指定的日志指令中。

error_log /var/log/nginx/error.info info;
error_log /var/log/nginx/error.crit crit;

当你想分别查看不同的日志级别时,或者你想让你的日志代理根据文件名来标记这些日志时,这种配置就非常有用。你可以根据错误日志的严重程度有选择地丢弃它们。

如何检查NGINX错误日志

你可以用与访问日志相同的方式查看NGINX错误日志:例如,通过使用TAIL、LESS或其他实用工具。下面是一个例子,说明如何用TAIL使用你设置的error_logs的位置来做。这些日志也存在于 journalctl 日志中,但在那里,它们将是 access_log 和 error_logs 的组合。

tail -f /var/log/nginx/error.log

如何禁用错误日志

禁用NGINX错误日志可能很棘手,因为error_log中没有关闭选项。与较低配置级别中的access_log类似,你可以在较高级别的配置中使用error_log false。

error_log off;

对于较低级别,你可以把日志转发到/dev/null。

error_log /dev/null;

如何发送NGINX日志到Syslog

NGINX也可以使用syslog将你的日志发送到日志聚合器。当你在syslog中记录其他系统/服务日志或使用syslog导出日志时,这可能很有用。你可以用syslog: 前缀来实现这一点,它可以用于access_log和error_logs。你也可以用这个前缀来代替access_log和error_log指令中的文件路径。

Syslog可以帮助你把NGINX的日志集中在一个地方,把它们转发到一个 集中的日志解决方案

error_log syslog:unix/var/log/nginx.sock debug

你也可以通过定义syslog服务器参数来指向syslog服务器的IP或主机名和端口,将日志发送到不同的syslog服务器。

error_log syslog:server=192.168.100.1 debug
access_log syslog:server=[127.0.0.1]:9992, facility=local1,tag=nginx,severity=debug;

在上述access_log的配置中,日志被转发到本地的syslog服务器,服务名称为local1,因为syslog对NGINX没有选项

Syslog有各种选项来保持转发的日志被隔离。

  • 设施。识别谁在向syslog记录。
  • 严重程度。指定日志级别。
  • 标签。 识别消息发送者或你想发送的任何其他信息;默认为NGINX。

Kubernetes环境下的NGINX日志记录

在Kubernetes中,NGINX Ingress作为一个pod运行。NGINX Ingress pods的所有日志都被发送到标准输出和错误日志。然而,如果你想看到这些日志,你必须登录到pod或使用kubectl命令,这不是一个非常实用的解决方案。

你还必须找到一种方法,从容器中运送日志。你可以用任何在Kubernetes环境中运行的日志代理来做这个。这些代理作为豆荚运行,挂载NGINX运行的文件系统,从那里读取日志。

如何查看NGINX的Ingress日志

使用kubectl logs命令来查看NGINX的日志流。

$ kubectl logs -f nginx-ingress-pod-name -n namespace.

重要的是要明白,pod可以来来去去,所以在Kubernetes环境中调试问题的方法与在基于VM或裸机的环境中有点不同。在Kubernetes中,日志代理应该能够发现NGINX Ingress pods,然后从那里刮取日志。另外,日志聚合器应该显示被杀死的pod的日志,并发现任何新上线的pod。

NGINX日志和Sematext的分析

NGINX日志与Sematext的整合

Sematext Logs是一个日志聚合和管理工具,对NGINX日志有很大的支持。它的自动发现功能很有帮助,特别是当你有多台机器时。只需在Sematext创建一个账户,然后创建NGINX Logs App并安装Sematext Agent。一旦你设置好了,你就会得到预建的、开箱即用的仪表盘,以及建立你自己的自定义仪表盘的选项。

Sematext Logs是Sematext Cloud的一部分,它是一个全栈监控解决方案,为你提供所有你需要的观察能力。通过关联NGINX日志和指标,你会得到一个更全面的基础设施视图,这有助于你快速识别和解决问题。

使用异常检测算法,Sematext Cloud会提前通知你任何潜在的问题。这些对你的基础设施的洞察力可以帮助你预防问题和更有效地排除故障。通过Sematext Cloud,你还可以收集各种工具的日志和指标,包括HAProxyApache TomcatJVMKubernetes。通过与基础设施的其他组件集成,这个工具是一个一站式的解决方案,可以满足你所有的日志和监控需求。

总结

管理、排除故障和调试大规模的NGINX基础设施可能是一个挑战,特别是如果你没有一个适当的方法来查看日志和指标。了解NGINX的访问和错误日志很重要,但如果你有数百台机器,这将需要大量的时间。你需要能够在一个地方看到汇总的日志。

性能问题也比你想象的更常见。例如,你可能在错误日志中没有看到任何东西,但你的API却在继续退化。为了正确地研究这个问题,你需要围绕NGINX性能指标的有效仪表盘,如响应代码和响应时间。

Sematext Logs可以帮助你解决这些问题,以便你能更快地排除故障。今天就注册参加我们的免费试用吧。

作者简介

Gaurav Yadav
Gaurav从事系统和基础设施工作已近6年。他在设计底层基础设施和大规模软件的可观察性方面有专长。他曾在Docker、Kubernetes、Prometheus、Mesos、Marathon、Redis、Chef等基础设施工具上工作。他目前正在研究Kubernetes运营商,用于在Kubernetes上运行和监控有状态服务。他还喜欢通过他的倡议Learnsteps和Letusdevops来写关于DevOps和SRE领域的文章,并指导人们。

帖子《NGINX日志配置。如何查看和分析访问和错误日志》首次出现在Sematext上。