The guid matches the service.instance.id for the container

Playing around here, I've managed to find the offending code, so this only happens when I specify a service name and/or version like this:

.WithTracing((builder) =>
{
    builder.SetResourceBuilder(ResourceBuilder.CreateDefault().AddService(ApplicationTelemetry.ServiceName))
         // ...
}

We want the service name and version for our prod OTEL data, so I can workaround this for now by making this a conditional thing. However I think this is still a bug, providing a service name shouldn't make the trace viewing experience worse, right?

Are you seeing this on your local machine when running the Aspire app host project?

Could you upload a simple repo to GitHub? I can take a look and see what is wrong.

This was really hard to replicate, but I finally got it 😅 It only happens when the Aspire resource name matches the service name, then the Aspire dashboard starts displaying things in terms of replica sets incorrectly:

In the case for this screenshot, if I rename either the service name or resource name from "myapp" to "myapp2", everything works as expected. I'll push something up to GH shortly.

Here's the example, again change the resource name or service name from "myapp" to anything else and it works, otherwise things become a bit broken:
https://github.com/slang25/aspire-issue/

I can work around this for now, but my assumption would be that these names clashing would be supported, and a common occurrence.

I'm also see this issue crop up when I see peoples demos and blogs, take a look at the screenshots here as an example:
https://nikiforovall.github.io/dotnet/opentelemtry/2024/06/07/test-instrumentation-with-otel-aspire.html

+1

I have a basic Java app used with otel java agent that populates both service.name and service.instance.id by default.
Instance id is random guid generated at start time.

Span names appear with instance id prefix (which is not really helpful).

Happy to share repro too if it's helpful.

I believe the reason it's not affecting .NET apps that much is because OTel .NET set service.instance.id to service name by default, so things look good.