OpenTelemetry.Instrumentation.Http 1.7.0 no longer has peer.service attribute

[JamesNK]

Bug Report

We updated Aspire to use OpenTelemetry.Instrumentation.Http from 1.6.0-beta3 to 1.7.0 and HTTP requests no longer have the peer.service attribute.

Aspire UI bases some functionality around peer.service and that broken when it's no longer present.

Symptom

What is the expected behavior?

I expected to see a peer.service attribute. A HTTP request is accessing a remote service: https://github.com/open-telemetry/semantic-conventions/blob/482cb01c4598429c65dd0b123b30259f41b360cb/docs/general/attributes.md#general-remote-service-attributes

What is the actual behavior?

No peer.service attribute.

Reproduce

Make a HTTP request with 1.6.0-beta3 and see these attributes:

Update to 1.7.0 and see these attributes:

Note: no peer.service

We will close this issue if:

• The repro project you share with us is complex. We can't investigate custom projects, so don't point us to such, please.
• If we can not reproduce the behavior you're reporting.

Additional Context

Add any other context about the problem here.

[vishweshbankwar]

@JamesNK - This is not a bug in OpenTelemetry.Instrumentation.Http as it never emitted peer.service before.

Looks like this is due to how Otlp exporter handles certain tags and has some custom logic to add peer.service tag

https://github.com/open-telemetry/opentelemetry-dotnet/blob/ef942a11ac264d7b0f754a78dd3b4dd7d4d2c6f3/src/OpenTelemetry.Exporter.OpenTelemetryProtocol/Implementation/ActivityExtensions.cs#L146-L159

[CodeBlanch]

Just to add some clarity here, OtlpExporter has some code to try and resolve peer.service from some common known attributes: https://github.com/open-telemetry/opentelemetry-dotnet/blob/a31bca866dab2f9735713e9be9bcf80d95ca0104/src/Shared/PeerServiceResolver.cs#L36-L57

My guess would be the new instrumentation on stable conventions isn't using any of the known ones.

Not sure what to do about this though. The OtlpExporter probably shouldn't be doing this and peer.service isn't a stable thing or part of http conventions explicitly so it probably shouldn't do it either (without spec clarification).

/cc @alanwest

[JamesNK]

As someone who is writing a UI tool for OTEL data, having a shared generic value to indicate where the client is calling is useful.

For now, Aspire will continue looking for peer.service and fallback to other attributes: https://github.com/dotnet/aspire/blob/240e3ab1ce94b9c990d0fbb2799d71dfc295eca7/src/Aspire.Dashboard/Otlp/Model/OtlpHelpers.cs#L162-L191

[cijothomas]

The OtlpExporter probably shouldn't be doing this and peer.service isn't a stable thing or part of http conventions explicitly so it probably shouldn't do it either (without spec clarification).

Agree, especially the OTLPExporter part. (I cannot recollect why it was originally in OTLPExporter code.. Zipkin/Jaeger both needed it so it made sense.._)

[martinjt]

We do have the experimental flag in the libraries, so we could use that to add peer.service back in, but I don't think we can add it to the released packages.

It does seem weird to do that in the OTLP exporter, but I guess it's because we were expecting, potentially, other processors to update the attributes and that was done at the end maybe.

[martinjt]

I'm inclined to close this issue as it's not a bug, and it's something that we would implement whenever that attribute is stable in the conventions.