Metric Ingestion Calculator
Calculate total metric sample ingestion rate across all scrapers, targets and metrics per target.
Inputs
Number of Prometheus instances or shards scraping targets.
Average scrape targets assigned to each scraper.
Average number of exposed metric series per scrape target.
How often each target is scraped.
Total Ingestion Rate
12,000.0samples/sec
Total Series Scraped
180,000series
Per-Scraper Ingestion Rate
4,000.0samples/sec
Daily Ingested Samples
1,036,800,000
Step by step
Total targets: scrapers × targets/scraper
3 × 400
= 1200 targets
Total series scraped: targets × metrics/target
1200 × 150
= 180,000 series
Ingestion rate: series ÷ scrape interval
180,000 ÷ 15s
= 12000.0 samples/sec
Per-scraper ingestion rate
12000.0 ÷ 3
= 4000.0 samples/sec/scraper
How it works
Total ingestion rate = scrapers × targets_per_scraper × metrics_per_target ÷ scrape_interval. This is the core number that drives TSDB write throughput, CPU cost of sample appends, and — combined with retention — total disk usage. Sharding scrapers evenly (targets_per_scraper roughly equal across shards) keeps per-scraper ingestion balanced and avoids any single Prometheus instance becoming a hotspot.
Formula
ingestion_rate_samples_per_sec = active_series / scrape_interval_sec
- active_series
- Total active time series being scraped
- scrape_interval_sec
- Seconds between scrapes
Frequently Asked Questions
What's a healthy ingestion rate per Prometheus instance?
A single well-resourced Prometheus instance commonly handles hundreds of thousands to low millions of samples per second, but the practical ceiling depends heavily on cardinality, query load, and available CPU/memory — benchmark your specific workload rather than relying on a universal number.
Why does metrics-per-target vary so much between services?
Client libraries auto-expose runtime metrics (GC stats, HTTP histograms with many buckets, per-endpoint counters) that scale with how many distinct label combinations an app has — a service with many endpoints or per-customer labels can expose orders of magnitude more series than a simple service.
Does this account for federation or remote_write fan-out?
No — this models direct scrape ingestion only. If you federate or remote_write to a central store, that store's ingestion rate is a separate (often equal or aggregated) calculation on top of this per-scraper figure.
How do I reduce ingestion rate without losing visibility?
Use `metric_relabel_configs` to drop unused metrics/labels at scrape time, increase scrape interval for low-value/high-cardinality targets, and rely on recording rules to pre-aggregate high-cardinality raw series into cheaper derived series.