logstash数据写入es后，通过kibana查看的UTC时区问题

本文链接：https://blog.youkuaiyun.com/codeydj/article/details/141032749

问题：

ES @timestamp字段默认是utc时区，不可更正
Logstash output中根据日期生成index xxx_log-{+YYYY.MM.DD} 是根据@timestamp的日期来的，如果不进行处理的话，会导致索引晚生成8小时，丢失8小时数据
kibana展示时，可能会出现强行转换@timestamp时间的情况，原因：kibana展示时是按照浏览器的时区来的

解决方案–试错版：

ES@timestamp时区问题：一般来说都会有自己的时间字段，我的方案是：放弃掉@timestamp字段，用自己的时间字段，@timestamp只用来做index生成和kibana展示
~~- logstash生成index解决方案：~~ 这个方案确实可以将@timestamp的时间与req_time保持一致，但存在一个问题就是kibana和es的查询会完全乱掉,所以放弃掉

  #将业务字段的时间转换为timestamp,由于logstash默认@timestamp为utc，需要转换为utc+8
  # date固定语法，提供指定字段的时间格式与时区转换为@timestamp,@timestamp会生成一个相同时间的utc时间（比上海时间晚8小时）
  date {
    match => [ "req_time", "yyyy/MM/dd HH:mm:ss" ]
    timezone => "Asia/Shanghai"
    target => "@timestamp"
   }
  # 获取到utc时间后，通过ruby脚本,将@timestamp改成东八区时间 
  ruby {
     code => "event.set('t_time', event.get('@timestamp').time.localtime + 8*60*60); event.set('@timestamp', event.get('t_time'))"
  }

~~kibana @timestamp被修改时区问题，由于我上述将@timestamp进行了+8，则在kibana展示时，需要将时区从浏览器时区修改为UTC时区~~ 这个改动会影响到X-pack的监控和kibana其他的功能，不建议这样改，且在discover也会完全乱掉..

最终妥协版

一、保留logstash中的@timestamp，但不做+8操作，延用UTC时间，原因：kibana整个系统的默认时区为浏览器时区，如果修改掉，则会导致所有功能都乱掉，得不偿失。且，如果@timestamp 为UTC时间，经过kibana处理后，与原时间字段req_time一致

  date {
    match => [ "req_time", "yyyy/MM/dd HH:mm:ss" ]
    timezone => "Asia/Shanghai"
    target => "@timestamp"
   }

二、修改动态索引依赖的字段，由于第一步不在对@timestamp进行+8后，会出现索引直到第二天8点才能生成的情况，因此需要中间字段，来负责Index的生成

  # 此处的时间匹配和根据自己的时间格式进行匹配，具体patterns可参考[官方地址](https://github.com/logstash-plugins/logstash-patterns-core/blob/main/patterns/ecs-v1/grok-patterns)
  grok {
    match => { "req_time" => "%{YEAR:year}/%{MONTHNUM:month}/%{MONTHDAY:day} %{HOUR:hour}:%{MINUTE:minute}:%{SECOND:second}" }
    add_field => {
      "[date]" => "%{year}-%{month}-%{day}"
    }
    remove_field => [ "year", "month", "day", "hour", "minute", "second" ] #中间字段用完就删除
  }