Combined metrics + dnstap tax

What does turning on standard scrape and fuller dnstap together cost?

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

When this matters

Production postures often enable more than one observability surface. Studies that turn on only metrics scrape or only dnstap (metrics scrape, dnstap emit) miss interaction cost. This study places observability off, standard scrape alone, fuller dnstap alone, and both under the same forward_fast recipe.

What we varied

Varied: observability posture (metrics_off, metrics_standard_scrape, dnstap_full, metrics_standard_dnstap_full)
Held fixed: sync runtime, forward_fast, ingress workers, dnsperf recipe

Evidence

Feature tax — metrics and dnstap combined (forward_fast)

Download CSV

Posture	Runtime	Achieved QPS	Avg latency (ms)	Sent	Completed	Workers
metrics_off	sync	75940.7	26.3	761386	761386	ingress=2
metrics_standard_scrape	sync	70029.9	28.5	703153	703153	ingress=2
dnstap_full	sync	68939.9	28.9	692386	692386	ingress=2
metrics_standard_dnstap_full	sync	64339.4	31.0	645499	645499	ingress=2

At a glance

metrics and dnstap combined (forward_fast): metrics_standard_scrape costs about 8% QPS versus metrics_off (~70k vs ~76k); dnstap_full costs about 9% QPS versus metrics_off (~69k vs ~76k); metrics_standard_dnstap_full costs about 15% QPS versus metrics_off (~64k vs ~76k).

Takeaway

Scrape and dnstap each cost QPS; together they cost more. Versus observability off (~76k): standard scrape about 8% (~70k), fuller dnstap about 10% (~69k), both on about 16% (~64k). Combined is higher than either alone without claiming a precise interaction model.

What to do: enable each surface only if you need it. Size them separately with the metrics scrape tax and dnstap emit tax, then remeasure the pair on your hardware before production.