nginx 日志规范化意义及实现!

一. 场景:

首先,我们需要明白 log的重要性。服务的log,将是我们分析用户行为的不可缺少的一个核心组件;通过log我们可以获取用户的访问量,qps,rt,pv,状态,通过log进行相应的监控,故障排除,追踪,定位等。

nginx log的配置方式,相信做过运维的同学都使用过,曾经的本人也认为是一个随手就能搞定的事儿。然而,当我们的nginx项目几十上百,甚至更多;不同的业务都有不同的配置需求/方式;对每个业务的log都需要接入log采集分析系统的情况下,就不再是一个随手的问题了。我们的nginx日志将面向运维、++开发、安全等++服务,所以确定规范非常必要,协同的前提是我们首先有"原则",否则将会发生信息不对称,造成冲突。同时,我们还要考虑相关敏感问题。

定以后的规范如下:

复制代码
log_format  main  '$time_local|$hostname|$remote_addr|$upstream_addr|$request_time|$upstream_response_time|$upstream_connect_time|'
'$status|$upstream_status|-|$bytes_sent|-|-|$remote_user|$request|$http_user_agent|$http_referer|'
'$scheme|$request_method|$request_trace_id|$request_trace_seq|'
'$http_x_forwarded_for|$http_Authorization';

定义说明:

  1. 因为需求对log进行采集,匹配分析,为了更好的解析,采用了管道符"|" 作为每个字段的分隔符(相关操作可参看ELK stack中的logstash配置)。

  2. 每个域所包含的字段列表不同,使用日志的开发团队所关注的域也不同;我们确保增加Field时,尽可能在当前域的后面增加;对于使用日志的开发者而言,调整的代码量也是比较小的。比如追踪系统,通常只关注第二个域,那么在第二个域中增减字段,不会影响其他域中Field的相对位置。

  3. 其中定义了"-"占位符 ,使用来后续的预留使用。

各字段内容:

|-------------------------|-------------------------------------------------------------------|
| 字段名 | 解释 |
| time_local | 日志时间 |
| hostname | 当前机器的hostname(非IP) |
| remote_addr | 客户端地址 |
| upstream_addr | 后端Server的地址 |
| request_time | nginx处理请求的时长,从获取Client请求的首个字节开始到响应数据发送完毕,单位为"秒 + 毫秒" |
| upstream_response_time | 从nginx与upstream建立连接开始到response数据接收完毕。 |
| upstream_connect_time | 与upstream建立连接的时间。 |
| status | nginx响应状态码 |
| upstream_status | upstream返回给nginx的状态码(tomcat或者后继nginx) |
| bytes_received | nginx接收到Client的请求数据大小 1.11版本才能支持,此处用"-"占位符替代 |
| bytes_sent | nginx返回给Client的数据大小 |
| upstream_bytes_sent | nginx发送给upstream的字节数 1.11版本才支持,此处使用"-"占位符替代 |
| upstream_bytes_received | nginx接收到upstream响应的字节数 1.11版本才支持,此处使用"-"占位符替代 |
| remote_user | 基本认证中的user信息 |
| request | HTTP请求行---首行 |
| http_user_agent | 标头中"User-Agent"值 |
| http_referer | 标头中"Referer"值 |
| scheme | 请求的Scheme,HTTP或者HTTPS |
| request_method | HTTP(S)请求的方法名:GET,POST等 |
| request_trace_id | 获取标头中"X-Request-ID"值, 如果不包含此header,则创建新的Trace_id。 |
| request_trace_seq | 获取标头中"X-Request-Seq"值,如果存在,表明此请求是trace link下发的请求。此值用于追踪请求链的层级或者顺序 |
| http_{key} | 获取HEADER中指定key的值。 |
| cookie_{key} | 获取COOKIE中指定key的值。 |

相关推荐
微小冷24 分钟前
用Mermaid画时序图
运维·流程图·时序图·mermaid·生命线
其实防守也摸鱼28 分钟前
Codex 下载与本地部署实战:从安装到运行全指南
android·大数据·运维·安全·自动化
wdfk_prog1 小时前
ROS教程07:从 ros::start() 顺着源码读懂 Master、XML-RPC 与 Topic 注册发现
运维·缓存·docker·容器·ros
吴声子夜歌1 小时前
Shell编程实例——与解析相关的任务(二)
linux·运维·shell
mengge.cloud1 小时前
0917Docker 小白实验教程(理论+实操)
linux·服务器·网络·docker
倔强的石头1062 小时前
【Linux指南】动静态库系列(八):ELF 加载与进程地址空间:程序还没运行,为什么已经有地址
linux·运维
两点王爷2 小时前
常用的 Docker 镜像拉取地址仓库及常用命令详解
运维·服务器·容器
wdfk_prog2 小时前
用 Git Submodule + Sparse Checkout 管理 RT-Thread:内核、BSP、第三方库与业务代码分层实践
运维·缓存·docker·容器·ros
神.秘.人2 小时前
【BIOS/UEFI 与 MBR/GPT 的区别详解】
运维·服务器
第十人i3 小时前
Linux 一键重装系统脚本:reinstall 工具详解
linux·服务器