Persisting index usage metrics across restarts (PMM/monitoring)
Parent: MongoDB Explain Plans, Query Planner and Plan Cache · Published reference · snapshot 2026-10-30
↓ Facts as markdownall context files
Source-anchored research for Persisting index usage metrics across restarts (PMM/monitoring). Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
How it works
- MongoDB $indexStats accesses.ops resets when mongod restarts. Index drop/recreation and index modification through collMod also reset the affected index statistics; accesses.since identifies when gathering began. (high confidence) [source]
- PMM can retain previously collected index usage samples across a MongoDB instance restart even though MongoDB resets its live statistics. Retention must cover the complete application workload cycle, including infrequent reporting jobs, to support unused-index assessment. (high confidence) [source]
- The indexstats collector must be enabled to obtain index-usage metrics. A Percona support answer identifies mongodb_indexstats_accesses_ops as the metric to inspect when troubleshooting missing index-usage data. (medium confidence) [source]
- A March 2026 support report for PMM 3.6.0 describes duplicate mongodb_indexstats_accesses_ops series when indexstats runs through mongos across multiple shards. The reporter confirmed that disabling indexstats on mongos resolved the reported scrape errors. This is evidence of a version-specific monitoring gap, not proof that every later release has the defect. (low confidence) (verified as of 2026-03-23) [source]
Problems, failure modes and limitations
- Zero $indexStats accesses does not prove that an index has no purpose: the counter excludes internal TTL deletion and chunk split/migration operations. Long retention does not remove this semantic limitation. (high confidence) [source]
- Monitoring history cannot guarantee an exact lifetime operation count: inference from MongoDB reset behavior and Prometheus sample-based reset handling shows that increments after the last pre-reset scrape can be lost. A reset that occurs and is overtaken between samples may also be invisible as a decrease. (medium confidence) [source]
Comparisons and alternatives
- Prometheus increase() and rate() adjust for observed counter resets. increase() extrapolates across the selected range and can return fractional results; rate() should be applied before aggregation so resets remain detectable. These functions analyze sampled counters rather than reconstructing an exact lifetime ledger. (low confidence) [source]
- For a series with counter semantics, Prometheus increase() adjusts observed decreases caused by resets and extrapolates across the requested window, so results can be fractional. Applying this to exported MongoDB usage requires verifying the deployed metric and label behavior rather than assuming that a raw end-minus-start subtraction survives restarts. (medium confidence) [source]
Facts and statements
- A zero index-access counter is scoped to its observation period and node. Review every relevant replica-set member and allow infrequent workloads to run before deciding that an index is unused. (high confidence) [source]
- The PMM 3 MongoDB Unused Indexes documentation describes zero-access candidates and least-used counts since the last restart, and directs readers to check instance uptime. Historical sample retention therefore must not be equated with that dashboard automatically reconstructing lifetime usage. (medium confidence) (verified as of 2026-10-26) [source]
- Collect and review index usage on every relevant replica-set member: $indexStats reports accesses local to the executing node, and an index unused on one member may be used on another. (high confidence) [source]
- The inspected mongodb_exporter indexstats collector executes a $indexStats aggregation per selected collection, attaches database, collection and key_name labels, and emits accesses.ops. Its sanitizeMetrics function omits accesses.since; this collector code does not implement a durable accumulated usage total. (low confidence) (verified as of 2026-10-30) [source]
- If mongodb_indexstats_accesses_ops is absent, verify collector configuration before interpreting the absence as zero usage. A Percona PMM 2.40.1 support thread identifies the metric and a disabled indexstats collector; PMM 3 dashboard documentation also requires enabling indexstats collection. (medium confidence) (verified as of 2026-10-26) [source]
- A conservative historical record should preserve node, database, collection and index identity plus sample time and MongoDB accesses.since where available. This is a design inference from node-local statistics, reset conditions and exporter labels; it helps distinguish a continuing index from a dropped and recreated index with the same name. (medium confidence) [source]
Children
- No children recorded.