[Bug]: Improve context in BatchSpanProcessor/BatchLogProcessor error logs when otlp export fails

[krisztianfekete]

What happened?

Currently, when otlp export fails due to transport errors, e.g. misconfigured endpoint, the error level logs are not helpful finding the root cause of the problem.

Current Behavior

With a misconfigured endpoint (missing schema, e.g., localhost:4317 instead of http://localhost:4317):

Error-level log:

2026-01-29T12:12:15.755056Z error opentelemetry_sdk
  name="BatchSpanProcessor.ExportError"
  error="Operation failed: status: 'Unknown error', self: \"transport error\""

Debug-level log:

2026-01-29T12:33:01.335273Z debug tonic::transport::channel::service::reconnect
  reconnect::poll_ready: ConnectError(ConnectError("invalid URL, scheme is missing"))

Looks like we lose the context when the original error gets wrapped into OTelSdkError::InternalFailure and the processors log it as a generic error without the original context.

I propose preserving the original error in InternalFailure in error messages. What do you all think?

OpenTelemetry API Version (i.e version of opentelemetry crate)

main

OpenTelemetry SDK Version (i.e version of opentelemetry_sdk crate)

main

What Exporter(s) are you seeing the problem on?

OTLP

Relevant log output

See above.

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[cijothomas]

See related PR #3343

We can include additional context in the component closest to where the error is occurring - the OTLP Exporter. The above PR is in that direction, please see if that is going to help your scenario. If not, we can improve that with additional context helpful to debugging. Let us know.

[krisztianfekete]

Hey @cijothomas, thanks for taking a look!
The PR above doesn't really help with my problem where one have to enable DEBUG level logging to see that the problem is a user-side misconfiguration that is easily fixable. I am proposing surfacing the ConnectError from the above example at an elevated log level. In this case, further sanitization isn't even required as that message doesn't even contain the actual connection string.

[cijothomas]

@krisztianfekete Could you leave a comment on the PR itself, with this specific suggestion? Thanks in advance for helping us improve internal logging.

[krisztianfekete]

Thanks @cijothomas, left a comment here: #3343 (review)