search

iand675 / hs-opentelemetry

OpenTelemetry support for the Haskell programming language
https://iankduncan.com/projects/opentelemetry
BSD 3-Clause "New" or "Revised" License
81 stars 35 forks source link

Extensibility for Propagators and Samplers #59

Open pbrisbin opened 1 year ago

pbrisbin commented 1 year ago

:wave: Hi there!

We're just getting started with OpenTelemetry and are looking to emit OTel traces from our app and then us the AWS collector to export to X-Ray. This means we need an AWS X-Ray Propagator, IdGenerator, and Sampler. I've written some of this code and it's working (I think), but it's been awkward (IMO) to get the SDK to use it.

I had to basically re-implement initializeGlobalTracerProvider just so that I could inject a record update to add my propagator after all the environment-variable-based configuration has happened. But then I look at the docs for said environment variables, and it seems like I should be able to "register" these things somehow, and then just say (e.g.) OTEL_PROPAGATORS=tracecontext,baggage,awsxray at runtime to turn them on. That would be really useful as we start migrating from X-Ray to Datadog -- to be able to choose via ENV at runtime like that.

So I guess my question is, am I missing a way in this library to do that?

wolverian commented 1 year ago

As far as I can see https://github.com/iand675/hs-opentelemetry/blob/54251bd15565e3a07cda0cecfa544d209ae63df6/sdk/src/OpenTelemetry/Trace.hs#L298-L299

and

https://github.com/iand675/hs-opentelemetry/blob/54251bd15565e3a07cda0cecfa544d209ae63df6/sdk/src/OpenTelemetry/Trace.hs#L360-L371

mean that only those propagators already known to the SDK are automatically used based on environment variables. Unfortunately, awsxray is not one of them:

https://github.com/iand675/hs-opentelemetry/blob/54251bd15565e3a07cda0cecfa544d209ae63df6/sdk/src/OpenTelemetry/Trace.hs#L287-L294

This TODO seems apropos and I'm sure @iand675 would be glad for a PR that implements this:

https://github.com/iand675/hs-opentelemetry/blob/54251bd15565e3a07cda0cecfa544d209ae63df6/sdk/src/OpenTelemetry/Trace.hs#L297

michaelpj commented 4 months ago

We're also wondering about this. There's also the issue that tracerProviderPropagators is specialised to HTTP headers, which isn't necessarily appropriate in all cases. For example, we have a Propagator for AMQP messages. At the moment we're just manually invoking it around the use sites of the library, but presumably the idea is that somehow we will eventually be able to register propagators that process different message types?