如何阿里巴巴网站做推广,中山网站建设文化策划,手机wap网站源码,甘肃省城乡建设局网站背景
Nginx是一款功能强大的Web服务器#xff0c;对于网络环境中的日志记录和配置至关重要。定制化Nginx日志格式可以帮助管理员更好地监控服务器性能、分析用户行为并做出相应优化。在本文中#xff0c;我们将深入探讨Nginx日志格式的高级定制化策略#xff0c;包括理解基…背景
Nginx是一款功能强大的Web服务器对于网络环境中的日志记录和配置至关重要。定制化Nginx日志格式可以帮助管理员更好地监控服务器性能、分析用户行为并做出相应优化。在本文中我们将深入探讨Nginx日志格式的高级定制化策略包括理解基础日志结构、日志格式自定义实例、模块集成与扩展以及日志切割与管理。 Nginx的自定义日志指标全面 Nginx之间的日志追踪分析整个流程
Nginx自定义日志格式
1. 理解基础日志结构
log_format 有一个默认的无需设置的 combined 日志格式相当于apache 的 combined 日志格式如下所示
log_format combined $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent ;Nginx默认日志格式包含多个字段每个字段都提供了有用的信息来帮助分析服务器行为。以下是一些常见字段及其含义
$remote_addr: 客户端的IP地址$remote_user: 客户端用户的名称$time_local: 访问时间与时区$request: 完整的HTTP请求行包括请求方法、URI和协议$status: 服务器响应的HTTP状态码$body_bytes_sent: 发送给客户端的字节数不包括响应头的大小$http_referer: 客户端发送的HTTP Referer头部信息$http_user_agent: 客户端发送的User-Agent头部信息
这些字段的组合可以提供全面的请求和响应信息有助于分析用户行为和服务器性能。
如果 nginx 位于负载均衡器 squid nginx 反向代理之后 web 服务器无法直接获取到客户端真实的 IP 地址了。 $remote_addr 获取反向代理的 IP 地址。反向代理服务器在转发请求的 http 头信息中可以增加 X-ForwardedFor 信息用来记录 客户端 IP 地址和客户端请求的服务器地址。 如下所示
log_format porxy $http_x_forwarded_for - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent ;2. 日志格式自定义实例
通过Nginx的access_log指令管理员可以轻松自定义日志格式
具体log_format的语法如下
log_format name [escapedefault|json|none] string ...;每一个日志格式都有一个名称然后在配置access_log的时候可以指定用哪种格式来进行记录日志。log_format只能定义在http块中。查看在Nginx配置文件中的定义
http {#可以定义多个log_format名称只需要不一样即可log_format main $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for;
}server {access_log /var/log/nginx/access.log main; # 注意这里的配置 error_log /var/log/nginx/error.log;
}如上在http块中定义了一个名称为main的日志格式在server块中通过名称对该日志格式进行了引用这样子日志的格式都会按找main中定义的一些属性来进行记录访问信息。
通过上边对日志格式和日志文件的一些了解我们就可以非常容易的把日志的格式设置成JSON了只需要定义一个log_format把它的格式定义成一个json字符串然后在打印日志的时候引用这个格式就可以实现了下边是一个完成的定义文件:可根据自己的需求定制
第一种 程序友好型json格式
log_format json escapejson {time_iso8601: $time_iso8601, # local time in the ISO 8601 standard formatrequest_time: $request_time, # request processing time in seconds with msec resolutionstatus: $status, # response status codebody_bytes_sent: $body_bytes_sent, # the number of body bytes exclude headers sent to a clientbytes_sent: $bytes_sent, # the number of bytes sent to a clientremote_addr: $remote_addr, # client IPremote_user: $remote_user, # client HTTP usernameremote_port: $remote_port, # client portrequest_uri: $request_uri, # full path and arguments if the requestargs: $args, # argsrequest_id: $request_id, # the unique request idconnection: $connection, # connection serial numberconnection_requests: $connection_requests, # number of requests made in connectionpid: $pid, # process pidrequest_length: $request_length, # request length (including headers and body)time_local: $time_local, http_referer: $http_referer, # HTTP refererhttp_user_agent: $http_user_agent, # user agenthttp_x_forwarded_for: $http_x_forwarded_for, # http_x_forwarded_forhttp_host: $http_host, # the request Host: headerserver_name: $server_name, # the name of the vhost serving the requestssl_protocol: $ssl_protocol, # TLS protocolssl_cipher: $ssl_cipher, # TLS cipherscheme: $scheme, # http or httpsrequest_method: $request_method, # request methodserver_protocol: $server_protocol, # request protocol, like HTTP/1.1 or HTTP/2.0pipe: $pipe, # p if request was pipelined, . otherwisegzip_ratio: $gzip_ratio, http_cf_ray: $http_cf_ray, request_host: $host, is_completion: $request_completion, upstream: $upstream_addr, # upstream backend server for proxied requestsupstream_name: $proxy_host, # upstream nameupstream_status: $upstream_status, # upstream statusupstream_bytes_sent: $upstream_bytes_sent, # upstream bytes sentupstream_bytes_received: $upstream_bytes_received, # upstream bytes receivedupstream_connect_time: $upstream_connect_time, # upstream handshake time incl. TLSupstream_header_time: $upstream_header_time, # time spent receiving upstream headersupstream_response_time: $upstream_response_time, # time spend receiving upstream bodyupstream_response_length: $upstream_response_length, # upstream response lengthupstream_cache_status: $upstream_cache_status, # cache HIT/MISS where applicablenginx_host: $hostname
};json格式对程序友好配合ELK等日志采集、分析系统使用很方便方便对日志进行深度分析。但是多数人平时比较喜欢直接查看日志文件这时json格式的日志文件看起来就不够清晰了日志较长冗余信息较多使用shell命令进行统计和分析也不方便。
{time_iso8601: 2024-04-10T16:55:2608:00, request_time: 0.009, status: 200, body_bytes_sent: 397, bytes_sent: 916, remote_addr: 192.168.96.19, remote_user: , remote_port: 8145, request_uri: /default_sso_heartbeat.html, args: , request_id: c002e29f30c5e85a01dc1927991a9175, connection: 759864, connection_requests: 1, pid: 8459, request_length: 1017, time_local: 10/Apr/2024:16:55:26 0800, http_referer: https://apollo.ownit.top/default_sso_heartbeat.html, http_user_agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36, http_x_forwarded_for: , http_host: apollo.ownit.top, server_name: apollo.ownit.top, ssl_protocol: TLSv1.2, ssl_cipher: ECDHE-RSA-AES256-GCM-SHA384, scheme: https, request_method: GET, server_protocol: HTTP/1.1, pipe: ., gzip_ratio: , http_cf_ray: , request_host: apollo.ownit.top, is_completion: OK, upstream: 192.168.102.40:80, upstream_name: kubernetes-cluster, upstream_status: 200, upstream_bytes_sent: 1100, upstream_bytes_received: 880, upstream_connect_time: 0.000, upstream_header_time: 0.009, upstream_response_time: 0.009, upstream_response_length: 397, upstream_cache_status: , nginx_host: bt}第二种 运维友好型自定义格式
log_format main escapejson$remote_addr |$ipdb_raw |[$time_local] |$host |$request |$status |BodySent:$body_bytes_sent |ReqTime:$request_time |$request_completion |$http_x_forwarded_for |$proxy_host |$upstream_addr |$upstream_status |$upstream_cache_status |UpResTime:$upstream_response_time |UpConnTime:$upstream_connect_time |UpResLen:$upstream_response_length |$hostname-$request_id |$scheme |$request_body |$http_referer |$http_user_agent |$http_cookie;这种格式使用“|”作为分隔符日志打印也不是很长方便使用AWK等命令进行统计
需注意以下几点:
$ipdb_raw这个变量是ipip.net ip库的nginx模块如果未使用这个模块会报错去掉或换成GEOIP即可。escapejson 表示以json格式输出高版本的Nginx已经支持json格式对于第二种自定义格式开启这个参数能在access log中打印中文不会乱码$http_cookie是打印所有cookies,当然也可以打印session,对于高安全要求的情况日志中不会允许泄漏用户cookies。但是某些情况需调试或打印非敏感的cookies,可以打印指定cookies如打印nginx session sticky生产的cookies,假设名字叫backend ‘TRACE:$cookie_backend’。$hostname-$request_id 如果有做全局调用链分析的需求这个参数可以做为全局的UUIDnginx对每个请求都生成一个唯一的UUID传给后端工程打印出来即可。
模块集成与扩展
通过集成第三方模块如ngx_http_geoip_module和ngx_http_log_module可以进一步丰富日志信息。ngx_http_geoip_module允许在日志中添加客户端的地理位置信息例如国家、城市等这对于分析用户的地理分布非常有用。ngx_http_log_module则提供了灵活的日志配置选项包括基于变量的日志记录和条件日志记录使日志记录更加精细和高效。
请参考
https://blog.csdn.net/fishinhouse/article/details/88966258 https://blog.csdn.net/zzhongcy/article/details/86214969
日志切割与管理
日志文件的定期滚动分割是日志管理中的一个重要方面。这可以通过设置定时任务如使用cron来实现以定期执行日志切割操作例如每天或每周切割一次日志文件。此外还需要考虑日志的归档和安全存储确保日志数据在保持可访问性的同时不会因过时或安全问题而遭到破坏。使用如logrotate等工具可以帮助实现这些日志管理任务保证日志数据的完整性和安全性。
通过深入探索这些策略可以实现对Nginx服务器日志记录的精细化配置从而为应用程序的监控和分析提供强大的支持
在Nginx的使用过程中如果不对Nginx的日志做自定义的配置的话那么默认的access.log日志默认就只有这么一个日志文件随着系统使用时间越来越就日志文件就会越来越大而且默认的日志记录的格式也不方便分析。所以我们在实际使用Nginx的过程中需要对其日志做一些配置。 在http配置块中进行配置也可以在每个server块中配置不同的access_log用以区分
http{# 定义一个变量来存储年月日 map $time_iso8601 $date { default date-not-found; ~^(?ymd\d{4}-\d{2}-\d{2}) $ymd;} # 定义一个变量来存储时分秒 map $time_iso8601 $time { default time-not-found; ~T(?hms\d{2}:\d{2}:\d{2}) $hms;}# 定义日志格式为json格式log_format json_format { timestamp: $date $time, remote_addr: $remote_addr, remote_user: $remote_user, request: $request, status: $status, body_bytes_sent: $body_bytes_sent, http_referer: $http_referer, http_user_agent: $http_user_agent, http_x_forwarded_for: $http_x_forwarded_for
};# 定义一个变量来存储年月,可用来作为access.log的日志文件名按月自动分割日志map $time_iso8601 $logmonth { ~^(?ym\d{4}-\d{2}) $ym; default date-not-found; }# 定义一个变量来存储年月日可用来作为access.log的日志文件名按天自动分割日志map $time_iso8601 $logdate { ~^(?ymd\d{4}-\d{2}-\d{2}) $ymd; default date-not-found; }# 开启access.log日志可设置日志名变量(这里选择上面的按天)以便分割日志可设置日志格式以便更直观分析日志access_log logs/access-$logdate.log json_format;
}Nginx的日志常见配置项
$args #请求中的参数值
$query_string #同 $args
$arg_NAME #GET请求中NAME的值
$is_args #如果请求中有参数值为?否则为空字符串
$uri #请求中的当前URI(不带请求参数参数位于$args)可以不同于浏览器传递的$request_uri的值它可以通过内部重定向或者使用index指令进行修改$uri不包含主机名如/foo/bar.html。
$document_uri #同 $uri
$document_root #当前请求的文档根目录或别名
$host #优先级HTTP请求行的主机名HOST请求头字段符合请求的服务器名.请求中的主机头字段如果请求中的主机头不可用则为服务器处理请求的服务器名称
$hostname #主机名
$https #如果开启了SSL安全模式值为on否则为空字符串。
$binary_remote_addr #客户端地址的二进制形式固定长度为4个字节
$body_bytes_sent #传输给客户端的字节数响应头不计算在内这个变量和Apache的mod_log_config模块中的%B参数保持兼容
$bytes_sent #传输给客户端的字节数
$connection #TCP连接的序列号
$connection_requests #TCP连接当前的请求数量
$content_length #Content-Length 请求头字段
$content_type #Content-Type 请求头字段
$cookie_name #cookie名称
$limit_rate #用于设置响应的速度限制
$msec #当前的Unix时间戳
$nginx_version #nginx版本
$pid #工作进程的PID
$pipe #如果请求来自管道通信值为p否则为.
$proxy_protocol_addr #获取代理访问服务器的客户端地址如果是直接访问该值为空字符串
$realpath_root #当前请求的文档根目录或别名的真实路径会将所有符号连接转换为真实路径
$remote_addr #客户端地址
$remote_port #客户端端口
$remote_user #用于HTTP基础认证服务的用户名
$request #代表客户端的请求地址
$request_body #客户端的请求主体此变量可在location中使用将请求主体通过proxy_passfastcgi_passuwsgi_pass和scgi_pass传递给下一级的代理服务器
$request_body_file #将客户端请求主体保存在临时文件中。文件处理结束后此文件需删除。如果需要之一开启此功能需要设置client_body_in_file_only。如果将次文件传 递给后端的代理服务器需要禁用request body即设置proxy_pass_request_body offfastcgi_pass_request_body offuwsgi_pass_request_body offor scgi_pass_request_body off
$request_completion #如果请求成功值为OK如果请求未完成或者请求不是一个范围请求的最后一部分则为空
$request_filename #当前连接请求的文件路径由root或alias指令与URI请求生成
$request_length #请求的长度 (包括请求的地址http请求头和请求主体)
$request_method #HTTP请求方法通常为GET或POST
$request_time #处理客户端请求使用的时间,单位为秒精度毫秒 从读入客户端的第一个字节开始直到把最后一个字符发送给客户端后进行日志写入为止。
$request_uri #这个变量等于包含一些客户端请求参数的原始URI它无法修改请查看$uri更改或重写URI不包含主机名例如/cnphp/test.php?argfreemouse
$scheme #请求使用的Web协议http 或 https
$server_addr #服务器端地址需要注意的是为了避免访问linux系统内核应将ip地址提前设置在配置文件中
$server_name #服务器名
$server_port #服务器端口
$server_protocol #服务器的HTTP版本通常为 HTTP/1.0 或 HTTP/1.1
$status #HTTP响应代码
$time_iso8601 #服务器时间的ISO 8610格式
$time_local #服务器时间LOG Format 格式
$cookie_NAME #客户端请求Header头中的cookie变量前缀$cookie_加上cookie名称的变量该变量的值即为cookie名称的值
$http_NAME #匹配任意请求头字段变量名中的后半部分NAME可以替换成任意请求头字段如在配置文件中需要获取http请求头Accept-Language$http_accept_language即可
$http_cookie
$http_host #请求地址即浏览器中你输入的地址IP或域名
$http_referer #url跳转来源,用来记录从那个页面链接访问过来的
$http_user_agent #用户终端浏览器等信息
$http_x_forwarded_for
$sent_http_NAME #可以设置任意http响应头字段变量名中的后半部分NAME可以替换成任意响应头字段如需要设置响应头Content-length$sent_http_content_length即可
$sent_http_cache_control
$sent_http_connection
$sent_http_content_type
$sent_http_keep_alive
$sent_http_last_modified
$sent_http_location
$sent_http_transfer_encodingNginx之间的日志追踪
在当今互联网架构中Web应用防火墙WAF与Nginx作为前端代理的整合越来越常见特别是在提升Web应用程序的安全性方面。这种结构不仅增强了对应用的保护还提升了系统的整体性能。在这种架构中理解WAF与Nginx如何协作以及如何实现日志追踪的整合尤为重要。
WAF与Nginx协作原理
WAF通常作为Nginx的上游组件部署拦截向Web应用程序发起的请求。它的主要作用是评估每个请求中的潜在威胁如SQL注入、跨站脚本XSS等然后根据预定义的规则集来决定是否允许请求通过。通过与Nginx的紧密协作WAF能够在请求到达应用服务器之前提供一层额外的保护。
在请求和响应过程中WAF与Nginx之间的交互涉及到请求的接收、分析、处理和转发。当WAF检测到潜在威胁时可以决定直接阻止该请求或者将其转发给Nginx进行进一步的处理。
日志集成挑战与解决方案
在将WAF与Nginx整合进一致性和可追溯性的日志系统时面临的挑战主要包括跨组件的日志同步和关联。日志记录需要从WAF到Nginx再到应用服务器形成一个连续的链路以确保对整个请求-响应周期的完全可见性。
为了解决这一挑战一种方法是在所有组件中使用统一的日志ID。通过在HTTP头部插入一个唯一的跟踪标识符例如通过X-Request-ID可以跨多个系统跟踪单个请求从而简化日志数据的关联和分析。
用户访问流程日志分析
总结阿里云的WAF日志更加详细Nginx层面的日志也是WAF过来的数据一样的
下方三个截图的数据日志就是一条的请求的访问。数据都是一样的各个层面都有日志记录。毫无疑问 WAF更加专业 图像化更多。 阿里云的WAF Nginx中转
server {listen 80;server_name bd.xxx.com ;rewrite ^/(.*)$ https://$host/$1 permanent;
}
server {listen 443 ssl;server_name bd.xxx.com;ssl on;ssl_certificate /usr/local/openresty/nginx/ssl/xx.com.crt;ssl_certificate_key /usr/local/openresty/nginx/ssl/xxx.com.key;include ssl.conf;location / {proxy_pass http://172.18.199.115:8085;include https_proxy.conf;}
}Nginx前端 前端机器172.18.199.115
server {listen 8085;server_name bd.xxxx.com;root /opt/mfbd/dist;index index.html index.htm;location / {try_files $uri /index.html;add_header Access-Control-Allow-Origin *; add_header Access-Control-Allow-Headers Content-Type; add_header Access-Control-Allow-Methods GET,POST,OPTIONS; add_header Access-Control-Allow-Credentials true; }
} 日志分析与可视化
利用自定义日志数据进行日志分析与可视化是提高安全性和响应能力的关键。通过集成SIEM工具、ELK栈Elasticsearch、Logstash、Kibana或其他日志分析平台可以对日志数据进行实时监控、异常检测和攻击行为分析。这些工具能够帮助团队快速识别并响应安全威胁同时提供直观的数据可视化以便深入理解和改进安全策略。
综上所述WAF与Nginx前端代理的整合不仅加强了Web应用的安全层而且通过有效的日志追踪和分析为团队提供了关键的洞察以持续改进安全姿态和响应能力。
参考文档
https://www.cnblogs.com/ouym/p/15393191.html
https://www.iminling.com/2023/10/04/272.html
https://opswill.com/articles/nginx-custom-access-log-format.html
