ELK開發日記(2) - 超坑爹的Filebeat 7.2.0時區漂移（UTC+16)解決方案

我是一個生活在東八區（UTC+8)的孩子，阿里雲的服務器時區在部署時也默認設置爲東八區
但我萬萬沒想到，有一天會看到東十六區的存在...

一、問題復現

原始問題我已記錄在 Elastic官方社區 裏

一切坑的起源，來自於最新的modules命令，該命令以組件的形式管理配置文件，非常快捷：

filebeat modules enable system elasticsearch kibana

modules命令是filebeat的組件化管理命令。

filebeat 7.2.0把面向不同對象的pipeline視爲不同的Modules，通過控制modules的開關來快速管理不同對象的日誌採集狀態。

啓用模組後，使用setup命令配置環境：

filebeat setup -e
service filebeat start #使用service啓動filebeat

啓動之後一切就開始正常工作了，然而接下來神奇的事情出現了

在我打開kibana進行可視化分析的時候，所有的日誌時間往前漂移了8個小時，也就是UTC+8再+8！

神奇的時間漂移日誌，紅線是當前時間，綠色直方圖是日誌時間分佈
可以看到所有日誌的時間都比真實時間快了8個小時

二、問題溯源

我起初懷疑filebeat二次解析，把utc+8時間再加了個8

然而日誌原始JSON數據告訴我並不是這樣

filebeat的文檔中@timestamp的記錄值和系統時間相同（UTC+8)，但@timestamp本身記錄的應該是UTC值

於是kibana將其解析爲UTC值，並在此之上把時區又加了一個8。

於是UTC+16出現了...

系統時間

UTC+8 2019/07/29 20:56:14

日誌時間

Jul 29 20:56:14

@timestamp 記錄的時間

2019-07-29T20:56:14.000Z

@timestamp 應該記錄的時間

2019-07-29T12:56:14.000Z

三、解決方案

在我調了一天bug，在github上翻閱無數個Pull Request，整個人接近崩潰的時候，一個帖子點亮了我：

[官方論壇] Filebeat 6.4.2 the timestamp is not right

這是我第一次在帖子裏看到有人討論covert_timezone配置，這個配置項一看就是跟時區有關的

只需要在path/to/conf/module.d/目錄裏所有的.yml開啓var.convert_timezone就行！！！

但是這也太尼瑪不顯眼了吧！！

四、附錄

日誌文檔原始JSON數據，@timstamp被記錄成了UTC+8時區（@timestamp應該是UTC記錄）:

{
  "_index": "filebeat-7.2.0-2019.07.28-000001",
  "_type": "_doc",
  "_id": "qRLNPWwBaHGrHZ27tQUU",
  "_version": 1,
  "_score": null,
  "_source": {
    "agent": {
      "hostname": "bigiron",
      "id": "3eb06835-b68e-4b25-9ec1-1ebf0bac83a3",
      "ephemeral_id": "fd8648df-4eab-4fd2-b915-97fb631211b6",
      "type": "filebeat",
      "version": "7.2.0"
    },
    "process": {
      "name": "filebeat",
      "pid": 28369
    },
    "log": {
      "file": {
        "path": "/var/log/syslog"
      },
      "offset": 1964308
    },
    "fileset": {
      "name": "syslog"
    },
    "message": "2019-07-29T20:56:14.994+0800#011INFO#011log/harvester.go:253#011Harvester started for file: /var/log/apache2/access.log",
    "cloud": {
      "availability_zone": "cn-beijing-a",
      "instance": {
        "id": "i-2ze74ci7j8m68giheosd"
      },
      "provider": "ecs",
      "region": "cn-beijing"
    },
    "input": {
      "type": "log"
    },
    "@timestamp": "2019-07-29T20:56:14.000Z",
    "system": {
      "syslog": {}
    },
    "ecs": {
      "version": "1.0.0"
    },
    "service": {
      "type": "system"
    },
    "host": {
      "hostname": "bigiron",
      "os": {
        "kernel": "4.4.0-146-generic",
        "codename": "xenial",
        "name": "Ubuntu",
        "family": "debian",
        "version": "16.04.6 LTS (Xenial Xerus)",
        "platform": "ubuntu"
      },
      "containerized": false,
      "name": "bigiron",
      "id": "a76d0b1176a3140a8e07cb725964722b",
      "architecture": "x86_64"
    },
    "event": {
      "timezone": "+08:00",
      "module": "system",
      "dataset": "system.syslog"
    }
  },
  "fields": {
    "@timestamp": [
      "2019-07-29T20:56:14.000Z"
    ],
    "suricata.eve.timestamp": [
      "2019-07-29T20:56:14.000Z"
    ]
  },
  "sort": [
    1564433774000
  ]
}