Loads of geoip errors

I'm getting loads of the following types of error:
[2017-02-21T18:22:02,599][WARN ][logstash.outputs.elasticsearch] Failed action. {:status=>400, :action=>["index", {:_id=>nil, :_index=>"filebeat-2017.02.21", :_type=>"syslog", :_routing=>nil}, 2017-02-21T07:21:59.000Z xxxxxxxx Feb 21 18:21:59 xxxxxx dovecot: service=pop3, user=xxxxx@xxxxxxxx, ip=[xxx.xxx.xxx.xxx]. Disconnected: Logged out rcvd=14, sent=67, top=0/0, retr=0/0, del=0/0, size=0], :response=>{"index"=>{"_index"=>"filebeat-2017.02.21", "_type"=>"syslog", "_id"=>"AVpfjGuewILVxJ6rNOuQ", "status"=>400, "error"=>{"type"=>"mapper_parsing_exception", "reason"=>"failed to parse", "caused_by"=>{"type"=>"illegal_argument_exception", "reason"=>"Can't parse [index] value [not_analyzed] for field [region_code], expected [true] or [false]"}}}}}

I have a feeling it's coming from the geo_ip plugin when it can't lookup the region_code field. The field that I really care about (country_code) seems to be working fine but these errors fill the logs. Does anyone have any idea how to prevent these errors from occurring?

Running Logstash 5.2.1, ES 5.2.1

It looks like your index template attempts to set index: "not_analyzed" for the region_code field, but that's IIRC only valid prior to ES 5.0. Are you using your own index template or the one that ships with Logstash? In the latter case, perhaps Logstash is choosing the wrong template. I think it has some kind of version autodetect mechanism.

Thanks for the reply Magnus. Although I set all this up years ago and have been progressively upgrading the same install over and over, i'm pretty sure i'm using the Logstash template. Is there anything I can do about it?

Then I suspect Logstash is picking the wrong template for your ES. You can try disabling Logstash's template management by setting manage_template => false and see if that makes a difference.

Turns out I had already set manage_template to false. I must have done this some time ago and forgotten about it. So I tried removing the directive thereby setting it to true and it's still throwing the error.

The problem seems to have gone away after the daily filebeat index rolled over.

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