【elasticsearch】数据早8小时Or晚8小时，你知道为什么吗，附解决方案

男娘i 2023-06-26 08:11 59阅读 0赞

##### 前言 #####

*  这篇文章，不会解释什么是本初子午线，只想以做实验的方式来理解数据差8小时的问题。下面就先说结论，再来谈原理。

##### 解决方案 #####

*  想必大家都很清楚：中国标准时间= UTC 8小时。
 *  那么所有和时区有关的地方，都有可能成为“凶手”。

###### 如果是java写入es怎么解决时区问题？ ######

*  如果你使用java程序来写入es，我推荐你写入带T的时间字符串。提供程序如下：

/**
         * String timeZoneConvert = timeZoneConvert(
         *                 new Date().getTime()
         *                 , "yyyy-MM-dd'T'HH:mm:ss.SSSZ",
         *                 "Asia/Shanghai");
         *                 
         * @param date 毫秒
         * @param pattern format时间格式
         * @param timeZone 时区
         * @return 如:2019-12-30T16:32:07.616 0800
         */
        public static String timeZoneConvert(Long date,String pattern,String timeZone){
            SimpleDateFormat simpleDateFormat=new SimpleDateFormat(pattern);
            simpleDateFormat.setTimeZone(TimeZone.getTimeZone(timeZone));
            return simpleDateFormat.format(date);
        }

*  为什么？因为java有些api是带时区的。如new Date().getTime()默认是东八区，System.currentTimeMillis() 依赖于当前时区来计算毫秒值。
 *  虽然上述例子依赖了这个api，但是这里只是想说明java程序所处的环境的时区同样有影响，特别是这个程序很可能是容器化的，那么可能又和系统镜像的时区有关了。

###### 如果是logstash写入es怎么解决时区问题？ ######

*  建议input的时间源数据就是带上时区的字符串，否则就要进行转换。

mutate{
            gsub => [
               "time", "[ ]", "T"
            ]
          } 
            mutate{
          replace => ["time","%{time} 08:00"]
          }

或是：

date {
        match => ["timestamp", "yyyy-MM-dd HH:mm:ss"]
        target => "my_timestamp"
        timezone => " 08:00"
    }

###### 如果是语句聚合es数据怎么解决时区问题？ ######

*  指定time\_zone配置

"aggs": {
        "by_day": {
          "date_histogram": {
            "field":     "date",
            "interval":  "day",
            "time_zone": "Asia/Shanghai"
          }
        }
      }

###### kibana显示怎么解决时区问题？ ######

*  Management>>Advanced Settings设置时区。

![file][]

##### 原理&试验 #####

##### Es中和时间相关的数据类型 #####

*  一般在写入es的时候，会以json的方式写入，由于json中没有日期数据类型，所以日期如何存储显示，是由es决定的，也就是说es会进行隐式的类型转换。
 *  es中的日期可以是：
    
     *  格式化日期的字符串，例如"2019-12-30"或"2019/12/30 12:10:30"。
     *  毫秒值。
     *  秒值。

##### 试验 #####

*  这里以不同的时间api准备了一些数据写入es,让我们来看看会发生什么。

![file][file 1]

*  数据打印出来如下：

{
        "AsiaTime":"2019-12-30T16:32:07.616 0800",
        "newDateTime":1577694727581,
        "localTimeNow":"2019-12-30T16:32:07.615",
        "systemCurrentTimeMilis":1577694727581,
        "newDate":1577694727581
    }

*  默认不设置索引模板的情况，写入es后，我们发现带 时区‘T’的数据类型为date。  
    ![file][file 2]
 *  接下来，我们将轮流设置这两个字段为kibana的时间搜索字段，看看会发生什么。

##### 两个实验对时区的思考 #####

*  实验一：以localTimeNow做时间搜索字段，显示比数据时间晚了8小时。  
    ![file][file 3]
 *  实验二：以AsiaTime做时间搜索字段，显示比数据时间早了8小时。  
    ![file][file 4]
 *  如何解释？当然是由于时区影响。记住这几个点，就很好理解了：
    
     *  es内部，时间会转换成UTC格式，实际按照数值型存储。可以理解为毫秒数。
     *  kibana会通过获取时区配置显示时间到界面。

首先来说实验一，为什么kibana上显示的时比数据时间多8个小时呢？明明是30号的数据，愣是跑到31号去了？

*  这条数据 "localTimeNow":"2019-12-30T16:32:07.615"。带时区T，默认是UTC时区，  
    而kibana获取的时区配置是Asia/Shanghai，为东8区，相当于在原来的时间上加上8个小时显示，所以跑到31号去了。  
    用大腿想一下，你肯定知道，这种情况下如果把kibana时区设置为UTC，当然数据就显示正常啦。
 *  再来说实验二， "AsiaTime":"2019-12-30T16:32:07.616 0800，由于上面设置了当前kibana时区为UTC,数据带东八区的时区，所以晚了8小时。同理将kibana时区改为东八区后显示正常。

#### 总结 ####

*  时区问题，万变不离其宗，搞清楚原理后，任意数据怎么变化，我们都能够有方法应对，希望这篇文章对你有所帮助。

> 欢迎来公众号【侠梦的开发笔记】 一起交流进步

[file]: https://img-blog.csdnimg.cn/20191230202157298.jpeg
[file 1]: https://img-blog.csdnimg.cn/20191230202203644.jpeg
[file 2]: https://img-blog.csdnimg.cn/20191230202203933.jpeg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTI4MTE4MDU=,size_16,color_FFFFFF,t_70
[file 3]: https://img-blog.csdnimg.cn/20191230202157780.jpeg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTI4MTE4MDU=,size_16,color_FFFFFF,t_70
[file 4]: https://img-blog.csdnimg.cn/20191230202204639.jpeg