| Elasticsearch 滞后8个小时等时区问题，一网打尽！ | 您所在的位置：网站首页 › 时区怎么划分出来的 › Elasticsearch 滞后8个小时等时区问题，一网打尽！ |
Elasticsearch 滞后8个小时等时区问题，一网打尽！
|
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 默认时区不可以修改。  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.  2.3 Logstash 默认时区是？能改吗？
默认：UTC。 可以通过中间：filter 环节进行日期数据处理，包括：转时区操作。 小结一下：  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 批量均可）代码语言：javascript复制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 返回结果如下： 代码语言：javascript复制 "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可视化展示一下：  上图中，kibana 采用默认浏览器时区。 如果不做上面的 ingest 预处理实现，会怎么样呢？大家如果实现过，肯定会感触很深。 需要我们在kibana中切换时间范围，才能找到之前写入的数据。 ingest 预处理时区的好处：方便、灵活的实现了写入数据的时区转换。 3.2 方案二：logstash 中间 filter 环节处理拿真实同步案例讲解一下时区处理： 数据源端：Mysql；数据目的端：Elasticsearch；同步方式：logstash，本质借助：logstash_input_jdbc 插件同步；时区处理：logstash filter 环节 ruby 脚本处理。如下只给出了中间 filter 环节的脚本： 代码语言：javascript复制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 效果：  同步后 效果：  如上两个截图，对比一下区别： publish_time 做了时区处理，两者时间已一致，都是东 8 区。update_time 未做时间处理，写入Elasticsearch 后由东8区时间 10:57:31 转为UTC时区时间 02:57:31，少了8小时。4、检索和聚合的时候指定时区假定我们写入ES前未做时区处理（实战环节常有的场景），但是检索或者聚合的时候想做时区处理可以吗？ 可以的，具体实现方式如下： 代码语言：javascript复制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时区。  本文给出了两种写入前预处理的解决方案，方案一：基于管道预处理；方案二：基于logstash filter 中间环节过滤。两种方案各有利弊，预处理管道相对更轻量级，实战选型建议根据业务需求。本文最后指出在检索和聚合环节使用时区处理方式。 大家在实战中有没有遇到时区问题，是怎么解决的呢？欢迎大家留言交流。 参考https://t.zsxq.com/2nYnq76 |
【本文地址】
| 今日新闻 |
| 推荐新闻 |
| 专题文章 |