Replies: 2 comments 1 reply
-
|
/CC @brunobat |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
This is something that I think we can done for tracing. For logs, I'll need to take a deeper look. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Context
We need to wrap (not replace) resolved exporters to apply cross-cutting concerns (PII masking, compliance filtering) before export.
In vanilla OTel this is done via
AutoConfigurationCustomizerProvider:For metrics, this SPI works perfectly in Quarkus, the customizer receives the resolved
MetricExporterand wrapping works as expected.For spans and logs, it doesn't. Quarkus registers the entire
SpanProcessor/LogRecordProcessorinfrastructure internally without giving the SPI customizer a chance to touch the createdSpanExporter/LogRecordExporter. By the timeaddSpanExporterCustomizer/addLogRecordExporterCustomizercallbacks could run, the exporters are already wired into processors that Quarkus controls.Current Workaround
For spans and logs, we rebuild the entire OTLP exporter from scratch in a CDI producer, coupling to
VertxGrpcSender,VertxHttpSender,GrpcExporter,HttpExporter, and other internal APIs, just to wrap the result. This duplicates config handling and breaks on upgrades.Question
Is there a recommended/support way to wrap
SpanExporterandLogRecordExporterin Quarkus?addSpanExporterCustomizer/addLogRecordExporterCustomizerthe same way metrics already does?Environment: Quarkus 3.31.3 · OTel SDK 1.55+ · Java 21
Beta Was this translation helpful? Give feedback.
All reactions