Skip to content
MTTL, Mean Time To Learn

BusinessPractitioner

Simulator: cost is decided at the Collector

For: architects · finance, risk and compliancePrerequisites: Basic notions of metrics, traces, logs and the OpenTelemetry Collector.

Reading mode

Observability cost does not depend on what you observe but on what you decide to keep. Filtering at the backend means paying to ingest data you then throw away; the same filtering in the Collector removes data before transport, ingestion and storage. This simulator uses the illustrative scenario of a mid-size Kubernetes platform (6 million active series, 800 GB of traces and 1.2 TB of logs per day) and shows what each lever takes off the volumes, then off the bill if you enter your prices.

Prices change fast and vary by contract: this guide gives none; use your provider’s dated price list. Without prices, the simulator shows volumes in series and in GB per month; with your volume prices, it shows the bill before and after, signal by signal.

Volumes (assumptions)
Your prices (optional)
Levers in the Collector

Result

Before / After

SignalBeforeAfterChange

Months of 30 days. Levers chain in the order shown: a lever’s contribution depends on the ones before it on the same signal. The fixed base does not move with volumes, which is why a large volume cut does not divide the bill by as much.

Things to try

Section titled “Things to try”
  1. Look at the default volumes: 6 million active series become 1.8 million (-70%), 24,000 GB of traces per month become 3,240 GB (-86.5%), and 36,000 GB of hot logs per month become 11,902 GB (-66.9%), plus 8,978 GB sent to cold storage.
  2. Turn off every lever except the first two: cardinality alone (unbounded labels, per-service aggregation) already removes 4.2 million of the 6 million active series, without touching application code.
  3. Raise the share of traces kept from 13.5% to 50%: tail sampling still cuts volume, but an overly generous policy (latency threshold too low) wipes out much of the saving: the lever now removes only 12,000 GB of traces per month instead of 20,760. The 13.5% comes from the default settings of the tail sampling simulator: 1% errors and 5% slow traces all kept, plus 8% of the rest (0.01 + 0.0495 + 0.9405 × 0.08 ≈ 0.135, shown rounded to 13%).
  4. Look at the routing row: it removes no GB, it moves 8,978 per month from hot to cold storage. Its monthly saving is therefore 8,978 x (hot_gb_price - cold_gb_price): enter your prices and give cold storage the same price as hot, and the lever no longer saves anything. It is worth the price gap between hot and cold, not the routing itself.
  5. Enter your prices, then raise the fixed base: the relative reduction flattens. Depending on your provider’s pricing model, the same volume cut does not yield the same saving.

The rule

Section titled “The rule”

Cardinality first, sampling next, routing for the rest. The first two levers deliver most of the saving because they act on the largest volumes; routing mainly serves to meet retention obligations without paying hot storage prices. The amount depends on your prices: enter those of your contract; the volumes removed tell the story even without them.

Further reading: the business dimension, the cardinality simulator, the tail sampling simulator and the bridges.

Revised on 2 October 2026: prices removed; the simulator shows volumes, and the bill only with your prices.