The Cost Structure of Logs, Metrics, and Traces

How logs, metrics, and traces create different ingest, storage, query, and operational costs and why those differences matter for design.

The cost structure of logs, metrics, and traces is different enough that teams should not govern them as if they were interchangeable. Logs often dominate ingest and retention cost because they are verbose and unstructured or semi-structured. Metrics are usually cheaper per signal but can become expensive through high cardinality and long retention. Traces can become costly through span volume, attribute richness, and the need for high-performance search during incidents.

The key design question is not “which is cheapest?” It is “which signal creates the best diagnostic value per unit of cost for this kind of question?” That answer changes by workload and by incident model.

    flowchart LR
	    A["Logs"] --> B["High volume / rich detail"]
	    C["Metrics"] --> D["Low detail / broad coverage"]
	    E["Traces"] --> F["Request-level causality / selective depth"]
	    B --> G["Cost trade-offs"]
	    D --> G
	    F --> G

Different Signals Spend Money In Different Ways

Typical cost drivers include:

  • log line volume and verbosity
  • metric label cardinality and retention length
  • trace span volume, sampling rate, and search performance expectations
  • cross-region transfer or duplication
  • query behavior during incidents
 1telemetry_cost_drivers:
 2  logs:
 3    - ingest_volume
 4    - retention_days
 5    - verbose_debug_fields
 6  metrics:
 7    - active_series_count
 8    - label_cardinality
 9    - long_term_storage
10  traces:
11    - spans_per_request
12    - sampling_rate
13    - searchable_retention

What to notice:

  • metrics are not automatically cheap if cardinality is uncontrolled
  • traces are not automatically expensive if they are targeted and sampled well
  • logs are often indispensable but need volume discipline

Cost And Diagnostic Value Must Be Considered Together

One of the biggest mistakes is judging a signal only by storage cost. A costly signal may still be worth it if it resolves incidents quickly and reliably. A cheap signal may be poor value if it never answers important questions. Observability economics is about trade-offs, not only reduction.

Design Review Question

If a team says metrics are always cheaper than logs and therefore should replace most logging, what cost-design mistake are they making?

The stronger answer is assuming one signal dominates economically in all cases. Cost depends on volume, cardinality, retention, and diagnostic need, not just signal type labels.

Quiz Time

Loading quiz…
Revised on Thursday, April 23, 2026