Nginx 日志自定义记录及启用日志缓冲区

如果想统计网站的访问来源信息，可以用 php 获取信息，记录到数据库的形式，也可以直接使用 nginx 提供的访问日志，来记录网站的访问详情，管理员可以通过分析 nginx 的访问日志，来分析用户的访问来源，访问行为详情，网站页面访问热度等。此外，nginx 自身也有错误日志，方便运维人员调试 nginx。对于记录日志的行为，如果每次进行磁盘操作，将会较多的耗费资源，基于这个情况可以开启 nginx 日志缓冲区，缓冲区满或者定时写入的时间到了，再一次写入日志。

访问日志

nginx 在处理请求后立即在访问日志中写入有关客户端请求的信息。默认情况下，访问日志位 logs/access.log 中，信息以预定义的组合格式写入日志。
想要精确记录访问信息，就需要自定义一个更加完整的访问日志格式，如下所示：

http {
    log_format geoproxy
    '[$time_local] $remote_addr '
    '$realip_remote_addr $remote_user '
    '$request_method $server_protocol '
    '$scheme $server_name $uri $status '
    '$request_time $body_bytes_sent '
    '$geoip_city_country_code3 $geoip_region '
    '"$geoip_city" $http_x_forwarded_for '
    '$upstream_status $upstream_response_time '
    '"$http_referer" "$http_user_agent"';
    ...
}

这个日志配置被命名为 geoproxy，它使用许多 nginx 变量来演示 nginx 日志记录功能。详细讲解配置选项中各个变量的具体含义：
当用户发起请求时，会记录服务器时间 $time_local, $remote_user 值为通过基本授权的用户名称；
用于 nginx 处理 geoip_proxy 和 realip_header 指令的打开连接的 IP 地址和客户端 IP 地址；
之后记录 HTTP 请求方法 $request_method、协议 $server_protocol 和 HTTP 方法 $scheme：http 或 https；
当然还有服务器名称 $server_name、请求的 URI 和响应状态码；
除基本信息外，还有一些统计的结果数据：包括请求处理的毫秒级时间 $request_time、服务器响应的数据块大小 $body_bytes_sent；此外，客户端所在国家 $geoip_city_country_code3、地区 $geoip_region 和城市信息 $geoip_city 也被记录在内；
变量 $http_x_forwarded_for 用于记录由其它代理服务器发起的请求的 X-Forwarded-For 头消息；
upstream 模块中一些数据也被记录到日志里：被代理服务器的响应状态码 $upstream_status 、建立链接和从上游服务器接收响应主体最后一个字节的时间 $upstream_response_time、建立和上游服务器的链接时间 $upstream_connect_time、建立链接和从上游响应头的第一个字节的时间 $upstream_header_time。
请求来源 $http_referer 和用户代理 $http_user_agent 也可以被记录在日志里；
nginx 的日志记录功能非常强大和灵活的，需要注意的是：用于定义日志格式的 log_format 指令仅适用于 http 块级指令内，所有时间值均以毫秒为单位，以毫秒分辨率进行测量。。

这个格式的日志配置将产生如下类型的日志：

[25/Feb/2019:16:20:42 +0000] 10.0.1.16 192.168.0.122 Derek
GET HTTP/1.1 http www.example.com / 200 0.001 370 USA MI
"Ann Arbor" - 200 0.001 "-" "curl/7.47.0"

如果需要使用这个日志配置，需要结合使用 access_log 指令，access_log指令接收一个日志目录和使用的配置名作为参数：

server {
    access_log /var/log/nginx/access.log geoproxy;
    ...
}

access_log 能在多个上下文使用，每个上下文中可以定义各自的日志目录和日志记录格式。

结论：

nginx 中的日志模块允许为不同的场景配置日志格式，以便查看不同的日志文件。
在实际运用中，为不同上下文配置不同的日志会非常有用，记录的日志内容可以简单的信息，也可以详细记录所有必要信息。不仅如此，日志内容除了支持文本
也能记录 json 格式和 xml 格式数据。实际上 nginx 日志有助于您了解服务器流量、客户端使用情况和客户端来源等信息。此外，访问日志还可以帮助您定位与上游服务器或特定 uri 相关的响应和问题；对于测试来讲，访问日志同样有用，它可以用于分析流量情况，模拟真实的用户交互场景。日志在故障排除、调试、应用分析及业务调整中作用是不可或缺的。

错误日志

为了精确定位 nginx 的错误日志，使用自带的 error_log 指令定义错误日志目录及记录错误日志的等级，配置如下：

error_log /var/log/nginx/error.log warn;

error_log 指令配置时需要一个必选的日志目录和一个可选的错误等级选项。
除 if 指令外，error_log 指令能在所有的上下文中使用。错误日志等级包括：debug、info、notice、warn、error、crit、alert 和 emerg。给出的日志
等级顺序就是记录最小到最严谨的日志等级顺序。需要注意的是 debug 日志
需要在编译 nginx 服务器时，带上 --with-debug 标识才能使用。

当服务器配置出错时，首先需要查看错误日志以定位问题。错误日志
也是定位应用服务器(如 FastCGI 服务)的利器。通过错误日志，我们可以调试 worker 进程连接错误、内存分配、客户端 IP 和应用服务器等问题。错误日志格式不支持自定义日志格式；但他同样记录当前时间、日志等级和具体信息等数据。

注意：

错误日志的默认设置适用于全局。要覆盖它，请将 error_log 指令放在 main（顶级）配置上下文中。error_log在开源 NGINX 1.5.2 版中添加了在同一配置级别指定多个指令的功能。

通过 syslog 将日志发送到统一服务器

既然不再需要将日志写到磁盘的某个目录，而是发送到统一的日志服务器，则将原有的目录部分替换为服务器 ip 即可，配置如下：

error_log syslog:server=10.0.1.42 debug;
access_log syslog:server=10.0.1.42,tag=nginx,severity=info geoproxy;

#error_log server=unix:/var/log/nginx.sock debug;
#access_log syslog:server=[2001:db8::1]:1234,facility=local7,tag=nginx,severity=info;

error_log 和 access_log 指令的 syslog 参数紧跟冒号 : 和一些参数选项。包括：必选的 server 标记表示需要连接的 IP、DNS 名称或 UNIX 套接字；
可以使用如上注释的高端玩。

可选参数有 facility、severity、tag:
server 参数接收带端口的 IP 地址或 DNS 名称；默认是 UDP 514 端口。
facility 参数设置syslog 的类型 facility，值是 syslog RFC 标准定义的 23 个值中一个，默认值为 local7。其他可能的值是：auth，authpriv，daemon，cron，ftp，lpr，kern，mail，news，syslog，user，uucp，local0 ... local7
tag 参数表示日志文件中显示时候的标题，默认值是 nginx。
severity 设置消息严重程度，默认是 info 级别日志。

日志缓冲区

当系统处于负载状态时，启用日志缓冲区以降低 nginx worker 进程阻塞。大量的磁盘读写和 cpu 资源使用对于服务器资源也是一种巨大消耗。将日志数据缓冲到内存中可能是很小的一个优化手段，buffer 参数意义是缓冲区的大小，功能是当缓冲区已经写满时，日志会被写入文件中；flush 参数意义是缓冲区内日志在缓冲区内存中保存的最长时间，功能即当缓存中的日志超过最大缓存时间，也会被写入到文件中，不足的地方即写入到日志文件的日志有些许延迟，即时调试中应当关闭日志缓冲。。配置如下：

http {
    access_log /var/log/nginx/access.log main buffer=32k flush=1m;
}

参考链接：

原文来自：https://alpha2016.github.io/2019/06/11/Nginx 日志自定义记录及启用日志缓冲区/

链接: https://www.fly63.com/article/detial/3649