Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Trace Context not propagated unless source for Microsoft.Orleans.* has been added #9188

Open
mkstephenson opened this issue Oct 16, 2024 · 6 comments

Comments

@mkstephenson
Copy link

mkstephenson commented Oct 16, 2024

I have been playing around with OpenTelemetry tracing and Orleans and found that unless you instruct the OpenTelemetry SDK to listen to the trace source "Microsoft.Orleans.*" (well, I have a * there, I'm sure you can have a more precise name there), the parent activity is not propagated to child activities across Orleans calls and remains null. This means that you can't choose to "just" instrument your own code, you must also add the Orleans source if you wish to have connected spans in Open Telemetry.

I am not sure if this is by design or not, but if it was, I wasn't able to find anything in the documentation related to this caveat. Would it be possible to add a note to the documentation if this is intended behaviour?

I am using 8.2.0 of the Microsoft.Orleans.Server package for reference and starting the application/tracing through an Aspire project.

@ReubenBond
Copy link
Member

Hi @mkstephenson, I don't quite understand - how should this behave?

@mkstephenson
Copy link
Author

Ah sorry, I forgot to mention the important bit that the parent is not propagated, even if AddActivityPropagation() has been called on the silo.

I think the behaviour is correct, but because Orleans handles all grain calls without the caller knowing its internals, it is not obvious that the parent Activity is not forwarded unless the Microsoft.Orleans namespace has been added to the OpenTelemetry tracing sources. Therefore I was wondering if we could expand the documentation to highlight this. It should hopefully save some other developers a bit of headscratching when they puzzle why the parent is null, even though they activated ActivityPropagation.

@scalalang2
Copy link
Contributor

scalalang2 commented Oct 21, 2024

I think the official docs already well described how to enable it.
https://learn.microsoft.com/en-us/dotnet/orleans/host/monitoring/?pivots=orleans-7-0

builder.Services.AddOpenTelemetry()
    .WithTracing(tracing =>
    {
        // Set a service name
        tracing.SetResourceBuilder(
            ResourceBuilder.CreateDefault()
                .AddService(serviceName: "GPSTracker", serviceVersion: "1.0"));

        tracing.AddSource("Microsoft.Orleans.Runtime");
        tracing.AddSource("Microsoft.Orleans.Application");

        tracing.AddZipkinExporter(zipkin =>
        {
            zipkin.Endpoint = new Uri("http://localhost:9411/api/v2/spans");
        });
    });

@mkstephenson
Copy link
Author

While it does contain the important namespace to trace in the example, it does not mention the importance of the namespaces and why those two should be included to ensure that all other tracing works. Because the Microsoft.Orleans namespace has been used as a demonstration namespace in the other examples on the page, reading it makes you think that the namespaces in the example were not chosen for a particular reason, rather than, if you exclude these, no distributed tracing will work at all.

@rkargMsft
Copy link
Contributor

If you could point out the examples for tracing using just Microsoft.Orleans (no * or Runtime/Appication), then those can get corrected.

@mkstephenson
Copy link
Author

Ah, I see now that there are no other examples for tracing (there's just that one small code snippet), just the meters (which are all under the Microsoft.Orleans namespace).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants