---
title: "MongoDB Query Tracing in .NET with Sentry + OTLP"
description: "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."
---

# MongoDB Query Tracing in .NET with Sentry + OTLP

[Sentry](https://yomu.fyi/company/sentry) · James Crosswell · Jul 20, 2026

**Type:** Tutorial

## 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.

## Context

The work addresses the need to measure MongoDB performance in .NET applications, identify slow commands and collections, distinguish one-off spikes from repeated query patterns, and correlate database traces with related Sentry errors and replays. It also addresses the risk that query payloads may contain sensitive data such as identifiers, emails, tokens, or other fields.

## Approach / What changed

Use MongoDB’s built-in OpenTelemetry instrumentation and the .NET OpenTelemetry SDK, then export spans to Sentry through Sentry.OpenTelemetry.Exporter and AddSentryOtlp(...). Initialize Sentry with UseOtlp() to prevent duplicate spans, subscribe to MongoTelemetry.ActivitySourceName, and optionally redact db.query.text with an Activity processor or configure Advanced Data Scrubbing rules.

## Takeaways

- UseOtlp() is needed when OpenTelemetry supplies trace data so Sentry’s built-in tracing hooks do not generate overlapping duplicate spans.
- 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.
- Sensitive MongoDB query data can be omitted, redacted client-side with a BaseProcessor, or targeted with server-side Advanced Data Scrubbing rules.

**Tags:** [Observability](https://yomu.fyi/topic/observability), [Performance](https://yomu.fyi/topic/performance), [Privacy](https://yomu.fyi/topic/privacy)

- Source: [Sentry](https://blog.sentry.io/mongodb-query-tracing-dotnet-sentry)
- Source URL: https://blog.sentry.io/mongodb-query-tracing-dotnet-sentry
- Ingested by Yomu: 2026-08-27T14:52:07.801Z

[Read original post](https://blog.sentry.io/mongodb-query-tracing-dotnet-sentry)