Elasticsearch 滞后8个小时等时区问题,一网打尽!

发布于 2022-4-21 13:55
浏览
0收藏

Elasticsearch 滞后8个小时等时区问题,一网打尽!-开源基础软件社区如下都是实战环节遇到的问题:

 

 • logstash谁解决过时区问题,mysql是东八区shanghai 但是这玩意读完存到es就少了8小时?


 • 目前索引会比真正时间晚8小时,导致8点前的日志写到昨天索引里,大佬们有招吗?


 • 问一下 logstash输出日志到本地文件中,按照小时生成索引,但是他这边的时区是utc,生成的时间和北京时间少8小时,这一块大佬们是咋操作的?

 

 • ......从浏览器kibana那里看timestamp时间戳变成了utc的时区?

 

上面的问题都涉及到时区问题,涉及到数据的同步(logstash)、写入、检索(elasticsearch)、可视化(kibana)的几个环节。

 

Elasticsearch 滞后8个小时等时区问题,一网打尽!-开源基础软件社区


我们通过如下几个问题展开拆解。


2.1 Elasticserch 默认时区是?能改吗?


官方文档强调:在 Elasticsearch 内部,日期被转换为 UTC时区并存储为一个表示自1970-01-01 00:00:00  以来经过的毫秒数的值。

 

Internally, dates are converted to UTC (if the time-zone is specified) and stored as a long number representing milliseconds-since-the-epoch.

 

https://www.elastic.co/guide/en/elasticsearch/reference/current/date.html

 

Elasticsearch date 类型默认时区:UTC。

 

正如官方工程师强调(如下截图所示):Elasticsearch 默认时区不可以修改。

 Elasticsearch 滞后8个小时等时区问题,一网打尽!-开源基础软件社区
https://discuss.elastic.co/t/index-creates-in-different-timezone-other-than-utc/148941


但,我们可以“曲线救国”,通过:


 • ingest pipeline 预处理方式写入的时候修改时区;


 • logstash filter 环节做时区转换;


 • 查询时指定时区;


 • 聚合时指定时区。


2.2 Kibana 默认时区是?能改吗?


kibana 默认时区是浏览器时区。可以修改,修改方式如下:


Stack Management -> Advanced Settings ->Timezone for data formatting.
 Elasticsearch 滞后8个小时等时区问题,一网打尽!-开源基础软件社区

2.3 Logstash 默认时区是?能改吗?

 

默认:UTC。


可以通过中间:filter 环节进行日期数据处理,包括:转时区操作。


小结一下:
 Elasticsearch 滞后8个小时等时区问题,一网打尽!-开源基础软件社区


我们看一下东8区百度百科定义:东八区(UTC/GMT+08:00)是比世界协调时间(UTC)/格林尼治时间(GMT)快8小时的时区,理论上的位置是位于东经112.5度至127.5度之间,是东盟标准的其中一个候选时区。当格林尼治标准时间为0:00时,东八区的标准时间为08:00。

 

通过上面的定义,能加深对 logstash 同步数据后,数据滞后8小时的理解。

 

Elasticsearch 滞后8个小时等时区问题,一网打尽!-开源基础软件社区


基于上面的分析,如何解决时区问题呢?


由于 kibana 支持手动修改时区,不在下文讨论 的范围之内。实战项目中,自己根据业务需求修改即可。

 

那么问题就转嫁为:写入的时候转换成给定时区(如:东8区)就可以了。


3.1 方案一:ingest 预处理为东8区时区


 • 步骤 1:定义预处理管道:chage_utc_to_asiash(名称自己定义即可)。


在该管道中实现了时区转换。


 • 步骤 2:创建索引同时指定缺省管道:chage_utc_to_asiash。


 • 步骤 3:写入数据(单条或 bulk 批量均可)

Elasticsearch 滞后8个小时等时区问题,一网打尽!-开源基础软件社区

当写入数据后,执行检索时,kibana dev tool 返回结果如下:

Elasticsearch 滞后8个小时等时区问题,一网打尽!-开源基础软件社区

最明显的特征是:多了+08:00 时区(东8区)标志。


然后,我们用:kibana discover可视化展示一下:
 Elasticsearch 滞后8个小时等时区问题,一网打尽!-开源基础软件社区

上图中,kibana 采用默认浏览器时区。


如果不做上面的 ingest 预处理实现,会怎么样呢?大家如果实现过,肯定会感触很深。


需要我们在kibana中切换时间范围,才能找到之前写入的数据。


ingest 预处理时区的好处:方便、灵活的实现了写入数据的时区转换。


3.2 方案二:logstash 中间 filter 环节处理


拿真实同步案例讲解一下时区处理:


 • 数据源端:Mysql;


 • 数据目的端:Elasticsearch;


 • 同步方式:logstash,本质借助:logstash_input_jdbc 插件同步;


 • 时区处理:logstash filter 环节 ruby 脚本处理。 


如下只给出了中间 filter 环节的脚本:
Elasticsearch 滞后8个小时等时区问题,一网打尽!-开源基础软件社区

三行脚本含义,解释如下:


 • 第一行:将 publish_time 时间加 8 小时处理,赋值给 timestamp。


publish_time  到了 logstash 已转成了 UTC 时区了。


timestamp 类似似 C 语言中的交换两个数函数中的 temp 临时变量。


 • 第二行:将 timestamp 时间赋值给 publish_time。


 • 第三行:删除中转字段:timestamp。


源数据Mysql 效果:

 Elasticsearch 滞后8个小时等时区问题,一网打尽!-开源基础软件社区

Elasticsearch 滞后8个小时等时区问题,一网打尽!-开源基础软件社区

如上两个截图,对比一下区别:


 • publish_time 做了时区处理,两者时间已一致,都是东 8 区。


 • update_time 未做时间处理,写入Elasticsearch 后由东8区时间 10:57:31 转为UTC时区时间 02:57:31,少了8小时。


Elasticsearch 滞后8个小时等时区问题,一网打尽!-开源基础软件社区


假定我们写入ES前未做时区处理(实战环节常有的场景),但是检索或者聚合的时候想做时区处理可以吗?

 

可以的,具体实现方式如下:

Elasticsearch 滞后8个小时等时区问题,一网打尽!-开源基础软件社区

如上示例中,整合了检索和聚合,有两个要点:


 • 要点1:range query 中指定时区检索。


 • 要点2:data_histogram 聚合中指定时区聚合。


Elasticsearch 滞后8个小时等时区问题,一网打尽!-开源基础软件社区
数据写入时间不一致、数据滞后8小时等时区问题的本质是:各个处理端时区不一致,写入源的时区、Kibana默认是本地时区(如中国为:东8区时区),而 logstash、Elasticsearch 是UTC时区。
 Elasticsearch 滞后8个小时等时区问题,一网打尽!-开源基础软件社区

本文给出了两种写入前预处理的解决方案,方案一:基于管道预处理;方案二:基于logstash filter 中间环节过滤。两种方案各有利弊,预处理管道相对更轻量级,实战选型建议根据业务需求。本文最后指出在检索和聚合环节使用时区处理方式。

 

大家在实战中有没有遇到时区问题,是怎么解决的呢?欢迎大家留言交流。

收藏
回复
举报
回复
添加资源
添加资源将有机会获得更多曝光,你也可以直接关联已上传资源 去关联
    相关推荐