You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, adding events (via AddEvent) and errors (via RecordError) using Open Telemetry is a NOOP using the SentrySpanProcessor. To properly add them, it's necessary to resort to sentry's specific abstractions (such as CaptureMessage and CaptureException) passing an EventHint with a context containing a span, making the underlying code dependent on both OTel and sentry's API.
This becomes more evident when handling panics, since the default spanRecorder automatically recovers from panics, adds them as an event and re-panics. Making the use of sentry's Recover not only redundant but misleading, as the reported stacktrace will start at the repanic location, inside the spanRecorder, not the place where the panic itself happened. See #582.
Motivation
To improve the current integration, my feature request is to enhance the current SentrySpanProcessor to iterate over the OTel Span events and send them to sentry.
Current challenges
For errors, Open Telemetry's default spanRecorder records all errors' metadata (name, kind, stacktrace strings), but keeps no record of the error itself. For reporting Stacktraces, it would be necessary to parse the stacktrace string into a []sentry.Exception, which can be challenging. There are libraries that already do the parsing, but I will keep this open for discussion.
Summary
Currently, adding events (via
AddEvent
) and errors (viaRecordError
) using Open Telemetry is a NOOP using theSentrySpanProcessor
. To properly add them, it's necessary to resort to sentry's specific abstractions (such asCaptureMessage
andCaptureException
) passing anEventHint
with a context containing a span, making the underlying code dependent on both OTel and sentry's API.This becomes more evident when handling panics, since the default
spanRecorder
automatically recovers from panics, adds them as an event and re-panics. Making the use of sentry's Recover not only redundant but misleading, as the reported stacktrace will start at the repanic location, inside thespanRecorder
, not the place where the panic itself happened. See #582.Motivation
To improve the current integration, my feature request is to enhance the current
SentrySpanProcessor
to iterate over the OTel Span events and send them to sentry.Current challenges
spanRecorder
records all errors' metadata (name, kind, stacktrace strings), but keeps no record of the error itself. For reporting Stacktraces, it would be necessary to parse the stacktrace string into a[]sentry.Exception
, which can be challenging. There are libraries that already do the parsing, but I will keep this open for discussion.Additional Context
Possible implementation:
The text was updated successfully, but these errors were encountered: