Logstash - Date function - Mapping timestamp ends with error _dateparsefailure when a hour is 02

Elastic Stack Logstash
1

Hello,
I figured out one thing:
Logstash 7.6.0 is not able map date to @timestamp field when timestamp has 02 in hour positio.

In pipeline configuration file:

if [timestamp]  {
  date {
    match => ["timestamp", "yyyy-MM-dd HH:mm:ss,SSS",  "yyyy-MM-dd HH:mm:ss.SSS", "ISO8601" ]
    target => "@timestamp"
    remove_field => ["timestamp"]
  }
}

Grok pattern works fine. In the field timestamp is correct value, e.g.: 2020-03-29 03:35:47.392 without additional whitespaces.
I simplified parser and date mapping and found out that error _dateparsefailure occur only on lines where hour is 02.

2020-03-29 02:35:47.392 INFO [xxx] Some message

 
There is example of log file.

2020-03-29 15:35:47.392 INFO [xxx] Some message
2020-03-29 14:35:47.392 INFO [xxx] Some message
2020-03-29 13:35:47.392 INFO [xxx] Some message
2020-03-29 12:35:47.392 INFO [xxx] Some message
2020-03-29 11:35:47.392 INFO [xxx] Some message
2020-03-29 10:35:47.392 INFO [xxx] Some message
2020-03-29 09:35:47.392 INFO [xxx] Some message
2020-03-29 08:35:47.392 INFO [xxx] Some message
2020-03-29 07:35:47.392 INFO [xxx] Some message
2020-03-29 06:35:47.392 INFO [xxx] Some message
2020-03-29 05:35:47.392 INFO [xxx] Some message
2020-03-29 04:35:47.392 INFO [xxx] Some message
2020-03-29 03:35:47.392 INFO [xxx] Some message
2020-03-29 02:35:47.392 INFO [xxx] Some message
2020-03-29 01:35:47.392 INFO [xxx] Some message

Is it a bug or am I doing something wrong?
Vašek

2

Did 02:35 occur? Did daylight savings time cause the time to go directly from 01:59:59 to 03:00:00 that day?

3

Hello @Badger, mapping fails on these 4 lines:

2020-03-29 02:06:54.462 INFO  [liferay/scheduler_dispatch-4]
2020-03-29 02:07:09.545 INFO  [liferay/scheduler_dispatch-4]
2020-03-29 02:35:47.392 INFO  [default task-2]
2020-03-29 02:35:47.397 ERROR [default task-2]

Time in logs is in UTC. Our servers are in +1 UTC (Prague). But why would mapping fail?

4

Aaa.. so it looks that problem is in daylight saving time change. Yes, the time should go to 03:00:00. So how we can achieve to correctly map this dates?

5

When I have dealt with this in the past (when analyzing NYPD arrest records) I used a series of gsubs

mutate { gsub => [ "someField", "^2020-03-29 02:", "2020-03-29 03:" ] }

That only deals with the one hour. When your logs contain "2020-03-29 03:35:47.392" they may well mean "2020-03-29 04:35:47.392". It also ignores the problems when time goes back later in the year. Personally I only cared whether arrests were recorded in the right month, so an hour with twice as many events as it should have had, and an hour that had no events did not bother me.

6

Thank you @Badger. It helps me.