Open cijothomas opened 3 months ago
The new_pipeline
pattern is more widespread in our exporters as it is also used in Zipkin and DataDog (from contrib) exporters. I agree that stdout
is more relatable as it is how most of the other languages have implemented exporters, but it also seems that the pipeline approach (probably) is more Rust idiomatic with builder pattern and config chaining to create the complete setup without any intermediate steps.
the pipeline approach (probably) is more Rust idiomatic with builder pattern
I am not sure which part makes it more Rust idiomatic... Sure, it is popular with other OTel Rust Exporters (those exporters, most likely, followed the approach from OTLP Exporters.)
I am not sure which part makes it more Rust idiomatic
with_pipeline
uses the single chain to configure the pipeline, more consistent with how other crates in Rust work, as compared to creating exporters, processors, logger-provider, and then logger. Especially in scenarios where these intermediate components are only needed to be passed to the next stage in the pipeline and are not utilized directly by the application. I am not saying this is the right way, it's just a more Rust's idiomatic approach.
See https://github.com/open-telemetry/opentelemetry-rust/pull/1788#issuecomment-2126204854 as well, which talks about potentially re-using the "transport" aspects across signals.
@lalitb will explore this more, and share concerns/comments.
OTLP Exporters are configured via the helper methods offered by OTLP crate, using the idea of "pipeline", (eg:
opentelemetry_otlp::new_pipeline().logging()...
). This hides a lot of LoggerProvider details from the user, and has somewhat reasonable consistency across signals. - opentelemetry_otlp::new_pipeline().logging() vs opentelemetry_otlp::new_pipeline().tracing() vs opentelemetry_otlp::new_pipeline().metrics(), but I see some issues/challenges with that approach.stdout
show a different way of configuring the LoggerProvider, viaLoggerProvider::builder().with_simple_exporter(exporter).build()
. This does not hideLoggerProvider
concepts from user. Most users get started with OpenTelemetry using stdout exporters, but then switching to otlp is a big shift in the way things are configured.LoggerProvider
, so user lose the ability to customize theLoggerProvider
themselves. For eg: if user want to add aRedactionProcessor
, it is not possible.install_simple/batch
is odd naming (of course, this is subjective!).The below is the way using LoggerProviderBuilder, shown in all examples except OTLP!
The below uses OTLP::pipeline/helps, and shown in almost all OTLP examples.
Opening to get some feedback on these issues. I'd prefer to remove all OTLPPipeline* constructs, and make OTLP consistent with stdout exporter.
Something like:
The above is easily composable, consistent for all exporters. Exporters need not know anything about provider configurations or runtime or anything - it just does it job - exporting and accepting configuration on how to export, like which protocol or endpoint to use etc.