Just circling around to the linked issue :-) ... would the end result be better/worse for Akka.net depending on whether we push that one forward?

Took a look at this some today and it's not going to be as simple as I thought:

1. The way MSFT.EXT.Logging / OpenTelemetry appear to do this, is they have to be active at the callsite where the log is collected - there's not really a method to pass the ActivityContext into the ILogger.Log method (which is really the OpenTelemetryLogger after that's configured) after the fact.

Given the asynchronous way we process logs, this is problematic - we can capture the ActivityContext and attach it to the LogEvent record in Akka.NET and provide that as structured data to the logger, but that leads to a bridge to nowhere unfortunately.

2. The other approach we can use is simply to pass the entire Activity into the LogRecord and then do a quick hack inside something like the SerilogLogger or the LoggerFactoryLogger:

 protected virtual void Log(LogEvent log, ActorPath path)
{
	// this is going to be `null` 99.9999999999999999% of the time
	var previous = Activity.Current;
	try{
		Activity.Current = log.Activity; // grab the activity from the ILoggingAdapter output

		// the OTEL logger, if configured, will pick it up here
		_akkaLogger.Log<LogEvent>(GetLogLevel(log.LogLevel()), new EventId(), log, log.Cause, (@event, exception) => @event.ToString());
	}
	finally{
		Activity.Current = previous; // put the old value back on the stack
	}
}

I don't see any reason why that wouldn't work - maybe we can give that a shot.

And we can still, of course, append the TraceId and SpanId to our own messages if needed.