feat(otel): capture span events #795
Conversation
|
We could instead capture breadcrumbs, 1 Sentry event per OTEL event could be too much, let's discuss this. |
| sentry_span.set_data("otel.kind", convert_span_kind(data.span_kind)); | ||
| for attribute in data.attributes { | ||
| sentry_span.set_data(attribute.key.as_str(), convert_value(attribute.value)); | ||
| } | ||
| // TODO: read OTEL semantic convention span attributes and map them to the appropriate | ||
| // Sentry span attributes/context values | ||
|
|
||
| for event in data.events { | ||
| sentry_core::capture_event(convert_event(&event)); |
There was a problem hiding this comment.
its a bit weird that you only get these on_end, and not when they happen.
if we decide to attach them as breadcrumbs, they should have proper ordering in relation to other breadcrumbs.
There was a problem hiding this comment.
This is true, on the other hand you know exactly which span they are in and you have the timestamp, so it shouldn't be much of a problem.
| let mut contexts = BTreeMap::<String, Context>::new(); | ||
| contexts.insert("otel".to_owned(), otel_context.into()); | ||
| Event { | ||
| level: sentry_core::Level::Error, |
There was a problem hiding this comment.
doesn’t an otel event have a level?
for tracing we have this code that does different things depending on the event level.
There was a problem hiding this comment.
Unfortunately in Rust they just carry a message, timestamp and attributes.
It seems that there is some misalignment in OTEL itself when it comes to this.
In e.g. Java they carry exceptions, so it makes sense to create errors out of them. @sl0thentr0py I don't think I mentioned this before when discussing this.
Adds capturing span events as Sentry events.
This is the behavior we have in other SDKs.
In the future we can consider ways to e.g. set tags on the event from special span attributes like we do in the
tracingintegration.We don't capture a stack trace as we have no way to get it reliably. The event itself does not carry it, it's just a struct with name, timestamp and attributes.
Should it be opt-in?