Calculate total metric samples ingested per second across all monitored targets.
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.
ingestion_rate_samples_per_sec = active_series / scrape_interval_sec
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.
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.
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.
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.