Scale Infrastructure Fearlessly - Cardinality Can’t Hold You Back

Protection activates automatically when any metric context (containers, disks, network interfaces) exceeds 1,000 instances AND >50% are ephemeral (no longer actively collected). The system clears long-term retention for inactive time series while preserving all real-time data. Thresholds are configurable via netdata.conf for specialized environments.

Active data is never lost. Protection only affects long-term retention (tier 1 and tier 2) for instances that have zero retention in tier 0 (per-second data) - meaning they’re no longer actively collected. Real-time data for active metrics, recent historical data, and any data for currently monitored resources remain completely intact. You only lose long-term historical trends for resources that no longer exist (e.g., deleted containers from weeks ago).

Datadog requires manual configuration of tag allowlists and blocklists - you must predict which labels you’ll need for future troubleshooting and tune the cardinality estimator. Netdata’s approach is fundamentally different: zero configuration, automatic protection based on activity, no cost impact from cardinality, and edge processing handles high cardinality locally before streaming. With Netdata, you don’t manage cardinality - you simply don’t think about it.

Yes - this is exactly what Extreme Cardinality Protection was designed for. Netdata automatically monitors every pod from the first second of life (per-second granularity captures short lifecycles), detects when pods stop running, clears long-term storage for inactive pods, and preserves all active data. Real-world proof: Nodecraft achieved 90% reduction in downtime with Netdata monitoring their rapidly scaling container infrastructure.

At 4.6 million metrics per second (equivalent to ~1,000 monitored nodes): Netdata uses ~47 GB RAM vs Prometheus ~383 GB RAM - 88% less memory. This comes from edge processing (each agent handles its own cardinality locally with 150-200MB per agent), parent aggregation (receive pre-processed streams), intelligent compression (Gorilla + ZSTD achieve ~0.6 bytes per sample), and per-CPU aggregation (eBPF metrics aggregated in-kernel before userspace). Critically, Netdata’s resource usage scales linearly with metrics—doubling your metrics roughly doubles resource usage, not exponentially like centralized systems where indexing overhead compounds.

Two architectural differences: (1) Contained impact - each Netdata agent handles its own cardinality independently, so a cardinality explosion on one server cannot cascade and take down your entire monitoring infrastructure. In centralized systems like Prometheus, high cardinality can OOM the central database and blind you to all servers. (2) Linear resource scaling - Netdata uses proportional resources per time-series (minimal CPU, memory, disk I/O per metric), while centralized systems often exhibit exponential resource growth with cardinality due to indexing overhead.

No manual configuration required for 99% of deployments. Netdata’s defaults are production-ready with protection enabled, 1,000 instance threshold, and 50% ephemerality minimum. You only need to adjust if you expect >1,000 instances per context per node (rare) or want more/less aggressive protection. For eBPF collectors, default hash table sizes are production-safe and handle thousands of processes.

Netdata collects every metric every second (tier 0) with no sampling or averaging, automatically creates per-minute aggregates (tier 1) and per-hour aggregates (tier 2) in parallel with no post-processing, and monitors tier 0 as source of truth for protection. When instances drop from tier 0 (no longer collected), they’re marked as ephemeral. After threshold reached, tiers 1 & 2 are cleared for ephemeral instances only. Result: real-time per-second data for troubleshooting, efficient long-term trends for capacity planning, automatic cleanup of unused historical data.

Netdata uses predictable per-node pricing for infrastructure monitoring, and the price does not change with metric count, labels, or cardinality. Traditional platforms charge based on unique time series (cardinality), making high-cardinality infrastructure prohibitively expensive. With predictable per-node pricing and no metrics volume charges, you achieve 90% cost reduction compared to traditional monitoring platforms. No egress fees, no cardinality multipliers, no per-metric charges, no surprise bills.

For infrastructure monitoring: yes, completely. Netdata provides superior capabilities for hosts, VMs, containers, Kubernetes, databases, message queues, web servers, cloud platforms, network devices, and hardware sensors. Migration strategy: deploy Netdata in parallel (week 1), teams use Netdata for troubleshooting (weeks 2-4), disable redundant collectors in existing tools (month 2), decommission expensive platforms (month 3). For traces: Netdata ingests OpenTelemetry traces over OTLP on the same agent, with a Traces tab in Netdata Cloud for heatmaps, waterfalls and span details. Teams that rely on code-level profiling usually keep a dedicated APM tool for it while consolidating infrastructure monitoring (the largest cost component) on Netdata.

Time to first dashboard: 60 seconds with one-line install and automatic discovery. Time to first insights: 60 seconds with all auto-discovered metrics visualized immediately. Time to ML anomaly detection: 15 minutes for baseline, then 18 models per metric detect anomalies automatically. Complete enterprise deployment: Day 1 (design topology, deploy agents/parents), Day 2 (add credentials, review alerts, invite team). Proof: KAUST achieved 50% improvement in troubleshooting efficiency, Nodecraft detects problems within 30 seconds vs 2-3 minutes before.