Reading through the source code, it looks like I do not need to call setOpenTelemetryContextAsyncContextStrategy since that is done by Sentry.init() (source)

And it looks like I need to make sure I setup OpenTelemetry first because init() calls validateOpenTelemetrySetup (source) that will print a bunch of warnings if it's not setup yet.

I definitely have to use setupEventContextTrace because it is not called (source) when I use skipOpenTelemetrySetup: true,

And it looks like I need to make sure I setup OpenTelemetry first because init() calls validateOpenTelemetrySetup (source) that will print a bunch of warnings if it's not setup yet.

to setup my tracerProvider with the SentrySampler I need the Sentry client before instantiating my TracerProvider. I don't get warnings with it setup this way because DEBUG_BUILD isn't set.

Here's the setup I landed on. If you see anything weird or wrong here would love to know.

import { MetricExporter } from "@google-cloud/opentelemetry-cloud-monitoring-exporter";
import { TraceExporter } from "@google-cloud/opentelemetry-cloud-trace-exporter";
import opentelemetry, * as api from "@opentelemetry/api";
import { AsyncLocalStorageContextManager } from "@opentelemetry/context-async-hooks";
import { registerInstrumentations } from "@opentelemetry/instrumentation";
import { HttpInstrumentation } from "@opentelemetry/instrumentation-http";
import { IORedisInstrumentation } from "@opentelemetry/instrumentation-ioredis";
import { UndiciInstrumentation } from "@opentelemetry/instrumentation-undici";
import { WinstonInstrumentation } from "@opentelemetry/instrumentation-winston";
import { Resource } from "@opentelemetry/resources";
import { MeterProvider, PeriodicExportingMetricReader, ConsoleMetricExporter } from "@opentelemetry/sdk-metrics";
import { BatchSpanProcessor, SimpleSpanProcessor, ConsoleSpanExporter } from "@opentelemetry/sdk-trace-base";
import { NodeTracerProvider } from "@opentelemetry/sdk-trace-node";
import { SEMRESATTRS_SERVICE_NAME, SEMRESATTRS_SERVICE_NAMESPACE } from "@opentelemetry/semantic-conventions";
import type { NodeClient } from "@sentry/node";
import {
 SentrySpanProcessor,
 SentryPropagator,
 wrapContextManagerClass,
 setupEventContextTrace,
 SentrySampler,
} from "@sentry/opentelemetry";
import { TypeormInstrumentation } from "opentelemetry-instrumentation-typeorm";
import { ExpressInstrumentation } from "@opentelemetry/instrumentation-express";
import { OTLPTraceExporter } from "@opentelemetry/exporter-trace-otlp-http";
import * as Sentry from "@sentry/node";
import { nodeProfilingIntegration } from "@sentry/profiling-node";
import { environment, release, SentryDSN } from "@smartrr/shared/services/Sentry/constants";
import { IS_DEPLOYED, PRODUCTION, RUNTIME_ENV_NAME } from "./utils/constants";
Sentry.init({
 dsn: SentryDSN.backend,
 environment,
 release,
 integrations: [nodeProfilingIntegration()],
 skipOpenTelemetrySetup: true,
});
const sentryClient = Sentry.getClient<NodeClient>();
const resource = new Resource({
 [SEMRESATTRS_SERVICE_NAME]: "smartrr",
 [SEMRESATTRS_SERVICE_NAMESPACE]: RUNTIME_ENV_NAME,
});
const metricReaders = [];
if (IS_DEPLOYED) {
 metricReaders.push(
 new PeriodicExportingMetricReader({
 // Export metrics every 10 seconds.
 // 5 seconds is the smallest sample period allowed by Cloud Monitoring.
 exportIntervalMillis: 10_000,
 exporter: new MetricExporter(),
 })
 );
}
if (process.env.OTEL_DEBUG || process.env.OTEL_DEBUG_JAEGER) {
 metricReaders.push(
 new PeriodicExportingMetricReader({
 exporter: new ConsoleMetricExporter(),
 })
 );
}
const meterProvider = new MeterProvider({ resource, readers: metricReaders });
const tracerProvider = new NodeTracerProvider({
 resource,
 spanLimits: { eventCountLimit: 512 },
 sampler: sentryClient && new SentrySampler(sentryClient),
});
const SentryContextManager = wrapContextManagerClass(AsyncLocalStorageContextManager);
tracerProvider.register({
 propagator: new SentryPropagator(),
 contextManager: new SentryContextManager(),
});
opentelemetry.metrics.setGlobalMeterProvider(meterProvider);
if (sentryClient) {
 setupEventContextTrace(sentryClient);
 sentryClient.traceProvider = tracerProvider;
}
registerInstrumentations({
 tracerProvider,
 meterProvider,
 instrumentations: [
 new HttpInstrumentation(),
 new UndiciInstrumentation(),
 new ExpressInstrumentation(),
 new IORedisInstrumentation(),
 new TypeormInstrumentation(),
 new WinstonInstrumentation({
 logHook(_, record) {
 record["resource.service.name"] = tracerProvider.resource.attributes[SEMRESATTRS_SERVICE_NAME];
 },
 }),
 ],
});
tracerProvider.addSpanProcessor(new SentrySpanProcessor());
if (IS_DEPLOYED) {
 tracerProvider.addSpanProcessor(
 new BatchSpanProcessor(new TraceExporter(), {
 scheduledDelayMillis: 1000,
 maxExportBatchSize: 512,
 maxQueueSize: 512 * 6,
 })
 );
}
if (process.env.OTEL_DEBUG) {
 tracerProvider.addSpanProcessor(new SimpleSpanProcessor(new ConsoleSpanExporter()));
}
if (process.env.OTEL_DEBUG_JAEGER) {
 tracerProvider.addSpanProcessor(new BatchSpanProcessor(new OTLPTraceExporter()));
}
if (RUNTIME_ENV_NAME !== PRODUCTION) {
 opentelemetry.diag.setLogger(new api.DiagConsoleLogger(), api.DiagLogLevel.ERROR);
}
export const OtelTracer = tracerProvider.getTracer("basic");
export const OtelMeter = meterProvider.getMeter(RUNTIME_ENV_NAME);

Hey, sorry about the confusion there - you are right that there are some incorrect/missing things in the docs there! I will make sure to update them and ensure everything is actually exported etc. correctly!

I opened a PR with some small fixes based on your feedback: #12214

• the docs PR for this: feat(node): Update docs for manual OTEL setup sentry-docs#10145

Thank you so much, we greatly appreciate the feedback and time to go through this! Hopefully with the changes in the PR this will become more straightforward 🙏

Hey, we have released 8.5.0 with some updates where stuff should properly work now!
The updated docs can be found here: https://docs.sentry.io/platforms/javascript/guides/node/performance/instrumentation/opentelemetry/#using-a-custom-opentelemetry-setup

Hello. We discovered today that with the above configuration, none of our tracing is making it to our Google Cloud Tracing. I also found that it's not making it to my local Jaeger instance when I have OTEL_DEBUG_JAEGER=1 set. While debugging I found that if I remove the SentrySampler my traces make it to my non-sentry tracing destinations, but of course then the sentry stuff stops working.

I ended up just removing Sentry from our backend entirely.

Do you have any suggestions on how we can support non-sentry trace destinations while still having Sentry work properly?

My takeaways from this experience:

1. It feels like Sentry has "taken over" my tracing. This does not feel good.
2. Having all of my backend tracing sampling be determined by Sentry sampling configuration is confusing and not necessarily what I want.
3. Having frontend tracing sampling determine backend tracing sampling is not what I want and I can't figure out how to turn this off.

We have Sentry installed for error tracking. I don't want it to even be involved with our tracing setup at all. I feel I have been sucked into trying to get the two to play nice together and failed. Ultimately I had to remove Sentry from my backend to get our tracing recovered to its previous state, but this is not what I want - I want to keep using Sentry for backend error tracking.

Disappointed.

FYI, we have shipped improved docs on how to use Sentry with a custom OTEL setup: https://docs.sentry.io/platforms/javascript/guides/node/opentelemetry/custom-setup/

Hopefully, these docs clarify some of the challenges that folks had so far.

@mydea

• i've submitted an issue that was closed in favor of discussing it here.
• i'd also like to point out a related issue

In my opinion i do not agree that this is the appropriate but discussion, but this was the direction given to me.

The problem:
Sentry scopes are not Isolated to each request. Specifically, when using Sentry.setUser or Sentry.setTag, the expectation is that if an exception is reported for that request, the event should include the correct User and tags that were set for the request. However, often times when a web server processes multiple requests at a time, the reported issue has incorrect User and Tag information.

For example:

• assume a web server is processing multiple requests
• each request was performed by a unique user
• Sentry.setUser and Sentry.setTag are called by the web server once it has identified the unique, authenticated user
• later on as the web server is processing a request, we need to capture/report an event to Sentry.
• The reported event is often captured with the user and tags which were set by a different a request.

Reproduction
This repository demonstrates the issue.

• setUser and setTag are called per request
• the authUser passed throughout the webservers middleware and set in the extra to illustrate what the expected user and tags should be for the event
• We've set up OTEL using all of the documented Sentry tools: SentrySampler, SentryPropagator, SentryContextManager
  • We've even tried multiple variations:
    • Only use SentryContextManager as mentioned [here](related issue
    • Using a custom sampler: See the commented out sampler here.

-- EDIT--

I apologize for the edit, but i forgot to mention some important context about how we use Sentry:

• We only use Sentry for reporting errors and events.
• We do no not need Sentry to link events between our UI and API.
• We have "an existing OTEL setup", AKA we do use OTEL, but have no plans at the time export our OTEL info to Sentry.
• Sentry's Sampler breaks our existing OTEL sampler, so we have to use a Custom Sampler. IMO - this seems like an unnecessary ask from Sentry, but we are willing to do it of course. Ideally, we'd be able to just init Sentry and everything would just work seeing as we manage our own OTEL separately.