[Instrumentation.ServiceFabricRemoting] initial implementation

[sablancoleis]

Today, Microsoft Service Fabric doesn't support trace context propagation natively. This library fills that gap and allows the trace context and Baggage to be transferred transparently between Services and Actors.

Note: This code targets only Service Fabric Remoting V2, since V1 would require using wrapped messages and it will be deprecated in the near future.

This implementation propagates the ActivityContext and Baggage through SF Remoting using the OpenTelemetry's Propagator infrastructure to inject the data into the message headers from the client and to extract the data from the headers on the receiving listener.

The code also provides extension methods to configure the whole infrastructure with one line of code in Program.cs:
tracerProviderBuilder.AddServiceFabricRemotingInstrumentation()

Merge requirement checklist

• CONTRIBUTING guidelines followed (license requirements, nullable enabled, static analysis, etc.)
• Unit tests added/updated
• Appropriate CHANGELOG.md files updated for non-trivial changes
• Changes in public API reviewed (if applicable)

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: sablancoleis / name: Santiago Blanco (53592da, db8eaf6, d263da9, 0625186, 9011f72, 517afdd, e9a12bb, 70ca2e5, a27127b, 458ac07, 89c66ef, 7e31c85, 9a82d60, 4ed7a9b, 7c57530)
• ✅ login: Kielek / name: Piotr Kiełkowicz (ebadc1b)

[rajkumar-rangaraj]

@sablanc-msft Could you please sign the Easy CLA, it's a requirement to review/accept PRs.

[rajkumar-rangaraj]

@sablanc-msft You need to update the https://github.com/open-telemetry/opentelemetry-dotnet-contrib/blob/main/.github/component_owners.yml file with owners. It is recommended to have a minimum of 2 owners. Once the component owner review is complete, approvers/maintainers will review.

Also, it would be nice if you provide a clear PR description of what you are trying to solve by adding this project to the repo.

[Kielek]

One more comment, do you see any possibility to include native-instrumentation directly in ServiceFabric? Whole Azure SDK is following this pattern, and it is the best option we can recommend.

[sablancoleis]

One more comment, do you see any possibility to include native-instrumentation directly in ServiceFabric? Whole Azure SDK is following this pattern, and it is the best option we can recommend.

That would be ideal. Hopefully the Service Fabric team can include native instrumentation in future releases. This library is meant to fill the gap of context propagation in the meantime.

[lmolkova]

@sablancoleis have you tried reaching out to the ServiceFabric team and proposing to add instrumentation there?

It seems they were considering adding instrumentation at some point and might be open to someone contributing it - microsoft/service-fabric-services-and-actors-dotnet#294

[sablancoleis]

@sablancoleis have you tried reaching out to the ServiceFabric team and proposing to add instrumentation there?

It seems they were considering adding instrumentation at some point and might be open to someone contributing it - microsoft/service-fabric-services-and-actors-dotnet#294

@lmolkova , Yes, I contacted them a month and a half ago and multiple times during the past few weeks, but I haven't been able to get a response yet. I will add you to the email thread.

I hope the SF Team integrates context propagation in a future release, but it will take months and even after that, it will take months for that release to be upgraded in the applications trying to use OpenTelemetry.
This library allows my Team, other teams in Microsoft and external customers using Service Fabric to integrate OpenTelemetry without having to upgrade the Service Fabric SDK, so I think it still adds value while we wait for the native integration.
My team is already using this code in production, but I would like to get it reviewed by the OpenTelemetry community and the Service Fabric team.

[sablancoleis]

One more comment, do you see any possibility to include native-instrumentation directly in ServiceFabric? Whole Azure SDK is following this pattern, and it is the best option we can recommend.

@Kielek, I got confirmation from the Service Fabric Team that they don't have plans to integrate OpenTelemetry in the near future.

[Kielek]

Just some technical comments.
I do not know anything about ServiceFabric. In this context it will be great to find someone to review.

That is sad, the ServiceFabric does not want to implement such stuff. Maybe you can consider contributing there? I am not against including this instrumentation library here, but it will be great to find the agreement also internally within MS teams.

[Kielek]

Is there any chance to have second volunteer to help with the maintenance?

[Kielek]

I do not see examples so this can be removed)

Suggested change

	instrumentation-servicefabricremoting: ['*/OpenTelemetry.Instrumentation.ServiceFabricRemoting*/**', 'examples/servicefabricremoting-instrumentation/**', '!**/*.md']
	instrumentation-servicefabricremoting: ['*/OpenTelemetry.Instrumentation.ServiceFabricRemoting*/**', '!**/*.md']

[Kielek]

OpenTelemetry.Api is transitive dependency. You can simplify here:

Suggested change

	<PackageReference Include="OpenTelemetry.Api" Version="$(OpenTelemetryCoreLatestVersion)" />
	<PackageReference Include="OpenTelemetry.Api.ProviderBuilderExtensions" Version="$(OpenTelemetryCoreLatestVersion)" />
	<PackageReference Include="OpenTelemetry.Api.ProviderBuilderExtensions" Version="$(OpenTelemetryCoreLatestVersion)" />

[Kielek]

Please update

[Kielek]

It is not true. I am not sure if you need an example. Or you can have cool enough README here.