Hi there,
For your use case, the best starting point is a rate-of-change alert. Instead of watching the absolute size, it measures how fast the size is changing over time, so it naturally ignores databases whose size is stable.
Basic Rate-of-Change Alert
Here’s an example configuration you can use as a starting point:
# Detect sudden database growth/shrinkage
template: mongodb_database_size_rate_change
on: mongodb.database_data_size
class: Utilization
type: Database
component: MongoDB
lookup: max -1s at -10m unaligned of data_size
calc: abs(($this - $data_size) / 600)
units: bytes/s
every: 1m
warn: $this > 10485760 # 10 MB/s growth rate
crit: $this > 52428800 # 50 MB/s growth rate
delay: down 15m multiplier 1.5 max 1h
summary: MongoDB database ${label:database} size changing rapidly
info: Database ${label:database} size is changing at ${this} bytes/sec (10-min window)
to: dba
How it works:
-
Compares the current database size to the size from 10 minutes ago
-
Calculates the rate of change in bytes per second (how fast it’s growing or shrinking)
-
Only triggers when the change rate exceeds the thresholds you set
-
Uses abs() to catch both growth and shrinkage with a single rule
-
Waits 15 minutes before clearing the alert to help prevent flapping
How the calculation works:
-
lookup: max -1s at -10m retrieves the database size from 10 minutes ago
-
This value is stored in $this (the result of the lookup)
-
$data_size is the current database size (dimension auto-variable)
-
Formula: abs(($this - $data_size) / 600)
-
If database grew: old < current, result is negative, abs() makes it positive
-
If database shrank: old > current, result is positive, abs() keeps it positive
-
Division by 600 converts the change over 10 minutes (600 seconds) to bytes per second
-
Result: absolute rate of change in bytes per second
Variable mapping:
-
$this = database size from 10 minutes ago (result of lookup)
-
$data_size = current database size (dimension variable)
-
$now = current Unix timestamp (Netdata variable)
-
$after = start timestamp of lookup window (Netdata variable)
Threshold Guidance
The example thresholds above are intentionally conservative and need tuning for your environment:
For reference:
Adjust based on your database size:
-
Small databases (< 10 GB):
warn: $this > 1048576 # 1 MB/s
crit: $this > 5242880 # 5 MB/s
-
Medium databases (10-100 GB):
warn: $this > 5242880 # 5 MB/s
crit: $this > 26214400 # 25 MB/s
-
Large databases (> 100 GB):
warn: $this > 10485760 # 10 MB/s (as shown above)
crit: $this > 52428800 # 50 MB/s
Set thresholds 50-100% above the maximum change rate you normally see during expected bulk operations.
Implementation Steps
Step 1: Enable Database-Level Metrics
Make sure your MongoDB collector is configured to collect database-level metrics, otherwise the mongodb.database_data_size chart won’t exist:
# /etc/netdata/go.d/mongodb.conf
jobs:
- name: local
uri: mongodb://netdata:password@localhost:27017
databases:
includes:
- "* *" # Collect metrics for all databases
Step 2: Create Alert Configuration
sudo /etc/netdata/edit-config health.d/mongodb.conf
Add the alert template with your chosen thresholds.
Step 3: Reload Health Configuration
sudo netdatacli reload-health
Step 4: Verify Alert is Active
After reloading, verify the alert loaded successfully:
-
Check alert status via API:
http://your-node:19999/api/v1/alarms?all
-
Look for mongodb_database_size_rate_change in the output
-
Verify it shows "status": "CLEAR" (not “DISABLED” or missing)
-
View the chart with alert:
http://your-node:19999/#menu_mongodb_submenu_database
-
Check the alarms page:
http://your-node:19999/#alarms
This configuration should give you reliable detection of unexpected database size changes. If you run into issues during implementation or need help tuning the thresholds after observing your workload patterns, just reply to this message.