一. 场景：

         首先，我们需要明白 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的值。