Metrics collect vs emit

Is metrics cost dominated by hot-path collect, or by scrape emit?

Numbers are same-host comparisons on a single reference host and are not service-level objectives. See the performance hub disclaimer.

When this matters

metrics.collection can record hot-path series without exporting them (collect: true, emit: false), or skip recording entirely. Operators often ask whether the tax is recording or scrape export. This study keeps metrics.base: standard and varies collect/emit on the volume/failures/lookup/timing categories under forward_fast. See also the metrics scrape tax (base off / minimal / standard with normal scrape).

What we varied

Varied: collect/emit posture (metrics_no_collect → metrics_collect_only → metrics_collect_emit)
Held fixed: sync runtime, forward_fast, standard base, scrape listener present

Evidence

Feature tax — collect vs emit (forward_fast)

Download CSV

Posture	Runtime	Achieved QPS	Avg latency (ms)	Sent	Completed	Workers
metrics_no_collect	sync	73615.4	27.1	738135	738135	ingress=2
metrics_collect_only	sync	70398.5	28.3	706795	706795	ingress=2
metrics_collect_emit	sync	70635.6	28.2	708920	708920	ingress=2

At a glance

collect vs emit (forward_fast): metrics_collect_only costs about 4% QPS versus metrics_no_collect (~70k vs ~74k); metrics_collect_emit costs about 4% QPS versus metrics_no_collect (~71k vs ~74k).

Takeaway

Collect carries most of the standing metrics cost; emit adds little on this median. Versus no-collect (~74k), collect-only costs about 4% (~70k); collect+emit about 4% (~71k).

What to do: turn off collect for categories you do not need. Choose minimal vs standard with operator metrics bases; see the metrics scrape tax for export-facing scrape cost.