Backport to 6.x: Handle IPv6 zone id in IIS filebeat ingest pipeline for access logs too#10029
Conversation
|
jenkins, test this |
|
@jsoriano Any reason why you didn't backport your IPv6 zone fix to 6.5? Original reporter was on 6.5. I'm not used to doing backports. Not sure what our policy is, on what goes into which past version. |
No reason, I was just not so sure of considering this just a fix/workaround or an enhancement. I am also not so happy with this workaround, I wouldn't like to have to add this to all pipelines that can have IPv6 addresses. |
… pipeline for access logs too (#10030)
|
@jsoriano Agreed, I don't want us to have to do this cleanup everywhere. Hopefully Elasticsearch adds support for the Zone ID in the geoip plugin and in the Let's backport to 6.5, yes. Are you saying you're willing to backport both fixes? ;-) |
|
@webmat yes, I opened an issue, it seems that this will be implemented for the geoip plugin, but not in the general implementation in Elasticsearch (elastic/elasticsearch#37107) And ok, I backport these fixes 🙂 |
… ingest pipeline for access logs too (elastic#10030) (cherry picked from commit e05f967)
|
@jsoriano Perfect, thank you! Make sure to ping me on the 6.5 PR :-) |
… ingest pipeline for access logs too (elastic#10030)
This is a manual backport, to fix an issue with the iis module, with regards to IP literals containing an IPv6 zone ID (issue #9836). This was fixed in master as part of the ECS conversion of the iis module (#9955).
Contrary to the fix in master, this fix is in line with Jaime's fix for the IIS error logs (#9869, #9932, #9933). This means the IP literal is saved as is to
iis.access.remote_ip(including the zone). This is fine, because this is a keyword field. The GeoIP processor then uses an IP literal with the zone stripped out, to avoid hitting the error. Note that this cleaned up field is not kept around in the 6.x line.