-
Notifications
You must be signed in to change notification settings - Fork 404
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OTLPExporter Pipeline issues #1810
Comments
The |
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.) |
|
See #1788 (comment) 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.
The text was updated successfully, but these errors were encountered: