本站提供互联网编程技术交流分享,部分技术教程不断更新中,请随时关注或联系我寻求帮助 ,同时也欢迎有兴趣的朋友进行投稿。

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

ELK 熊哥club 250℃ 0评论

1、实战问题

如下都是实战环节遇到的问题:

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

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

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

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

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

2、时区问题拆解

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

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个小时等时区问题,一网打尽!

  • logstash 默认 UTC 时区。
  • Elasticsearch 默认 UTC 时区。
  • Kibana 默认浏览器时区,基本我们用就是:东八区。
  • 如果基于Mysql 同步数据,Mysql 数据是:东八区。
我们看一下东8区百度百科定义:东八区(UTC/GMT+08:00)是比世界协调时间(UTC)/格林尼治时间(GMT)快8小时的时区,理论上的位置是位于东经112.5度至127.5度之间,是东盟标准的其中一个候选时区。当格林尼治标准时间为0:00时,东八区的标准时间为08:00。
通过上面的定义,能加深对 logstash 同步数据后,数据滞后8小时的理解。

3、时区问题解决方案

基于上面的分析,如何解决时区问题呢?
由于 kibana 支持手动修改时区,不在下文讨论 的范围之内。实战项目中,自己根据业务需求修改即可。
那么问题就转嫁为:写入的时候转换成给定时区(如:东8区)就可以了。

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

  • 步骤 1:定义预处理管道:chage_utc_to_asiash(名称自己定义即可)。
在该管道中实现了时区转换。
  • 步骤 2:创建索引同时指定缺省管道:chage_utc_to_asiash。
  • 步骤 3:写入数据(单条或 bulk 批量均可)
PUT _ingest/pipeline/chage_utc_to_asiash
{
  "processors": [
    {
      "date" : {
        "field" : "my_time",
        "target_field""my_time", 
        "formats" : ["yyyy-MM-dd HH:mm:ss"],
        "timezone" : "Asia/Shanghai"
      }
    }
  ]
}

PUT my-index-000001
{
  "settings": {
    "default_pipeline""chage_utc_to_asiash"
  },
  "mappings": {
    "properties": {
      "my_time": {
        "type""date"
      }
    }
  }
}

PUT my-index-000001/_doc/1
{
  "my_time""2021-08-09 08:07:16"
当写入数据后,执行检索时,kibana dev tool 返回结果如下:
 "hits" : [
      {
        "_index" : "my-index-000001",
        "_type" : "_doc",
        "_id" : "1",
        "_score" : 1.0,
        "_source" : {
          "my_time" : "2021-08-09T08:07:16.000+08:00"
        }
      }
    ]
最明显的特征是:多了+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 环节的脚本:
filter {
 ruby { 
   code => "event.set('timestamp', event.get('publish_time').time.localtime + 8*60*60)" 
 }
 ruby {
   code => "event.set('publish_time',event.get('timestamp'))"
 }
 mutate {
   remove_field => ["timestamp"]
 }
}
三行脚本含义,解释如下:
  • 第一行:将 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小时。

4、检索和聚合的时候指定时区

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

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

POST testindex/_search?pretty
{
  "query": {
    "range": {
      "date": {
        "gte""2020-01-01 00:00:00",
        "lte""2020-01-03 23:59:59",
        "format""yyyy-MM-dd HH:mm:ss",
        "time_zone""+08:00"
      }
    }
},
  "size": 0,
  "aggs": {
    "per_day": {
      "date_histogram": {
        "calendar_interval""day",
        "field""date",
        "time_zone""+08:00"
      }
    }
  }
}

如上示例中,整合了检索和聚合,有两个要点:
  • 要点1:range query 中指定时区检索。
  • 要点2:data_histogram 聚合中指定时区聚合。

5、小结

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

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

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

参考

https://t.zsxq.com/2nYnq76

本文地址: https://www.xiongge.club/1630.html

转载请注明:熊哥clubElasticsearch 滞后8个小时等时区问题,一网打尽!

©熊哥club,本站推荐使用的主机:阿里云,CDN建议使用七牛云


关注微信公众号『熊哥club』

免费提供IT技术指导交流
  关注博主不迷路~

喜欢 (0)
[您的支持是我最大的动力]
分享 (0)
发表我的评论
取消评论
表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
×
订阅图标按钮