net.peer.name in HTTP client semconv is both Required and also mentions "SHOULD NOT be set if"

[trask]

Currently net.peer.name is marked as Required, but in its description it also says

SHOULD NOT be set if capturing it would require an extra DNS lookup

which seems contradictory.

Question: When an HTTP request is explicitly sent to an IP address, e.g. http://x.x.x.x:8080, should we be capturing net.peer.name of x.x.x.x? or not capturing any net.peer.name?

cc @lmolkova @Oberon00

[lmolkova]

opentelemetry-specification/specification/trace/semantic_conventions/span-general.md

Lines 141 to 149 in ec84e5d

	#### `net.peer.name`
	For IP-based communication, the name should be a DNS host name of the remote service.
	`net.peer.name` should be the name of logical remote destination, e.g., `"example.com"` if connecting to an URL `https://example.com/foo`. Usually, application pass it as configuration to client libraries in form of URL, connection string, host name, etc.
	Sometimes host name is only available to instrumentation as a string which may contain DNS name or IP address. `net.peer.name` SHOULD be set to the available known hostname (e.g., `"127.0.0.1"` if connecting to an URL `https://127.0.0.1/foo`).
	If only IP address is available via `net.sock.peer.addr`, `net.peer.name` SHOULD NOT be set. Reverse DNS lookup SHOULD NOT be used to obtain DNS name.

I.e. if you know the url which happened to be http://x.x.x.x - then x.x.x.x becomes peer name.
If you know only x.x.x.x and know it's an IP address, net.peer.name should not be set.

It sounds complex, but I don't see a contradiction. [Edit] I do see a contradiction now (with the required attribute).

I'm open to reducing complexity and using IP if name is not available (i.e. SHOULD be set to IP address if capturing name would require an extra DNS lookup).
We can't guarantee low cardinality in edge cases anyway.

[Oberon00]

If you know only x.x.x.x and know it's an IP address, net.peer.name should not be set.

IMHO in the HTTP conventions net.peer.name should be set to the IP in this case (if the x.x.x.x is what the user passed in the API, or as part of the URL), since that's also the name that was used to connect and thus in this context "the name of logical remote destination". It also avoids special cases in the backend.

This is even what you edited into the original PR description @lmolkova #2469 (comment):

Client: the only set of attributes clients should support is: http.url, net.peer.name, net.peer.port

• require http.url, net.peer.name (use IP if only IP is avaialble), net.peer.port (when not default)

Perhaps this should be clarified explicitly.

Personally, I would even say that net.peer.name and net.peer.port should not be required and perhaps not even listed explicitly (less than opt-in), since http.url is already required and the other things are redundant information, but probably that was discussed as well on #2469.

[trask]

IMHO in the HTTP conventions net.peer.name should be set to the IP in this case (if the x.x.x.x is what the user passed in the API, or as part of the URL), since that's also the name that was used to connect and thus in this context "the name of logical remote destination". It also avoids special cases in the backend.

fwiw I think this is what the Java instrumentation does today (cc @laurit to correct me if that's not the case)

Personally, I would even say that net.peer.name and net.peer.port should not be required and perhaps not even listed explicitly (less than opt-in), since http.url is already required and the other things are redundant information, but probably that was discussed as well on #2469.

These are important for metrics, which I think makes them important for span-to-metrics pipelines.

Also, having metric attributes always be a subset of span attributes makes unifying those signals behind a single "instrumentation api" simpler.

[mateuszrzeszutek]

fwiw I think this is what the Java instrumentation does today (cc @laurit to correct me if that's not the case)

Not Lauri but I'm pretty sure we're always using the logical address for net.peer.name - and if the URL contains an IP address, then it's an IP address.