Skip to Main Content

MongoByte MongoDB Logo

Welcome to the new MongoDB Feedback Portal!

{Improvement: "Your idea"}
We’ve upgraded our system to better capture and act on your feedback.
Your feedback is meaningful and helps us build better products.

Status Submitted
Created by Ariel Fernandez
Created on Nov 10, 2026

Feature Request: Expose IOPS Utilization Percentage Metrics in Datadog Integration

What problem are you trying to solve?

Focus on the what and why of the need you have, not the how you'd like it solved.

We would like to request the addition of IOPS utilization percentage metrics to the MongoDB Atlas Datadog integration.
Currently, the Datadog integration exposes the following IOPS metrics as absolute values:

mongodb.atlas.system.disk.iops.reads
mongodb.atlas.system.disk.iops.writes
mongodb.atlas.system.disk.iops.total
mongodb.atlas.system.disk.max.iops.reads
mongodb.atlas.system.disk.max.iops.writes
mongodb.atlas.system.disk.max.iops.total

However, these absolute values make it difficult to create generic, cluster-agnostic monitors that alert based on a percentage of provisioned IOPS capacity. Different cluster tiers have different IOPS limits, so a single threshold does not apply universally.

What would you like to see happen?

Describe the desired outcome or enhancement.

We would like to request the following new metrics to be exposed in the Datadog integration:

mongodb.atlas.system.disk.iops.percentused — Percentage of total provisioned IOPS being utilized (read + write combined)

mongodb.atlas.system.disk.iops.reads.percentused — Percentage of provisioned read IOPS being utilized
mongodb.atlas.system.disk.iops.writes.percentused — Percentage of provisioned write IOPS being utilized

Why is this important to you or your team?

Explain how the request adds value or solves a business need.

These percentage-based metrics would enable us to:

Create generic monitors that work across all cluster tiers regardless of provisioned IOPS capacity
Set consistent alert thresholds (e.g., warn at 90%, alert at 95%) that scale automatically with cluster tier
Reduce false positives and false negatives caused by fixed IOPS thresholds that don’t account for tier differences
This feature would significantly improve our ability to proactively monitor disk I/O saturation across our entire Atlas fleet.

What steps, if any, are you taking today to manage this problem?

Using alternative metrics

  • Disk Queue Depth — best indicator of disk saturation (sustained > 10 is a concern)

  • Disk Latency — read/write responsiveness (single-digit ms is healthy)

  • CPU IOWait — percentage of CPU time waiting on I/O