[processor/geoipprocessor] Add attributes parameter and consider both source.address and client.address by default

[bencehornak]

Description

Currently, the geoipprocessor reads the source.address attribute of the processed record, which is used to describe network exchanges/packets only (see the semantic conventions). For HTTP requests there is another attribute, called client.address with the same format (see the semantic conventions).

In this PR I am changing the geoipprocessor take both attributes into account by default (if both are defined client.attributes wins). Additionally, the attributes are configurable via the new attributes parameter to allow geo ip lookup based on custom attributes.

Testing

I duplicated the source address located in inner attributes test case for client.address, as they should work the same way.

Documentation

Updated the README with the second attribute.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: bencehornak / name: Bence Hornák (7027470, 8cd5287, 37acb5d, 3ad4faf, 22cd8a2, 1836258, b62e20f, 3f88565, dd1e8cf, 0a5d848, e6ca723)

[rogercoll]

LGTM. The client.address attribute closely resembles source.address, so I support adding it to the default lookup attributes. (It would be great to have a configuration option to allow any arbitrary attribute key).

My assumption is that if both attributes are defined, they will likely have the same value, making the lookup order less critical.

[bencehornak]

@rogercoll I've implemented a new configuration parameter (attributes), which allows specifying the desired attributes.

[bencehornak]

I think the attributes should default to something other than [source.address, client.address] when context: resource, because these attributes apply to spans (i.e. records), not resources (see the General Attributes Semantic Conventions).

I could imagine the host.ip for example, but I don't see it right away, why somebody would look up server IP addresses. @rogercoll can you give me an idea about what the intended purpose of context: resource is?

Thanks in advance!

[rogercoll]

Just added some nits, overall LGTM!

[rogercoll]

I could imagine the host.ip for example, but I don't see it right away, why somebody would look up server IP addresses. @rogercoll can you give me an idea about what the intended purpose of context: resource is?

For example, the redis receiver creates metrics that contain the server.address as resource attribute (resource context). One could use the geoIP processor to add geographical metadata about their internal Redis servers. The same concept could be applied to the mentioned host.ip, add location metadata of their distributed servers.

I think the attributes should default to something other than [source.address, client.address] when context: resource, because these attributes apply to spans (i.e. records), not resources (see the General Attributes Semantic Conventions).

That's a good point, would you mind creating an issue with these findings? We can definitely consider changing the attributes defaults depending on the signal type.