MongoDB Operation Telemetry

Implementation evidence

MongoDB Operation Telemetry: from boundary to verified row

Use MongoDB Operation Telemetry at a controlled application boundary, keep the event contract small, and verify a known outcome before building aggregate views.

1
Choose the outcome
Slow-operation analysis
2
Define the contract
database_system, operation, collection_name, query_fingerprint, and release
3
Instrument the boundary
Name the application operation separately from the database command so dashboards remain stable as query implementations change.
4
Verify the evidence
Exercise a known fixture, then inspect mongodb_operation_completed for one correctly typed terminal row.

Before you start

Prerequisites and boundaries

The MongoDB Node.js driver and telemetry-sh initialized server-side
A bounded operation taxonomy that does not include collection documents or filter values
A reviewed distinction between application timing and database-profiler diagnostics

Delivery setup

Install and initialize server-side

Import telemetry-sh in server-only code and initialize it once with process.env.TELEMETRY_API_KEY. Keep ingestion credentials out of browser bundles, client-visible environment variables, source control, logs, and exception messages.

mongodb-install

npm installation

bash

npm install telemetry-sh

1Prepare one reusable server-side delivery client with bounded network behavior.
2Add the outcome event at the success, failure, retry, or timeout boundary.
3Send controlled fixtures and inspect the stored rows before enabling an alert.

Snippet

Start with one structured event

Add this shape where the workflow completes, fails, or retries. Then build the dashboard from real fields.

mongodb

MongoDB Operation Telemetry event

javascript

await telemetry.log("mongodb_operation_completed", {
  database_system: "mongodb",
  operation: "workspace_activity.aggregate",
  collection_name: "workspace_activity",
  query_fingerprint: "workspace_activity_summary_v3",
  status: "success",
  duration_ms: Math.round(performance.now() - startedAt),
  result_count: results.length,
  retry_count: 0,
  transaction_status: "not_started",
  read_preference: "primaryPreferred",
  route_template: "/api/workspaces/:workspaceId/activity",
  release: process.env.APP_RELEASE,
});

Event contract

database_system, operation, collection_name, query_fingerprint, and release

status, duration_ms, result_count, retry_count, and transaction_status

read_preference, write_concern_category, route_template, and error_type

Implementation checkpoints

Checkpoint 1

Name the application operation separately from the database command so dashboards remain stable as query implementations change.

Checkpoint 2

Keep filters, update documents, aggregation pipelines, returned documents, connection strings, and unrestricted driver errors out of events.

Checkpoint 3

Use the MongoDB database profiler selectively for native query diagnostics; its captured data can include sensitive query details and needs its own access and retention review.

Verification

Prove the event arrived

Run this after exercising known success and failure cases. Replace the fallback table name if your final event contract differs from the snippet.

mongodb-verification

MongoDB Operation Telemetry verification query

sql

SELECT *
FROM mongodb_operation_completed
ORDER BY timestamp_utc DESC
LIMIT 20;

Confirm one terminal row per logical outcome, with the expected status, identifiers, units, and UTC time.

Inspect the inferred schema and verify that retries do not change field types or generate a new logical event ID.

Search the stored fields for credentials, raw payloads, prompts, private content, and unbounded error messages.

Exercise a provider timeout, ingestion rejection, and process shutdown before treating the dashboard as complete.

Implementation references

Review the event contract, data-safety guidance, and upstream primary documentation before enabling a new production path.

Database reliability monitoring Database-query impact SQL Redacting sensitive data MongoDB database profiler MongoDB query performance guide

Production boundary

Keep the outcome event small and recoverable

This pattern provides

A bounded, SQL-ready outcome beside the upstream workflow.
Stable fields for dashboards, alerts, and cross-event correlation.
A fixture-driven path for validating success, failure, retry, and timeout behavior.

This pattern does not provide

An OTLP exporter, automatic collection pipeline, or replacement for detailed traces and diagnostic logs.
Exactly-once delivery merely because the payload contains an event ID.
Permission to collect raw provider payloads, user content, credentials, or regulated data.

Delivery and idempotency Batching and shutdown Troubleshoot ingestion

Event schema starting points

Review the row grain, emit boundary, required types, privacy classes, example payload, and validation checklist before adapting a query or snippet to production.

Database reliability9 fields

database_operation_completed

One completed application-owned database operation.

Inspect contract

Continue this workflow in SQL query API

Run read-only DataFusion SQL over structured-event tables and reuse the result.

Explore SQL query API Review customer evidence

Related SQL recipes

Answer the next question with SQL

Run the query against the structured fields from this workflow, inspect the example result, and turn a useful answer into a dashboard or alert.

Browse all recipes

Database reliabilityBeginner

Find Slow Database Queries by Fingerprint

Which database operations are consistently slow enough to investigate?

Open recipe

Database reliabilityBeginner

Rank Database Queries by Total Time Impact

Which database operation consumes the most cumulative request time?

Open recipe

Database reliabilityIntermediate

Calculate Database Transaction Rollback Rate

Which services roll back an unusual share of database transactions?

Open recipe

Database reliabilityIntermediate

Measure Long-Running Database Transactions

Which application transaction classes remain open the longest?

Open recipe

Complete collectionsDatabase reliability SQL

Browse by implementation family

Compare related integration patterns

Database and Data-System Telemetry Integrations

Templates to pair with this integration

Database Reliability Monitoring Template

Instrument slow operation fingerprints, pool contention, transaction rollbacks, locks, replication lag, and migration outcomes with safe structured events.

Open template

More integrations

MongoDB Operation Telemetry