I ran into this threat in Github so I just copy-paste:
- Steps to Reproduce: Enable Apache module in Filebeat and use the DNS processor; configuration example below:
- dns: type: reverse action: append fields: source.ip: source.hostname destination.ip: destination.hostname success_cache: capacity.initial: 1000 capacity.max: 10000 failure_cache: capacity.initial: 1000 capacity.max: 10000 ttl: 1m nameservers: ['22.214.171.124', '126.96.36.199'] timeout: 500ms tag_on_failure: [_dns_reverse_lookup_failed]
In my particular case I'm also using other processors, namely the
add_fields processor. While that processor works, DNS silently fails.
There will be no
destination.hostname in the http events dispatched to Elasticseach.
On a second thought I've noticed that this is not working for the
auth module either, which leads me to believe that the DNS processor will not work on single line logs like Apache and SSH.
It's possible that this is related to the order in which the processor is ran. If it happens after the Filebeat pipeline transforms that single line log to ECS-mapped event, it should work (as the fields configured in the DNS processor are present), but if it happens before then it's not expected to work, as those single line logs don't hold any