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

[alchy]

Hi,

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):

   processors:

   • decode_json_fields:
     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
thanks

[alchy]

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

[alchy]

@alchy

"20200601T070018-0100"

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):

processors:
  - timestamp:
      field: @timestamp
      target_field: @filebeat_timestamp
      layouts: 
        - "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

[alchy]

@alchy

20200601T070018-0100

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.

[kvch (Noémi Ványi)]

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: https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-input-log.html#filebeat-input-log-config-json