BatchSpanProcessor: Exporter error handling does not provide useful information

[hibachrach]

If an Exporter returns a FAILURE status, the BatchSpanProcessor calls OpenTelemetry.handle_error with a new exception. But that exception doesn't tell you anything about what happened: all we get back is "Unable to export 90 spans" or some such because it just instantiated the error based on a return value--there's no raising or deeper stack trace (afaict).

Thanks again for all of your work on OTel!

[ericmustin]

@hibachrach sorry for the delay here. There's a bit of tech debt here for sure, at the time we'd hit this issue originally at $job-2, otel metrics were unstable, and we were a statsd shop, so we exposed a not very well documented MetricsReporter that you can define (otherwise it just no-ops iirc) and which provides some extra debugging info about the processors and exporters, which you can then theoretically provide your own metrics client to export to your backend of choice, or logger, etc.

https://github.com/open-telemetry/opentelemetry-ruby/blob/23c5aaf445244b6b634ccdf8d557a56feda98831/sdk/lib/opentelemetry/sdk/trace/export/metrics_reporter.rb#L18-L29

And you can see its use within the BSP here https://github.com/open-telemetry/opentelemetry-ruby/blob/1279826ed84549088652331725790c19862f759c/sdk/lib/opentelemetry/sdk/trace/export/batch_span_processor.rb#L66

Anyway, I realize that's very far from a first class feature, this is probably something we'd be open to revisiting or reworking given capacity or contributions from the community :)

[github-actions[bot]]

👋 This issue has been marked as stale because it has been open with no activity. You can: comment on the issue or remove the stale label to hold stale off for a while, add the keep label to hold stale off permanently, or do nothing. If you do nothing this issue will be closed eventually by the stale bot.