Estimate CPU and memory overhead added by running Prometheus exporters on a host.
Exporters (node_exporter, cAdvisor, application-specific exporters, sidecar exporters) are lightweight individually but add up at fleet scale: total_CPU = exporters × CPU_per_exporter, total_memory = exporters × memory_per_exporter. At ~50 millicores and ~30 MiB per instance, a fleet of a few hundred exporters is usually a rounding error against total cluster capacity, but fleets in the tens of thousands can represent a meaningful dedicated resource allocation worth tracking explicitly.
total_memory_MB = exporters × memory_per_exporter_MB; total_cpu_millicores = exporters × cpu_per_exporter_millicores
A simple exporter like node_exporter mostly reads and re-exposes kernel/proc data with minimal processing, while exporters that maintain internal caches, connect to a database, or compute derived metrics (e.g. blackbox_exporter running active probes) can use substantially more CPU and memory per instance.
Yes — even lightweight exporters should have Kubernetes resource requests/limits set explicitly, both to guarantee scheduling and to catch a misbehaving exporter (e.g. one leaking memory or stuck in a scrape loop) before it impacts co-located workloads.
Slightly — more frequent scrapes mean the exporter's HTTP handler and metric-collection logic run more often, but for most simple exporters this effect is small relative to their baseline footprint unless the exporter does expensive work per scrape (e.g. re-reading large files).
Exporter overhead is distributed across your fleet (many small allocations), while Prometheus server resource needs are concentrated (fewer, larger allocations) — both should be tracked, but they represent different parts of your monitoring stack's total resource budget.