ES时区问题
elasticsearch原生支持date类型，json格式通过字符来表示date类型。
所以在用json提交日期至elasticsearch的时候，es会隐式转换，把es认为是date类型的字符串直接转为date类型。
date类型是包含时区信息的，如果我们没有在json代表日期的字符串中显式指定时区，对es来说没什么问题，
但是如果通过kibana显示es里的数据时，就会出现问题，数据的时间会晚8个小时。
kibana在通过浏览器展示的时候，会通过js获取当前客户端机器所在的时区，也就是东八区，所以kibana会把从es得到的日期数据减去8小时。
最佳实践方案就是：往es提交日期数据时，直接提交带有时区信息的日期字符串，
如：“2016-07-15T12:58:17.136+0800”。
数据的存储和显示相分离是非常基本的设计原则，却常常被大多数开发人员忽略:
基于“数据的存储和显示相分离”的设计原则，只要把表示绝对时间的时间戳（无论是Long型还是Float）存入数据库，在显示的时候根据用户设置的时区格式化为正确的字符串。
System.currentTimeMillis() 自起点多少毫秒数。是隐式含有时区信息的。不同时区在同一时刻，距离起点的毫秒数是不同的！
若写入的是new Date().getTime()，默认按照系统时区写(东八区)。kibana按照东八区读没问题。
若写入的是字符串，没有时区信息，默认按照0时区，Kibana读取的时候，若按照东八区读，差8小时。
long t = System.currentTimeMillis()
System.out.println("long = " + t)
// current time zone:
SimpleDateFormat sdf_default = new SimpleDateFormat("yyyy-MM-dd HH:mm")
System.out.println(sdf_default.format(t))
SimpleDateFormat sdf_8 = new SimpleDateFormat("yyyy-MM-dd HH:mm")
sdf_8.setTimeZone(TimeZone.getTimeZone("GMT0"))
System.out.println("GMT0 = " + sdf_8.format(t))
TimeZone.getTimeZone("GMT+8:00")
TimeZone.getTimeZone("America/Los_Angeles")
TimeZone.setDefault(TimeZone.getTimeZone("GMT+8")) 修改默认时区
-
1
-
2
-
3
-
4
-
5
-
6
-
7
-
8
-
9
-
10
-
11
-
12
-
13
-
14
据查询不出结果#
时区问题：
东八区（GMT+08:00）是比世界协调时间（UTC）/格林尼治时间（GMT）快8小时的时区，
英国格林尼治处于0度经线
美国横跨西五区至西十区,共六个时区。每个时区对应一个标准时间,
华盛顿(西五区)比北京慢13小时
“Management” —- “Advanced Settings”
dateFormat：YYYY-MM-DD HH:mm:ss.SSS 显示结果时，方便查看的格式
dateFormat:tz 若采用默认时区则，显示时需设置为 GMT0，这是 展示数据正确与否的关键设置
"createtime": {
"type": "date",
"format":"YYYY-MM-DD'T'HH:mm:ss.SSSZ"
提交数据携带时区信息
"createtime":"2017-01-22T12:58:17.136+0800"
java格式化：
String FULL_FORMAT="yyyy-MM-dd\'T\'HH:mm:ss.SSS+0800";
Date now=new Date();
new SimpleDateFormat(FULL_FORMAT).format(now)
"createtime":"2017-01-22T18:55:17.136Z" 这里没有携带时区信息，将以默认时区写入(GMT0)
使用ELK组件从Kibana4中查看日志数据，以某个时间字段为timestam时发现所有时间都被自动提前了八个小时。
虽然是小问题，但是很头疼，因为作为基线的时间和实际情况有误差，那日志就没法看了。
查看Kibana4的json数据格式可以发现所有时间字符串都被Elasticsearch转换成了长整型：
"fields": {
"@timestamp": [
1442214581048
其source的时间值为想要的：
“@timestamp”: “2015-09-14T07:09:41.048Z”
这是因为Elasticsearch在处理时间字符串时默认按UTC时间，如果没有指定额外信息的话。
因此，如果按照北京时间处理的话，就得需要加上08:00
在logstash的配置中可以使用mutate过滤器对输入Elasticsearch的时间字段做如下过滤：
mutate{
gsub => [
"time", "[+]", "T"
mutate{
replace => ["time","%{time}+08:00"]
注意，其中T为日期和时间之间的分隔符，Elasticsearch可以识别进行处理。
ES时区问题elasticsearch原生支持date类型，json格式通过字符来表示date类型。 所以在用json提交日期至elasticsearch的时候，es会隐式转换，把es认为是date类型的字符串直接转为date类型。date类型是包含时区信息的，如果我们没有在json代表日期的字符串中显式指定时区，对es来说没什么问题， 但是如果通过kibana显示es里的数据时，就会出现问题，数...
需求，日志收集的时候，时间格式是国际标准时间格式。形如yyyy-MM-dd'T'HH:mm:ss.SSS。 （2023-12-05T02:45:50.282Z）这个时区也不对，那如何将此类型的时间，进行格式化呢？
本篇文章体统一个案例，可以格式化各种类型的时间，已经调整到各个时区。
背景：业务正常通过应用程序写入没有问题，通过hive同步mysql到es库的时候会出现时区问题，mysql时间字段类型是datetime；
原因：ES默认存储的是UTC时间，比北京时间晚8h；
解决方案：
1、将时间写入ES中string类型字段；
2、将时间以时间戳的形式存入ES中long类型字段；
3、ES默认是UTC时间，将时间+8h后存入ES中date类型字段；
4、写入时间数据时，指定时区，eg：“time”: “2016-07-15T12:58:17.136+0800” //东八区时间
本文主要讲解Elasticsearch中date类型数据的底层存储原理，以及对带时区日期字符串和不带时区的日期字符串如何在ES底层存储进行验证。对于直接存储Long类型时间戳，不作过多描述。
1.1 Date类型数据的存储
UTC(Universal Time Coordinated) 叫做世界统一时间，中国大陆所用的时间是东8区时间，比UTC时间超前8小时。即与 UTC 的时差是 +8 ,也就是 UTC+8。
在Elasticsearch内部，不论 date 是什么展示格式，所有date类型数据
在企业级开发中、我们经常会有编写数据库表结构文档的时间付出，从业以来，待过几家企业，关于数据库表结构文档状态：要么没有、要么有、但都是手写、后期运维开发，需要手动进行维护到文档中，很是繁琐、如果忘记一次维护、就会给以后工作造成很多困扰、无形中制造了很多坑留给自己和后人，于是萌生了要自己写一个插件工具的想法，但由于自己前期在程序设计上没有很多造诣，且能力偏低，有想法并不能很好实现，随着工作阅历的增加，和知识的不断储备，终于在2020年的3月中旬开始进行编写，4月上旬完成初版，想完善差不多在开源，但由于工作太忙，业余时间不足，没有在进行完善，到了6月份由于工作原因、频繁设计和更改数据库、经常使用自己写的此插件、节省了很多时间，解决了很多问题 ，在仅有且不多的业余时间中、进行开源准备，于2020年6月22日，开源，欢迎大家使用、建议、并贡献。
关于名字，想一个太难了，好在我这个聪明的小脑瓜灵感一现，怎么突出它的小，但重要呢？从小就学过雷锋的螺丝钉精神，摘自雷锋日记：虽然是细小的螺丝钉，是个细微的小齿轮，然而如果缺了它，那整个的机器就无法运转了，慢说是缺了它，即使是一枚小螺丝钉没拧紧，一个
Elasticsearch中的时区设置可以通过在配置文件中设置`timezone`参数来实现。具体操作如下：
1. 打开Elasticsearch配置文件`elasticsearch.yml`。
2. 在文件末尾添加以下内容：
# 设置时区
# timezone格式为"区域/城市"，例如"Asia/Shanghai"
# 更多时区列表可以参考https://www.elastic.co/guide/en/elasticsearch/reference/current/time-zone-list.html
cluster:
timezone: "Asia/Shanghai"
3. 保存并退出配置文件。
4. 重启Elasticsearch服务，使配置生效。
设置完时区后，Elasticsearch会将所有的日期时间数据都转换为指定时区的时间。如果不设置时区，则默认使用UTC时间。
