Ops Manager can emit deployment metrics collected by MongoDB Agent in OpenTelemetry (OTel) format to a third-party observability backend while Ops Manager continues to receive these metrics. This feature enables you to integrate your MongoDB deployments into an existing observability stack or any other platform that accepts the OpenTelemetry Protocol (OTLP). You do not need custom pipelines, sidecar processes, or additional collection agents.
OTel export is additive and is disabled by default. Metrics delivery to Ops Manager is not altered in any way: every signal continues to be carried on the existing Ops Manager path unchanged. Any failure on the OTel export path, such as an unreachable endpoint, is isolated so that reporting to Ops Manager is never interrupted.
When you enable this feature, MongoDB Agent pushes metrics over OTLP/HTTP to your configured endpoint on a configurable cadence (the default is 30 seconds). Each cycle sends one OTLP request per monitored process, plus one request for the agent's own self-health, so your backend receives several small requests per interval rather than one large batch. Your endpoint can be one of the following:
An OpenTelemetry Collector, which can process metrics and route them onward to multiple destinations.
An observability platform that accepts OTLP natively (for example, Datadog, Grafana, Dynatrace).
You configure this feature through the Automation Configuration. MongoDB Agent collects the exported metrics on its existing collection cycle, so this feature places no extra load on your monitored MongoDB processes.
How OTel Export Differs from the Prometheus Integration
The OTel export path is not a drop-in replacement for the existing Prometheus integration. Whereas the Prometheus integration is pull-based, and MongoDB Agent exposes a /metrics endpoint that your Prometheus server scrapes. The OTel path is push-based, and MongoDB Agent sends metrics to your configured OTLP endpoint on a timer.
OTel metrics also use different names, types, and units that follow OpenTelemetry semantic conventions for MongoDB, so you cannot reuse your existing Prometheus dashboards. You must create new dashboards, alerts, and queries in your target observability platform against the exported metrics.
Prerequisites
Before you configure OTel export, ensure that you meet the following requirements:
You must enable monitoring for your deployment before you can configure OTel export. OTel export reuses the samples that MongoDB Agent already collects for monitoring. To learn how to install MongoDB Agent and enable monitoring, see Install the MongoDB Agent to Monitor or Back Up Deployments.
Ensure your OTLP endpoint is reachable from every host where MongoDB Agent runs. MongoDB Agent pushes metrics directly to the endpoint. Verify your firewall rules and egress policies before you enable this feature.
Confirm you have
Project Automation Adminaccess to update the Automation Configuration through the Ops Manager API. To learn more about project roles, see Ops Manager Roles. To learn about the Automation Configuration API, see Automation Configuration Resource.Ensure your OTLP endpoint supports OTLP/HTTP as a receiver protocol. To learn about configuring an OTLP/HTTP receiver, see the OpenTelemetry Protocol specification.
Enable OTel Export
You configure OTel export through the Automation Configuration. All settings are carried in a single otelConfig key under the monitoring module's additionalParams. You can apply this configuration through the existing custom configuration flow in the Ops Manager interface, described in Custom Settings. You can also apply this configuration through the public Automation Configuration API.
The following example shows an additionalParams entry that enables OTel export:
1 "additionalParams": { 2 "otelConfig": "{\"enabled\":true,\"metricsExportIntervalSec\":30,\"backends\":[{\"endpoint\":\"https://collector.example.com:4318\",\"headers\":\"Authorization=Bearer <token>\",\"caCertPath\":\"/etc/ssl/ca.pem\"}]}" 3 }
For the full list of otelConfig fields, see OpenTelemetry (OTel) Export Settings.
Important
A misconfigured otelConfig fails loudly rather than being silently ignored. If the configuration is invalid, MongoDB Agent prevents the monitoring module from starting. MongoDB Agent retries the configuration every 30 seconds until it receives a valid configuration. An invalid otelConfig therefore affects monitoring as a whole, not only the OTel path. The agent logs this failure with an Otel: prefix and surfaces it in the agent's status reporting to Ops Manager.
Configuration changes take effect the next time the monitoring module restarts. Ops Manager triggers this restart automatically when you change the relevant Automation Configuration properties.
Warning
If you configure an http:// endpoint, MongoDB Agent sends metrics over an unencrypted connection. Ops Manager cannot detect whether an endpoint is a production destination, so no guardrail prevents insecure export in production. Use an https:// endpoint for production deployments.
Kubernetes Deployments
For deployments managed by MongoDB Controllers for Kubernetes (MCK), OTel export uses the same Automation Configuration mechanism. The operator maintains the Automation Configuration. The operator writes your OTel settings to the agent hosts through custom resource updates. You do not need any separate Kubernetes-specific configuration.
Exported Metrics
This feature exports the metric groups in the following table over OTLP. Metric names, types, and units follow OpenTelemetry semantic conventions for MongoDB, using a consistent mongodb.* naming pattern.
Metric Group | Source | Coverage |
|---|---|---|
Server status |
| Operation counters (including replicated), operation latencies, connections, memory, network, cursors, documents inserted, updated, deleted, and returned, WiredTiger cache statistics, tickets and queue depth, lock acquire, wait, and deadlock counts, active reads and writes, asserts, flow control, query targeting, time-to-live (TTL) deletes, page faults, uptime, and health. |
Database statistics |
| Per-database storage, data size, object, index, and view statistics. |
Collection activity |
| Per-operation aggregated time. |
Replication |
| Oplog size and window, replication lag, and member health. |
Sharding | Config metadata | Chunk counts and data distribution across shards. |
Agent self-health | Agent runtime | MongoDB Agent uptime, memory, and goroutines, published under the dedicated |
This feature exports counter metrics as cumulative values with a start timestamp derived from mongod uptime. A mongod restart is surfaced as a standard counter reset, so rate calculations remain correct across restarts.
Staleness and Series Lifetime
MongoDB Agent re-exports counter series unchanged while a process is temporarily unreachable, so a collection gap is not misread as a counter reset.
MongoDB Agent exports point-in-time series, such as
mongodb.health, only while they are fresh, so an unreachable process goes silent instead of holding a stale value.MongoDB Agent drops a series after 20 minutes without a new sample, and the series disappears from your backend. Account for this behavior when you build alerts based on missing data.
Set Up Dashboards in Your Observability Platform
You must create new dashboards in your target observability platform against the exported metrics. Ops Manager does not ship pre-built dashboards, and you can't reuse existing dashboards created for the Prometheus integration, the Ops Manager interface, or another third-party MongoDB integration.
Consider this guidance when you set up dashboards:
Create new dashboards instead of porting existing ones. Metric names emitted over OTLP follow a
mongodb.*naming convention that differs from the Prometheus exporter's names and from Ops Manager internal metric identifiers.Use resource attributes for filtering and grouping. Every metric carries resource attributes that identify the monitored process and the project. Use these attributes as the primary dimensions for dashboard panels, alerts, and grouping.
Apply rate functions to counter metrics. Counters are cumulative. Apply functions such as
rate()orincrease(), or their equivalents in your platform, to counter-type metrics.Recreate your alerts. OTel export does not carry over existing alert rules defined in Prometheus, Ops Manager, or another third-party integration. Define new alert rules in your target platform against the OTel metric names and resource attributes.
Limitations
One backend per deployment. This feature supports exactly one OTLP backend. Configuring more than one backend results in a hard error. To fan metrics out to many destinations, configure an OpenTelemetry Collector as your export target, and route to more backends through its pipeline configuration.
Metrics only. This feature exports only metrics over OTLP. The OTel export path does not include the following signals, which continue to flow to Ops Manager unchanged:
Logs (profiler entries, host logs, and agent logs) and traces
MongoDB Search process metrics
Host-level system metrics (CPU, memory, disk, and network)
Per-collection latency histograms
No buffering for unreachable destinations. MongoDB Agent retries or drops a failed export according to the exporter's policy. This feature provides no store-and-forward queue. Delivery to Ops Manager is unaffected in all cases.