docs(go): Update OpenTelemetry docs for OTLP migration

docs/platforms/go/common/tracing/instrumentation/opentelemetry.mdx

@@ -4,7 +4,13 @@ description: "Using OpenTelemetry with Sentry Performance."
 sidebar_order: 20
 ---
 
-You can configure your [OpenTelemetry SDK](https://opentelemetry.io/) to send traces and spans to Sentry.
+You can configure your [OpenTelemetry SDK](https://opentelemetry.io/) to send traces to Sentry over OTLP.
+
+<Alert title="Span Processor Deprecation">
+
+The legacy `sentryotel.NewSentrySpanProcessor()` integration is deprecated in `sentry-go`. Prefer OTLP export instead: use `sentryotlp.NewTraceExporter()` to send traces directly to Sentry, or use a standard OpenTelemetry exporter if you're sending data through an OpenTelemetry Collector.
+
+</Alert>
 
 ## Install
 
@@ -16,7 +22,12 @@ You can configure your [OpenTelemetry SDK](https://opentelemetry.io/) to send tr
 
 ## OpenTelemetry and Sentry
 
-With Sentry’s OpenTelemetry SDK, an OpenTelemetry `Span` becomes a Sentry `Transaction` or `Span`. The first `Span` sent through the Sentry `SpanProcessor` is a `Transaction`, and any child `Span` gets attached to the first `Transaction` upon checking the parent `Span` context. This is true for the OpenTelemetry root `Span` and any top level `Span` in the system. For example, a request sent from frontend to backend will create an OpenTelemetry root `Span` with a corresponding Sentry `Transaction`. The backend request will create a new Sentry `Transaction` for the OpenTelemetry `Span`. The Sentry `Transaction` and `Span` are linked as a trace for navigation and error tracking purposes.
+With the OTLP-based setup, your OpenTelemetry spans are exported to Sentry using the standard OpenTelemetry trace pipeline instead of being converted locally by a Sentry span processor. Root spans show up in Sentry as transactions, child spans appear under those transactions, and the full trace remains connected across services.
+
+If you also want captured Sentry errors to be linked to the active OpenTelemetry trace, register `sentryotel.NewErrorLinkingIntegration()` in `sentry.Init` and capture errors with an `EventHint` that includes the active `context.Context`.
+
+
+If you're using an OpenTelemetry Collector, you don't need `sentryotlp.NewTraceExporter()`. Keep `sentryotel.NewErrorLinkingIntegration()` in your Sentry SDK setup, then configure the collector's `otlphttp` exporter to send traces to Sentry's OTLP endpoints. For the collector configuration, see the [OpenTelemetry Collector](/concepts/otlp/forwarding/pipelines/collector/) guide.
 
 ## Additional Configuration
 

platform-includes/performance/opentelemetry-install/go.mdx

@@ -10,9 +10,10 @@ The Sentry Go OpenTelemetry integration requires `go.opentelemetry.io/otel` (and
 
 </Alert>
 
-Install the `otel` module in addition to the main SDK:
+Install the `otel` and `otel/otlp` modules in addition to the main SDK:
 
 ```bash
 go get github.com/getsentry/sentry-go \
-       github.com/getsentry/sentry-go/otel
+       github.com/getsentry/sentry-go/otel \
+       github.com/getsentry/sentry-go/otel/otlp
 ```

platform-includes/performance/opentelemetry-setup/go.mdx

@@ -1,13 +1,15 @@
-You need to register the Sentry-provided SpanProcessor and Propagator as shown below:
+Create a trace exporter and register Sentry's error-linking integration:
 
 
 ```go
 import (
+	"context"
 	"go.opentelemetry.io/otel"
 	sdktrace "go.opentelemetry.io/otel/sdk/trace"
 
 	"github.com/getsentry/sentry-go"
 	sentryotel "github.com/getsentry/sentry-go/otel"
+	sentryotlp "github.com/getsentry/sentry-go/otel/otlp"
 	// ...
 )
 
@@ -16,22 +18,30 @@ sentry.Init(sentry.ClientOptions{
 	EnableTracing:    true,
 	TracesSampleRate: 1.0,
 	Debug:            true,
+	Integrations: func(integrations []sentry.Integration) []sentry.Integration {
+		return append(integrations, sentryotel.NewErrorLinkingIntegration())
+	},
 })
 
+ctx := context.Background()
+exporter, err := sentryotlp.NewTraceExporter(ctx, "___PUBLIC_DSN___")
+if err != nil {
+	panic(err)
+}
+
 tp := sdktrace.NewTracerProvider(
-	sdktrace.WithSpanProcessor(sentryotel.NewSentrySpanProcessor()),
+	sdktrace.WithBatcher(exporter),
 )
 otel.SetTracerProvider(tp)
-otel.SetTextMapPropagator(sentryotel.NewSentryPropagator())
 ```
 
-Now, all spans produced by OpenTelemetry will also be captured and sent to Sentry.
+Now, spans produced by OpenTelemetry will be exported to Sentry over OTLP.
+
+If you're exporting through an OpenTelemetry Collector instead of sending traces directly to Sentry, you only need to keep the same `sentry.Init(...)` integration setup for error linking in your Go app. Then configure the collector's `otlphttp` exporter to send traces to Sentry's OTLP endpoints. See the [OpenTelemetry Collector](/concepts/otlp/forwarding/pipelines/collector/) guide.
 
 ### Linking Errors to Transactions
 
-If you want the errors and messages the SDK produces (for example, via `CaptureException` or
-`CaptureMessage`) to be linked to transactions in the UI, a couple of extra steps are required. Most importantly, the current OpenTelemetry-enhanced context has to be passed as part
-of `EventHint` to `client.Capture*` methods:
+To link errors and messages captured by the Sentry SDK to the active trace in the UI, pass the current OpenTelemetry-enhanced context in the `EventHint`:
 
 ```go
 hub := sentry.CurrentHub()
@@ -45,5 +55,4 @@ client.CaptureException(
 )
 ```
 
-Events captured with the high-level `sentry.CaptureException` or `sentry.CaptureMessage` functions are
-NOT linked to transactions or spans at the moment. This will be improved in future releases.
+Events captured with the high-level `sentry.CaptureException` or `sentry.CaptureMessage` functions are not linked unless the active context is included in the event hint.