From 03743f3c2066171571bb86e23cb68f69eaac5398 Mon Sep 17 00:00:00 2001 From: Abhijeet Prasad Date: Tue, 14 Feb 2023 11:53:18 +0100 Subject: [PATCH] feat(otel): Add otel context to errors --- src/docs/sdk/performance/opentelemetry.mdx | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/src/docs/sdk/performance/opentelemetry.mdx b/src/docs/sdk/performance/opentelemetry.mdx index 5e910a7891..75dd28a5e2 100644 --- a/src/docs/sdk/performance/opentelemetry.mdx +++ b/src/docs/sdk/performance/opentelemetry.mdx @@ -384,6 +384,10 @@ function generateSentryErrorsFromOtelSpan(otelSpan) { Sentry.captureException(syntheticError, { contexts: { + otel: { + attributes: otelSpan.attributes, + resource: otelSpan.resource.attributes, + }, trace: { trace_id: otelSpan.spanContext().traceId, span_id: otelSpan.spanContext().spanId, @@ -722,7 +726,7 @@ OpenTelemetry, has the concept of [Span Events](https://github.com/open-telemetr In Sentry, we have two options for how to treat span events. First, we can add them as breadcrumbs to the transaction the span belongs to. Second, we can create an artificial "point-in-time" span (a span with 0 duration), and add it to the span tree. TODO on what approach we take here. -In the special case that the span event is an exception span, [where the `name` of the span event is `exception`](https://opentelemetry.io/docs/reference/specification/trace/semantic_conventions/exceptions/), we also have the possibility of generating a Sentry error from an exception. In this case, we can create this [exception based on the attributes of an event](https://opentelemetry.io/docs/reference/specification/trace/semantic_conventions/exceptions/#attributes), which include the error message and stacktrace. This exception can also inherit all other attributes of the span event + span as tags on the event. +In the special case that the span event is an exception span, [where the `name` of the span event is `exception`](https://opentelemetry.io/docs/reference/specification/trace/semantic_conventions/exceptions/), we also have the possibility of generating a Sentry error from an exception. In this case, we can create this [exception based on the attributes of an event](https://opentelemetry.io/docs/reference/specification/trace/semantic_conventions/exceptions/#attributes), which include the error message and stacktrace. This exception can also inherit all other attributes of the span event + span as tags on the event. This is addressed by Step 7, where you add `generateSentryErrorsFromOtelSpan` to the `SpanProcessor` pipeline. In the OpenTelemetry Sentry exporter, we've used this [strategy to generate Sentry errors](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/8eda2f80b6dbd5aea03ca699c3ad1454714156d0/exporter/sentryexporter/sentry_exporter.go#L169-L196). @@ -759,8 +763,6 @@ interface OpenTelemetryContext { } ``` -The reason sdk and service are split are so they can be indexed as top level fields in the future for easier usage within Sentry. - ## SDK Spec - SpanProcessor: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/sdk.md#span-processor