Potentially common error when registering log record processors via AutoConfigurationCustomizer?

[trask]

I only just found that the way I've been registering log processors via AutoConfigurationCustomizer is seriously flawed, and worried other people may be doing the same:

AutoConfigurationCustomizer.addLoggerProviderCustomizer(
            (builder, otelConfig) -> builder.addLogRecordProcessor(...))

Since this will register the log record processor after the BatchLogRecordProcessor, any mutations made by the log record processor may not be exported, although 99.9% (~) of the time the mutations will be exported since they will be made prior to the batch being exported.

One (non-obvious) workaround is to leverage AutoConfigurationCustomizer.addLogRecordProcessorCustomizer().

[jack-berg]

Right now, span processors can only mutate spans #onStart. It would only be mutations #onEnd that a BatchSpanProcessor would not see. This is proposed in https://github.com/open-telemetry/opentelemetry-specification/pulls, but not possible today.

[trask]

oh right 🙈 for some reason I found the problem in logs and assumed I had the same problem in spans but actually don't

i've updated the title and description above to reference logs

[jack-berg]

Right right. Logs is definitely impacted by this.

One option I've thought about is adding a option for SdkTracerProviderBuilder and SdkLoggerProviderBuilder to insert a processor at the front of the processing pipeline, rather than appending to the end.