OpenTracing support

[skyflyer]

Do you have any plans / ideas to support OpenTracing concepts? I'm thinking along the lines that a given "call chain" could have an "execution context", which could hold arbitrary data.

It makes a lot of sense for RPC-oriented services, where there is a request and a response, which is not necessarily the case with grains as their lifetime is quite different.

I'm thinking along the lines of passing additional "context" data to each call, but not via interface method parameters, but rather via "client enrichment". Something along the lines of:

var ctx = Context().WithValue("requestid", Request.HttpContext.TraceIdentifier)
var something = _orleansClient.EnrichWith(ctx).GetGrain<ISomething>(Guid.Empty);
await something.DoIt();

Additional data could be passed encoded (don't know anything about how clients in orleans actually communicate with the server) into a communication channel. The server-side (or silo-side) implementation would be able to pick it up:

var ctx = GetRequestContext();
// do something with it

---

OK, so I just stumbled upon Request context so I see that this is already addressed, I just could not find it. :)

[skyflyer]

@benjaminpetit,

I see that the RequestContext already carries an ActivityId which is supposed to be used for something like activity correlation. Is this ActivityId preserved (transferred) when using streams? I glanced over the code in the repo and I would assume it isn't?

For instance, let's say I set the RequestContext.ActivityId on the client, then call into a grain in the silo, which then enqueues the message into a stream. How could I propagate this information to the grain processing the message from the stream (in my case, implicit subscription)?

[ReubenBond]

Related #4992

[ReubenBond]

RequestContext is propagated in streams

[skyflyer]

Great @ReubenBond! I'm closing this in favour of #4992, as that one is pretty much inline with my expectations.
/close