Filebeat touches my @timestamp even I've explicitly said don't do this!


thank you for reading, the story goes:

  1. generated event in file
    {"@timestamp": "20200601T070018-0100", "src_type": ""...} ... ... ... all the lines with in the same @timestamp format

  2. filebeat 7.7 grabs file on the host and sends content to logstash, I don't need filebeat even barely [touches] my data (filebeat.yml):


    • decode_json_fields:
      overwrite_keys: false <- do not touch, should be default, but...
      add_error_key: true
  3. logstash 7.7 gets the data, no rules for @timestap, I don't need logstash touches my data either, especially the @timestamp, I suppose this field should not be modified when no date filter...

  4. elasticsearch has the respective field set as basic_date_time_no_millis, the source format fits, even manual ingestion via POST works, but the format gets garbled somewhere on the road:

  5. The indexing error from logstash-plain.log:
    '2020-06-01T07:40:08.669Z'", "caused_by"=>{"type"=>"illegal_argument_exception", "reason"=>"failed to parse date field [2020-06-01T07:40:08.669Z] with format [basic_date_time_no_millis]", "caused_by"=>{"type"=>"date_time_parse_exception", "reason"=>"date_time_parse_exception: Failed to parse with all enclosed parsers"}}}}}}

Who and why WTF manipulates my @timestamp when I've explicitly said don't do this? How can I be more explicit?

any idea will be appreciated

filebeat does that! debug output to file proves that.
I've not idea how to prevent this when overwrite_keys: false is set already...

according to documentation, there is the processor for timestamp, which should enable tweaking logstash's @timestamp behaviour. according to documentation, this should work (in plain, please use the @timestamp, but write your modification elsewhere):

  - timestamp:
      field: @timestamp
      target_field: @filebeat_timestamp
        - "Mon Jan 2 15:04:05 MST 2006"

but this won't work, the logstash won't start
as a bonus, seems nothing relevant is logged

the best answer yet seems to be avoid using @timestamp in your data while transfering them with filebeat. even if you manage filebeat won't touch your data, there are other metadata with @timestamp around your data and it seems those metadata are used while indexing in the elastic as the primary @timestamp. these @timestap/s are related to time, when filebeat reads the file from disk.

Indeed, @timestamp is reserved field name in Beats. That's where the time of reading is saved when reading events from arbitrary sources.

However, if you use the json.* option in the log input, you can overwrite the value in @timestamp. See more:

1 Like

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.