blakeroberts-wk
commented
3 months ago Nice. I think you've stated this very well in that these additional propagators should exist in another repo such as a opentelemetry-dart-contrib or similar. And to do that, NonRecordingSpan should be exposed.
I would be happy to review a PR to expose NonRecordingSpan!
Is your feature request related to a problem? Please describe.
My company runs Dart gRPC servers in production, and I am thinking of using this SDK to implement distributed tracing. There is an Envoy proxy running in front of the gRPC servers, and all the HTTP requests are sent through the Envoy proxy.
In this scenario, Envoy needs to generate a tracing id, but the OpenTelemetry tracing extension is still marked as work-in-progress and it does not support OpenTelemetry's default W3C context propagator. Instead, Envoy supports Zipkin's B3 and Datadog as described in this document.
Envoy is widely accepted in the cloud-native community, and some SDKs for other languages seem to implement the B3 propagator. I think it would be nice to implement a propagator other than W3C as well in Dart SDK.
Describe the solution you'd like
Actually, I have already implemented both the propagators in my forked repository and confirmed that they worked properly in our development environment.
There are 2 options for where to place non-default propagator implementations.
If you think the second option is better, we should export NonRecordingSpan in order to implement these propagators outside of the upstream repository. Basically, I'd be happy to contribute this to upstream(this repository), but I'd like to know which approach I should take since it might increase your maintenance burden.
Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.
Additional context Add any other context or screenshots about the feature request here.