Top MongoDB Metrics to Monitor in Runtime Environments
November 24, 2025
Tags:
Observability
OpenTelemetry
MongoDB Monitoring
.png)
In fast-moving production environments, teams running MongoDB often encounter unpredictable performance shifts as workloads grow or query patterns evolve. Applications may see rising latency due to inefficient query shapes, sudden cache pressure, or replicas falling behind during peak periods.
Even when MongoDB appears “healthy,” underlying signals may already be pointing to memory churn, locking contention, or storage saturation. Monitoring these early indicators helps teams to stay ahead of performance drift instead of reacting after user impact.
MongoDB manages query routing, index selection, replication, journaling, cache management and disk I/O. Any degradation in these internal components immediately affects upstream application services.
As a result, regular and meaningful monitoring becomes essential to ensure MongoDB behaves consistently under real-world traffic.
From an operational standpoint, MongoDB metrics help answer questions like:
MongoDB performance is shaped by few practical factors that shape how well it responds to real-world demand:
By keeping visibility into these areas, teams can spot early warning signs like rising page faults or inefficient query patterns before they cascade into broader user-facing issues.
To extend this visibility, here are the key methods for collecting MongoDB metrics using OpenTelemetry.
Methods of MongoDB Monitoring with OpenTelemetry
OpenTelemetry provides a vendor-neutral way to instrument MongoDB workloads, collect performance signals without depending on fragmented exporters or driver-specific tooling.
Depending on your environment, you can choose from two instrumentation paths:
1. Client-side instrumentation (application telemetry)
Captures MongoDB operation timings and requests directly from OTel-enabled MongoDB drivers helping correlate API requests with database operations and surface slow or inefficient query patterns.
2. Server-side instrumentation (engine telemetry)
Gather internal MongoDB metrics such as replication lag, WiredTiger cache usage, index efficiency, and operation counters through the OpenTelemetry MongoDB receiver that the application cannot observe.
This binary perspective reveals whether latency originates in the application path or the database engine itself, enabling faster root-cause analysis and more accurate performance tuning.
To explore more, refer to the in-depth MongoDB Monitoring guide.
To summarize, MongoDB metrics provide the early signals needed to maintain stability and predictable performance under load. With this, we can now break down the core metric categories that are critical in monitoring.
MongoDB metrics can be organized into telemetry categories that expose workload intensity, cache efficiency, replication health, and query behavior enabling teams to assess system stability and emerging bottlenecks before they impact application performance.
MongoDB performance metrics illustrate how efficiently the engine executes queries, writes, and cursor operations. Helping to uncover rising latency, inefficient filters, or imbalanced workloads before they affect user-facing paths. These signals show whether execution time is increasing due to query complexity, CPU pressure, or planner regressions.
During a seasonal traffic spike, an order-processing service begins issuing more complex read operations, causing performance metrics such as operation latency to climb steadily.
As inefficient filters degrade query execution, the server starts accumulating stalled cursors, leading to rising cursor timeout counts. The engineering team notices that unpredictable response times correlate directly with these degraded operation and query execution signals.
Core metrics to track:
mongodb_operation_time_milliseconds_total - High sustained latency signals increasing workload pressure or inefficient queries.
mongodb_operation_count_total - Sudden spikes/drops help detect traffic shifts or abnormal workloads.
mongodb_cursor_timeout_count - Cursor timeouts point to slow-running queries or resource contention.
Connection and session metrics indicate how clients interact with MongoDB and whether incoming workloads are within stable operating limits. These metrics surface connection storms, poor pooling behavior, and long-lived sessions that may exhaust resources.
Suppose after deploying a new authentication service, the platform accidentally bypasses the connection pool, causing MongoDB’s connection and session metrics to spike. Hundreds of short-lived sessions open per second, overloading the node and increasing network request activity beyond normal workload patterns.
As connections and sessions pile up, thread scheduling slows down and other APIs experience cascading latency due to uncontrolled connection growth.
Core metrics to track:
mongodb_connection_count - Near-limit values indicate connection storms or unoptimized pooling.
mongodb_session_count - Rapid session growth suggests inefficient client reuse or long-running operations.
mongodb_network_request_count - Helps correlate traffic surges with connection or workload changes.
These metrics show how effectively MongoDB uses memory and WiredTiger cache to keep hot data resident and minimize disk I/O. Tracking them helps detect shrinking headroom, reduced cache locality, and oversized working sets that impact query predictability.
As user activity climbs in an analytics dashboard, the active dataset expands and begins exceeding available cache space. Memory and cache metrics reveal shrinking cache hit ratios and rising memory pressure, indicating the working set no longer fits in RAM.
With WiredTiger forced into frequent evictions, previously fast queries begin hitting disk, degrading overall resource utilization and slowing interactive dashboards.
Core metrics to track:
mongodb_memory_usage_bytes - Rising memory usage indicates shrinking headroom and risk of swapping.
mongodb_cache_operations_total - Low hit ratios reveal poor cache locality or oversized working sets.
mongodb_data_size_bytes - Tracks working set growth; sudden changes may signal schema changes or data skew.
These metrics highlight the health and timeliness of replication, along with lock behavior that affects concurrent reads and writes. Monitoring them ensures data freshness, stable read-scaling, and predictable failover behavior under varying workloads.
A large background aggregation running on a secondary starts consuming CPU and cache, leading to increasing replication and concurrency metrics such as replication lag and global lock time.
As internal threads compete, lock contention rises and replication is unable to keep pace with the oplog stream. The result is stale data in services using read-preference modes and elevated failover risk due to delayed replication and blocking effects.
Core metrics to track:
mongodb_replication_lag_seconds - Core indicator of secondary health and read-consistency SLAs.
mongodb_global_lock_time_milliseconds_total - Long lock durations reveal heavy write or contention workloads.
mongodb_index_access_count - Drops suggest query or workload changes that bypass indexes.
These metrics surface how data and index footprints evolve and how storage throughput affects query and write responsiveness. They help diagnose disk saturation, index bloat, and capacity risks that can slow MongoDB at the engine level.
Following a new feature rollout, additional indexes are created for search functionality, causing storage and disk I/O metrics to rise significantly. Index files quickly outgrow memory, forcing more disk seeks and reducing cache locality.
As write rates continue climbing, MongoDB experiences noticeable I/O stalls, and background compaction increases storage and disk usage, affecting performance during peak hours.
Core metrics to track:
mongodb_index_size_bytes - Large or fast-growing indexes reduce cache efficiency.
mongodb_storage_size_bytes_total - Helps forecast disk exhaustion and compaction needs.
mongodb_object_count - Sudden document growth may reflect workload anomalies or data ingestion issues.
Diagnostic metrics reveal underlying engine issues, faulty query patterns, and operational anomalies. Tracking them helps identify problems such as in-memory sorts, query inefficiencies, or engine-level assertions requiring immediate attention
A change in query patterns results in multiple search filters executing without appropriate indexes, driving error and diagnostic metrics such as scanAndOrder and slow-query counts higher.
MongoDB starts issuing internal assertions about inefficient query shapes as the workload triggers more in-memory sorts. This diagnostic data highlights the root cause of increased application latency and guides teams toward necessary query-plan optimizations.
Core metrics to track:
mongodb_asserts_total - Critical for detecting internal engine warnings or structural issues.
mongodb_scan_and_order_count - Indicates queries that bypass indexes and rely on in-memory sorting.
mongodb_slow_query_count - Highlights inefficient query shapes affecting user-facing latency
Next, we transition to the MongoDB telemetry indicators that provide high-fidelity insight into runtime performance, workload patterns, and system health.
MongoDB emits a wide spectrum of operational and engine-level metrics, but only few reflect whether query execution, cluster health, and resource usage are behaving within safe limits.
These ten metrics capture the pulse of the system under real production traffic surfacing signals that directly map to cache saturation and data-growth pressure.
With this foundation in place, the next step is to translate these signals into meaningful visualizations that reveal operational inefficiencies with clarity.
Once collected, MongoDB metrics can be visualized through various monitoring dashboards depending on the operational observability stack, allowing teams to inspect performance signals and workload behavior in runtime environments.
Here’s an example of MongoDB metric mongodb_global_lock_time_milliseconds_total visualized through Prometheus :
Similarly, an example of MongoDB traces displayed in Jaeger, revealing request flows, latency distributions, and span-level timing across services.
Across different telemetry backends, MongoDB visualizations surface essential signals such as lock behavior, query latency, concurrency patterns, and request traces. These insights help teams identify contention, correlate workload shifts, and maintain predictable performance in distributed environments.
For a complete list of MongoDB metrics and more details, refer the documentation.
MongoDB’s internal health is defined by how well it manages cursor execution, cache residency, lock contention, replication progress, and storage allocation under load.
By focusing on early indicators of stress by exposing shifts in execution latency, workload distribution, memory turnover, lock pressure, and data growth that directly shape the database’s real-time responsiveness.
In the end goal it’s not just monitoring it’s sustaining predictable performance, fast responsiveness, and reliable applications at scale.
For a more comprehensive breakdown of instrumenting and operationalizing the signals using OpenTelemetry, you can explore our detailed guide here: MongoDB Monitoring
.png)
.avif){kind=logo}
