Estimate total observability platform cost from logs, metrics and traces ingested.
Total observability spend is the sum of what each pillar costs under your vendor's pricing model: monthly = logs_cost + metrics_cost + traces_cost, where each is volume × unit price under that vendor's specific pricing dimension (per-GB for logs/traces, per-series for metrics). Because vendors price these very differently — some charge per-GB across all three pillars, others charge per-host or per-series for metrics — plugging in your specific vendor's rates lets you compare total cost of ownership across providers on equal footing.
monthly_cost = logs_GB_per_month × cost_per_GB_logs + metrics_series × cost_per_series + traces_GB_per_month × cost_per_GB_traces
Metrics pricing is usually driven by cardinality (how many unique time series exist) rather than raw data volume, since each series requires ongoing storage and indexing regardless of how many data points it contains — high-cardinality labels (e.g. per-user or per-request-ID tags) can explode series count and cost.
Lower log verbosity in production (shift to sampling or structured summaries), reduce trace sampling rate, drop or aggregate high-cardinality metric labels, and set tighter retention windows on less critical data.
It varies by architecture, but logs are frequently the largest cost driver for verbose applications, while metrics cardinality dominates for microservice architectures with many labeled dimensions (per-pod, per-endpoint, per-customer).
Yes — running the same volume/cardinality inputs through each vendor's actual per-unit pricing surfaces true cost differences, since list prices per GB or per series can vary by more than 2-3× between vendors for comparable data.