MongoDB Query Tracing in .NET with Sentry + OTLP

Summary

Measuring MongoDB performance in a .NET application requires command details, durations, and enough context to distinguish isolated spikes from recurring query patterns. The post presents an end-to-end setup that uses MongoDB’s built-in OpenTelemetry Activity instrumentation, the .NET OpenTelemetry SDK, Sentry.OpenTelemetry.Exporter, and OTLP ingestion rather than a dedicated Sentry.MongoDB integration. Configuration initializes Sentry with UseOtlp(), subscribes to MongoTelemetry.ActivitySourceName, adds MongoDB instrumentation, and exports spans with AddSentryOtlp(...), while avoiding duplicate spans from overlapping hooks. Query context appears in Sentry traces, span samples, and the Queries experience, with Relay generating parameterized values for aggregation but retaining raw db.query.text per span. The post also demonstrates client-side redaction and describes server-side scrubbing, while exporter propagation bridges preserve correlation with errors and replays.

Takeaways

1. 1

   UseOtlp() is needed when OpenTelemetry supplies trace data so Sentry’s built-in tracing hooks do not generate overlapping duplicate spans.

2. 2

   Relay creates a parameterized query copy for grouping and display in Queries, but the original db.query.text remains stored and viewable in individual span or exemplar details.

3. 3

   Sensitive MongoDB query data can be omitted, redacted client-side with a BaseProcessor, or targeted with server-side Advanced Data Scrubbing rules.