1.nginx日志调成json样式

log_format json '{"@timestamp":"$time_iso8601",'
                '"server_addr":"$server_addr",'
                '"server_name":"$server_name",'
                '"server_port":"$server_port",'
                '"server_protocol":"$server_protocol",'
                '"client_ip":"$remote_addr",'
                '"client_user":"$remote_user",'
                '"status":"$status",'
                '"request_method": "$request_method",'
                '"request_length":"$request_length",'
                '"request_time":"$request_time",'
                '"request_url":"$request_uri",'
                '"request_line":"$request",'
                '"send_client_size":"$bytes_sent",'
                '"send_client_body_size":"$body_bytes_sent",'
                '"proxy_protocol_addr":"$proxy_protocol_addr",'
                '"proxy_add_x_forward":"$proxy_add_x_forwarded_for",'
                '"proxy_port":"$proxy_port",'
                '"proxy_host":"$proxy_host",'
                '"upstream_host":"$upstream_addr",'
                '"upstream_status":"$upstream_status",'
                '"upstream_cache_status":"$upstream_cache_status",'
                '"upstream_connect_time":"$upstream_connect_time",'
                '"upstream_response_time":"$upstream_response_time",'
                '"upstream_header_time":"$upstream_header_time",'
                '"upstream_cookie_name":"$upstream_cookie_name",'
                '"upstream_response_length":"$upstream_response_length",'
                '"upstream_bytes_received":"$upstream_bytes_received",'
                '"upstream_bytes_sent":"$upstream_bytes_sent",'
                '"http_host":"$host",'
                '"http_cookie":"$http_cooke",'
                '"http_user_agent":"$http_user_agent",'
                '"http_origin":"$http_origin",'
                '"http_upgrade":"$http_upgrade",'
                '"http_referer":"$http_referer",'
                '"http_x_forward":"$http_x_forwarded_for",'
                '"http_x_forwarded_proto":"$http_x_forwarded_proto",'
                '"https":"$https",'
                '"http_scheme":"$scheme",'
                '"invalid_referer":"$invalid_referer",'
                '"gzip_ratio":"$gzip_ratio",'
                '"realpath_root":"$realpath_root",'
                '"document_root":"$document_root",'
                '"is_args":"$is_args",'
                '"args":"$args",'
                '"connection_requests":"$connection_requests",'
                '"connection_number":"$connection",'
                '"ssl_protocol":"$ssl_protocol",'
                '"ssl_cipher":"$ssl_cipher"}';

凡是需要使用nginx日志的均采用如下写法：

# 事前创建保存nginx日志的文件夹
# mkdir -p /var/log/nginx/

access_log /var/log/nginx/test.access.log json;

2.使用filebeat收集nginx的日志

注意:这里不采用自带的模块形式，也就是不开启nginx的module收集功能

注意：方式1和方式2的其他配置都相同，这里只列出不同的地方，后面会具体分析这俩不同的配置有啥不同的效果

设置方式1

- type: log
  enabled: true
  paths:
    - /var/log/nginx/test.access.log
  fields:
    log_source: nginx
    log_type: www
  fields_under_root: true
  tags: ["nginx"]
  json:
    keys_under_root: true
    overwrite_keys: true
    message_key: "message"
    add_error_key: true

使用方式1的设置后，nginx的日志就会输出到es中，且日志中的每个键值对就是顶级字段，如下图所示

但是有一个问题，原有message字段的值是空的，导致在kibana日志导航中无法显示ngixn的日志(具体是access日志，error日志因为还是原来的设置仍会显示).

这种设置在grafana中会正常显示数据出来的。

设置方式2

- type: log
  enabled: true
  paths:
    - /var/log/nginx/test.access.log
  fields:
    log_source: nginx
    log_type: www
  fields_under_root: true
  tags: ["nginx"]

processors:
  - add_host_metadata:
      when.not.contains.tags: forwarded
  - decode_json_fields:
      fields: ['message']
      target: "" 
      overwrite_keys: false 
      process_array: false 
      max_depth: 1

使用方式2的设置后，nginx的日志就会输出到es中，且日志中的每个键值对就是顶级字段，并且原有message字段的值仍存在，在kibana日志导航中还可以继续显示ngixn的日志(具体是access日志，error日志因为还是原来的设置仍会显示).

这种设置在grafana中会正常显示数据出来的。

综合方式1和方式2，方式2的方式是符合需求的，既能继续查询日志，还能把日志信息图形化显示出来(不使用自带的nginx module收集方式)

3.es中设置索引模式

filebeat-*

4.grafana中添加dashboard

打开 Grafana 页面，登录后，在 Data Sources 添加类型为 Elasticsearch 的数据源
在 HTTP 段，把 es 机器的IP地址和端口填写到 URL 输入框中，比如: http://localhost:9200,访问有密码的话需要加上密码
在 Elasticsearch details 段
把上面 filebeat 配置的nginx索引名称填写到 Index name 输入框中，比如: filebeat-*
Version 选择 7.0+
保存测试

导入Dashboard，ID: 14913

6.上述方式1和方式2的字段含义

方式1
json 这些选项使得Filebeat将日志作为JSON消息来解析。例如：

json.keys_under_root: true
json.add_error_key: true
json.message_key: log

为了启用JSON解析模式，你必须至少指定下列设置项中的一个：
keys_under_root: 默认情况下，解码后的JSON被放置在一个以"json"为key的输出文档中。如果你启用这个设置，那么这个key在文档中被复制为顶级。默认是false。
overwrite_keys:　如果keys_under_root被启用，那么在key冲突的情况下，解码后的JSON对象将覆盖Filebeat正常的字段
add_error_key:　如果启用，则当JSON反编排出现错误的时候Filebeat添加 "error.message" 和 "error.type: json"两个key，或者当没有使用message_key的时候。
message_key: 一个可选的配置，用于在应用行过滤和多行设置的时候指定一个JSON key。指定的这个key必须在JSON对象中是顶级的，而且其关联的值必须是一个字符串，否则没有过滤或者多行聚集发送。
ignore_decoding_error: 一个可选的配置，用于指定是否JSON解码错误应该被记录到日志中。如果设为true，错误将被记录。默认是false。

方式2

用filebeat想对收集到的日志进行这样的解析：如果为json的话，就将json对象中的每个子字段解析成顶级结构下的一个字段，但是发现，解析后，保存日志完整内容的message字段（也即完整的json串）消失了，最终找到如下解决方法：
用processors中的decode_json_fields处理器进行处理，它类似logstash中的filter，具体格式如下：

processors:
  - add_host_metadata:
      when.not.contains.tags: forwarded
  - decode_json_fields:
      fields: ['message'] #要进行解析的字段
      target: ""  #json内容解析到指定的字段，如果为空（""），则解析到顶级结构下
      overwrite_keys: false #如果解析出的json结构中某个字段在原始的event（在filebeat中传输的一条数据为一个event）中也存在，是否覆盖event中该字段的值，默认值:false
      process_array: false  #数组是否解码，默认值:false
      max_depth: 1 #解码深度，默认值：1