Logstash Illegal Argument Exception while parsing date

Elastic Stack Logstash
1

Hi there,

I've got three questions around Logstash:

  1. We're using an older version of Logstash (6.5.4) and experiencing currently an issue while parsing a date. I've got absolutely no idea anymore what I can do to make it work.

This is the exception:

[2022-04-25T09:32:54,248][WARN ][logstash.outputs.elasticsearch] Could not index event to Elasticsearch. {:status=>400, :action=>["index", {:_id=>nil, :_index=>"webtools-dev-2022.04.25", :_type=>"doc", :routing=>nil}, #<LogStash::Event:0x12bd057c>], :response=>{"index"=>{"_index"=>"webtools-dev-2022.04.25", "_type"=>"doc", "_id"=>"5usRYIABZkNlZjpwFuFa", "status"=>400, "error"=>{"type"=>"mapper_parsing_exception", "reason"=>"failed to parse field [log_timestamp] of type [date]", "caused_by"=>{"type"=>"illegal_argument_exception", "reason"=>"Invalid format: \"2022-04-25 09:32:41.847\" is malformed at \" 09:32:41.847\""}}}}}
[2022-04-25T09:32:54,248][WARN ][logstash.outputs.elasticsearch] Could not index event to Elasticsearch. {:status=>400, :action=>["index", {:_id=>nil, :_index=>"webtools-dev-2022.04.25", :_type=>"doc", :routing=>nil}, #<LogStash::Event:0x50fd26ba>], :response=>{"index"=>{"_index"=>"webtools-dev-2022.04.25", "_type"=>"doc", "_id"=>"5-sRYIABZkNlZjpwFuFa", "status"=>400, "error"=>{"type"=>"mapper_parsing_exception", "reason"=>"failed to parse field [log_timestamp] of type [date]", "caused_by"=>{"type"=>"illegal_argument_exception", "reason"=>"Invalid format: \"09:32:46.822\" is malformed at \":32:46.822\""}}}}}

This is our date parsing part:

    date {
        match => [ "log_timestamp", "ISO8601", "MMM dd, yyyy HH:mm:ss a", "yyyy-MM-dd HH:mm:ss.SSS", "yyyy-MM-dd HH:mm:ss,SSS", "HH:mm:ss.SSS", "dd-MMM-yyyy HH:mm:ss.SSS"]
        timezone => "Europe/Berlin"
        target => "@timestamp"
    }

If I use log_timestamp - the originating field - as target it funnily works, but if I use @timestamp it throws the exception above. I'm pretty much sure our parse expressions are correct. We need different expressions because unfortunately the input expressions are not very streamlined yet.

  1. Furthermore I'm also wondering how I can add the current day to a timestamp that only exists of the time.

  2. I found a @time field in the index and don't know where it originates from. Is that a field Filebeat adds by default somehow? It's exactly the log line timestamp and maybe I can just use that field instead parsing the expression then.

Thanks Bastian

2

That makes sense. elasticsearch is complaining about the format of the [log_timestamp] field, so if you overwrite it with the output of a date filter that may well enable elasticsearch to parse it.

You need to review the mapping for the index. The date parsers are listed here. It may be your index is configured to expect [log_timestamp] to be a basic_date rather than a strict_date_optional_time.

3

I see, thanks for the pointer. I've seen that log_timestamp is a string, which makes sense that it's working then.

What I actually want to achieve is to parse this field and get the parsed value into @timestamp which is of type date, simply date with no additional format specificers or so.

I'm sorry but I still don't understand what the issue is, especially for the first exception line. I get that it might throw an exception for timestamp only when expecting a full fledged date.

We have the same mapping in other indexes and there it seems to work...type date showing a date and a time with no additional format definition in the mapping.

4

What is the mapping of the field that the exception occurs for?

5

Sorry for the late reply.

          "@timestamp" : {
            "type" : "date"
          },
          "log_timestamp" : {
            "type" : "date"
          },
6

Hard to say why that would produce this warning. The default format for a field of type "date" is "strict_date_optional_time||epoch_millis", and that should parse the values that got warnings. If your index had

 "log_timestamp" : {
     "type" : "date",
     "format": "yyyy-MM-dd"
 },

then I would expect the warnings you showed.

7

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