I'm using the suricata module from beats 7.17.3 to parse suricata 6.0.4 EVE json logs and I'm getting the following parse error:
"error"=>{"type"=>"mapper_parsing_exception", "reason"=>"object mapping for [suricata.eve.http.content_range] tried to parse field [content_range]
as object, but found a concrete value"
"content_range"=>"bytes 0-859529/859530"
There does not appears to be a mapping for suricata.eve.http_content_range in the filebeat template.
# suricata filebeat module
filter {
if "suricata" in [tags] {
mutate {
# https://redmine.openinfosecfoundation.org/issues/5320
# "error"=>{"type"=>"mapper_parsing_exception", "reason"=>"object mapping for [suricata.eve.http.content_range] tried to parse field [content_range] as object, but found a concrete value"}}}}
remove_field => [ "[suricata][eve][http][content_range]" ]
}
}
}
I guess I'm not sure yet - need to wait for an event to occur again. Maybe throw in two remove_fields to get both. I really don't particularly care about content_range here.
Where did you get this from is that out of filebeat? I am surprised it will actually output that.
So what I think is going to happen according to what I see is that whichever content_range is defined last the string or the object will be in the json because the json decoder will do that ... then you will drop the content_range everytime...
i.e. I ran test with "content_range":"bytes 1140-1205/23709" and "content_range":{"raw":"bytes 1111-1205/23709","start":1140,"end":1205,"size":23709} in different orders and the json that ends up after it is decoded in logstash is what ever is the last one...
SO I think if you wanted to keep most of the "content_range":{"raw":"bytes 1111-1205/23709","start":1140,"end":1205,"size":23709} you could check if
"[suricata][eve][http][content_range][raw]" exists and if does not...then drop the field.
input {
beats {
port => 5044
codec => "json"
}
}
##
# filter {
# mutate {
# # https://redmine.openinfosecfoundation.org/issues/5320
# # "error"=>{"type"=>"mapper_parsing_exception", "reason"=>"object mapping for [suricata.eve.http.content_range] tried to parse field [content_range] as object, but found a concrete value"}}}}
# remove_field => [ "[http][content_range]" ]
# }
# }
output{
stdout {}
}
The you will see in logstash the codec keeps the last... so unfortunately is if that is what the message looks like above you will always get the 2nd instance of content_range
NOW all that said ... now what I think is happening is that occasionally you are getting a message that does NOT have the 2nd string content_range and then when it tries to write the content_range Object it fails. or vice versa.
SO I think you could detect the object and turn it back into the string... or parse the string every-time and make it the content_range object.
And since the mapping appears to be dynamic... which ever type arrives first wins the mapping!
According to the very top error.. the mapping is an content_range Object.... so you need to decide what to do ... unfortunately I think the the json decoder is just going to pick the last one each time... seems like you an object first... you could put in code to detect if is a string then parse yourself.
Or detect if a string / not object and just rename it.
Apologies that was a lot... but interesting problem
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.