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.

Add new feedback Subscribe
Status Completed
Categories Atlas
Created by Guest
Created on Feb 24, 2020

RELATED FEEDBACK

Add 1 second granularity to ATLAS metrics

At present the finest granularity of ATLAS metrics is 1 minute ,as the metrics are averaged by 1 minute , this would not provide info on spikes lasting less than few seconds reducing the granularity to 1 second would give more insight
  • ADMIN RESPONSE
    Aug 1, 2025
    10-second level granularity for Atlas projects is available with M40+ clusters. More information on this is available here: https://www.mongodb.com/docs/atlas/monitor-cluster-metrics/#std-label-premium-monitoring ( https://www.mongodb.com/docs/atlas/monitor-cluster-metrics/#std-label-premium-monitoring )
  • Attach files
  • Guest
    Apr 8, 2025
    To be able to accurately track the Disk IOPS metric a 1-second granularity is imperative. As this is the only(?) per second metric by definition, perhaps it should have a separate setting that applies only to it. Alternatively, it can also be tracked in a separate dashboard. Thank you!
    Reply
  • Guest
    Jul 16, 2021
    We are working to introduce 10-second level granularity for Atlas projects with M40+ clusters as a next step
    Reply
  • Guest
    Jul 15, 2021
    Monitoring Data Storage Granularity 5 minutes for 48 hours is not enough. It would be good to see at least 1-2 months
    Reply
  • Guest
    Jun 10, 2021
    Rather than increasing granularity, just reporting the `max` rather than (or in addition to) the average would go a long way towards making the metrics useful. We have to open up a support ticket to request "FTDC diagnostic data" every time our clusters do anything weird, and it's a pain.
    Reply
  • Guest
    Apr 13, 2021
    For write heavy workloads, sub-minute granularity of disk latency and IOPS would be useful to visually identify the limits of performance.
    Reply
  • Guest
    Mar 30, 2021
    We have also recently had alerts for metrics that we can not see more granularly. We have configured our IOPS for what we believe our usage is but have recently found out we have occasional sub minute spikes of much higher usage.
    Reply
  • Guest
    Feb 17, 2021
    Having alerts that fire from data points at a finer granularity than the metrics, it is very misleading. In our case, multiple alerts are triggering and then you see the metrics, and all looks fine. It makes debugging issues almost impossible.
    Reply
  • Guest
    Mar 23, 2020
    Hi Rez, please look at support case 00643354 - a short CPU usage spike causes disconnections from the server. This CPU spike is invisible to Atlas users since over a period of 1 minute the average cpu usage is smoothed down 60%. I suggest exposing CPU (and possible network as well) at a finer granularity.
    Reply
  • Guest
    Feb 25, 2020
    Hi Sudheer - Thanks for the feedback. We are considering this. What would you reckon are the most metrics to provide <1m granularity to and why?
    Reply