[processor/dnslookup] Add log processing and host file resolver

[kaisecheng]

Description

This PR adds log processing for DNS Lookup Processor and implements host files resolver.
The Resolver interface defines Resolve() for forward lookup and Reverse() for reverse lookup.
Hostfile resolver supports a list of hostfiles to resolve IP <> hostname.

Config

  dnslookup:
    # Forward DNS resolution configuration (hostname to IP)
    resolve:
      # Context for attributes: "resource" or "record". Default: "resource"
      context: "record"
      # List of attributes to check for hostnames. The first valid hostname is used. Default: ["source.address"]
      source_attributes: ["source.address"]
      # Attribute to store the resolved IP.  Default: "source.ip"
      target_attribute: "source.ip"

    # Reverse DNS resolution configuration (IP to hostname)
    reverse:
      # Context for attributes: "resource" or "record". Default: "resource"
      context: "record"
      # List of attributes to check for IPs. The first valid IP is used. Default: ["source.ip"]
      source_attributes: ["server.ip"]
      # Attribute to store the resolved hostname. Default: "source.address"
      target_attribute: "server.address"
    
    # Path to custom host files. Default: []
    hostfiles: 
      - "/path/to/host/file"
      - "/path/to/other/file"

nameserver resolver, system default resolver and cache implementation will be in the next PR

Link to tracking issue

Parts of #34398

Testing

• integration tests for log processor
• unit tests for hostfile resolver

Documentation

• added README.md

[andrzej-stencel]

Did you consider network.peer.address? See here for an example: https://opentelemetry.io/docs/specs/semconv/http/http-spans/#http-client-server-example.

[kaisecheng]

*_address in semconv can be IP or hostname. Ideally, an attribute dedicated solely to the IP address would be great. I am not sure "network.peer" is the right description to store the resolved IP.

If you think network.peer is better than creating a new attribute, I can change it.

[edmocosta]

I think that makes sense for HTTP, but in the DNS context, the peer part would make it confusing IMO, as it's not the DNS server's peer address we're referring to on this config.

[kaisecheng]

@edmocosta I have discussed with Andrzej that this is the minimum testable processor and he agreed to move on base on the current functionality. A noop resolver is added to temporarily replace the default resolver. This is ready for your review.

[edmocosta]

Do we need to support this Enabled config? If the lookup is configured, it's enabled, otherwise users could just remove/comment it on their configuration.

[kaisecheng]

My concern is the default value for Resolve and Reverse. Typically, a processor has default values and semconv attributes to simplify user configuration.

lookup	source_attributes	target_attribute
Resolve	"source.address"	"source.ip"
Reverse	"source.ip"	"source.address"

Without enabled, two lookups overwrite each other's result. Therefore I set enabled: false to Reverse.
For consistency, I avoid to set empty default for Reverse, while Reverse has values.

If no default values for Resolve and Reverse, I think enabled can be removed, but I am not sure it is the right way to go. Having enabled flag is handy to quickly turn on/off some features.

[edmocosta]

Yes I agree, but considering those are different operations, and that we don't actually know which one the user wants, I wouldn't enabled any lookup by default, and I would enforce them to be explicit set on the config.
Regarding the defaults, we could probably reach similar results by using the source_attributes and target_attribute default values at code level, making them optional config keys.

I personally find something like:

  dnslookup:
    reverse:

Easier to read/understand than:

  dnslookup:
    resolve:
      enabled: false
    reverse:
      enabled: true

Also, the following would still do resolve lookups, which IMO, is somehow hidden at config level (but not at the docs):

  dnslookup:
    reverse:
      enabled: true

Anyway, just my 2 cents :)

[edmocosta]

Do we want to create the resolvers/chain instances per signal type? If the same configuration applies to all signals, and they're stateless, we probably could create it once and re-use the same chain, avoiding for example reading all hostfiles 3 times, and also allowing it (in the future) to leverage/share the same cache.

[kaisecheng]

Very good point. It make sense to share the cache for signals per component.ID. I think we can implement it later to keep this PR slim enough for review. I will add a todo

[kaisecheng]

@edmocosta I have removed enabled from config and addressed all the comments. It is ready for a second look.

[edmocosta]

Hi @kaisecheng, could you please resolve the conflicts, so it can run the CI? thanks!