Activity parent id for diagnostics

[ebbeflarup]

Question:

Setting the parent id of the current activity when receiving message through the Azure Servicebus is inconsistent in the current Microsoft.Azure.ServiceBus and this new Azure.Messaging.ServiceBus package, is this by design?

To be more precise, this particular code from the Microsoft.Azure.ServiceBus MessageDiagnosticsExtensions.cs sets the new activity parent id, when processing messages, to metadata received in the 'Diagnostic-Id' field.

While this particular code from the Azure.Messaging.ServiceBus DiagnosticExtensions.cs sets the data received in the metadata in the 'Diagnostic-Id' field as a linked activity for the current activity.

Is this by design? Is it correctly understood that this causes different behaviour and also breaks the trace correlation chain since no parent is set here?

And additionally, this particular piece of code from the Azure.Core.Pipeline DiagnosticScope.cs adds a private class 'DiagnosticActivity' which adds the property 'Links' to the Activity class. This is then used in the Azure.Messageing.ServiceBus package here. This causes problems when using this package with the OpenTelemetry(or any other package) packages since the OpenTelemetry packages uses the newest version(Version=5.0.0.0) of the "System.Diagnostics.DiagnosticSource" which also add a 'Links' property to the Activity type :)

[jsquire]

Thank you for your feedback. Tagging and routing to the team members best able to assist.

[pakrym]

This is the guidance we got for integration with OpenTelemetry and ApplicationInsights.

Is it correctly understood that this causes different behaviour and also breaks the trace correlation chain since no parent is set here?

It is understood that behavior is different. I don't see it breaking correlation though. The parent of the processing span is whoever started it and links are used to correlate messages.

And additionally, this particular piece of code from the Azure.Core.Pipeline DiagnosticScope.cs adds a private class 'DiagnosticActivity' which adds the property 'Links' to the Activity class. This is then used in the Azure.Messageing.ServiceBus package here. This causes problems when using this package with the OpenTelemetry(or any other package) packages since the OpenTelemetry packages uses the newest version(Version=5.0.0.0) of the "System.Diagnostics.DiagnosticSource" which also add a 'Links' property to the Activity type :)

Do you see problems with it at runtime?

[ebbeflarup]

It is understood that behavior is different. I don't see it breaking correlation though. The parent of the processing span is whoever started it and links are used to correlate messages.

Maybe I'm asking for something not supported, It's a bit difficult to figure out.
I'm asking because I want to take the diagnostics and export them directly from the application to any OpenTelemetry supported platform, not necessarily ApplicationInsights.

I just noticed your post here. Does this mean that you are planning on making everything OpenTelemetry compatiable? And additionally making it possible to subscribe to these diagnostics and handle them however the application developer wants inside the application? Is it even neccessary to do anything explicit to export the diagnostics using the OpenTelemetry dotnet exporters like the already existing instrumentation packages for AspNetCore, the HTTP client or SQL? (I know none of these are related to the Azure SDK and that you guys probably have your own agenda separate from these 3 areas)

I feel like I have completely misunderstood something really basic here, sorry if that's the case :/

And additionally, this particular piece of code from the Azure.Core.Pipeline DiagnosticScope.cs adds a private class 'DiagnosticActivity' which adds the property 'Links' to the Activity class. This is then used in the Azure.Messageing.ServiceBus package here. This causes problems when using this package with the OpenTelemetry(or any other package) packages since the OpenTelemetry packages uses the newest version(Version=5.0.0.0) of the "System.Diagnostics.DiagnosticSource" which also add a 'Links' property to the Activity type :)

Do you see problems with it at runtime?

Never mind this. I guess that since the DiagnosticActivity class is declared private it was never the intention to expose these links anyways :)

[pakrym]

I just noticed your post here. Does this mean that you are planning on making everything OpenTelemetry compatible

Yes, that's the plan. We are going to use ActivitySource and produce Activities that are natively compatible with the OpenTelemetry and don't require any additional collectors. That would include the new Links property.

[ghost]

Hi @ebbeflarup. Thank you, for your interest in helping to improve the Azure SDK experience and for your contribution. We've noticed that there hasn't been recent engagement on this pull request. If this is still an active work stream, please let us know by pushing some changes or leaving a comment. Otherwise, we'll close this out in 7 days.

[ghost]

Hi @ebbeflarup. There was a mistake and this issue was unintentionally flagged as a stale pull request. The label has been removed and the issue will remain active; no action is needed on your part. Apologies for the inconvenience.

[ramya-rao-a]

@pakrym Any updates here? If this is a valid feature request or a bug, can you please add the appropriate label and milestone?

[pakrym]

We've since added the ActivitySource/OpenTelemetry support: https://devblogs.microsoft.com/azure-sdk/introducing-experimental-opentelemetry-support-in-the-azure-sdk-for-net/#get-started