Elasticsearch: Unify processors option for field name

[javanna]

Date processor parses match_field, Geoip processor parses source_field, while others parse simply field. It may get tricky with processors that support both source_field and target_field, but shall we try and streamline the processors configuration so that we don't have to go and check the documentation for each single processor when writing a pipeline?

[clintongormley]

I'd standardise on using field. Also, I was surprised to see that eg split didn't support target_field - I think that should be standard too, no? i.e. target_field is optional and defaults to field

[martijnvg]

+1

Just one question, so in cases where there is a source field and a target field we will have field and target_field as options?

[clintongormley]

Just one question, so in cases where there is a source field and a target field we will have field and target_field as options?

I think that works. Currently we only support target_field on convert and date, with it defaulting to @timestamp for the date processor. I think it is OK to always use field to mean "the field we're getting the value from" and target_field to mean "the field we're applying the change to, which defaults to field"

Seems pretty clear to me. And the benefit of consistency makes it less likely that users will get confused.

[martijnvg]

The geoip and attachment processors also have a fields option, which controls what properties from maxmind db and tika are used to enrich the document being processed. Naming wise this can become confusing if we stream line to use field. I think we should rename fields in both of these processors. The option name properties feels like a good choice to me.