OpenTelemetry cost of ownership

The OpenTelemetry framework and the Collector carry no license fee. The Collector repository is licensed under Apache-2.0, and there is no paid edition to buy. The cost of ownership sits in four pools: backend storage and ingest, Collector infrastructure, instrumentation work, and telemetry volume. Each pool is paid to a different party, and each one recurs for as long as the telemetry runs. Budgeting for the framework alone will understate the total, because OpenTelemetry does not store or visualize data. A separate backend does that work.

Backend storage and ingest is usually the largest line on the invoice. If you buy a backend, the vendor typically bills for ingest, retention and sometimes query volume. If you host an open-source backend yourself, the cloud provider bills for the storage, compute and network it consumes, and your internal platform team carries the operating work. Before comparing options, ask each backend how it meters ingest, how long it retains data by default, and which charges apply to queries and to data moved between regions. These terms decide how the other pools behave once volume grows.

Collector infrastructure covers the compute, memory and network for two tiers. Agents run beside services, and gateways accept data from many sources. The cloud provider bills for the instances or containers, and the platform team sizes, scales and patches them. Gateways are shared choke points, so their memory headroom and network egress deserve the closest attention. Ask the team to document the expected load per tier, how each tier scales under a traffic spike, and which cross-zone or cross-region transfers the design creates.

Instrumentation work is paid in engineering hours, either to your own developers or to a partner. Automatic instrumentation covers many common frameworks with little code change, while manual spans and metrics require developers to decide what to measure and how to name it. The work does not end at rollout. Teams must review attribute naming, keep SDKs current as stability varies by language, and check that new code emits telemetry consistently. Log SDK maturity varies more than trace SDK maturity across languages, so plan that review effort per language in use.

Telemetry volume multiplies every other pool. Each additional span, metric series or log line raises backend ingest, Collector CPU and memory, and network traffic at once. High-cardinality attributes are the most common cause of surprise growth. Assign one owner for the telemetry budget, and make sampling, filtering and attribute removal part of the design review. Release provenance adds a build cost. Official Collector releases ship the contrib distribution with signed artifacts, SHA256 checksums and SBOM files, along with the Collector builder and OpAMP supervisor. Verifying those files against your policy is a recurring task. A custom distribution built to include only the components you need removes unused code, but it also makes your team responsible for building, signing, generating SBOMs and patching the distribution on every release.

The cost model is only as good as the volume data behind it. Before any estimate is built, the client should provide a service and language inventory, current telemetry volumes or recent ingest bills from every tool that receives traces, metrics and logs today, and the retention periods each signal must meet. Volume is the largest driver of backend cost, and it is the input most often missing. When no one can say how many spans, metric series or log lines a service produces per day, the model has to carry wide ranges for storage, ingest and query costs. Those ranges can make the difference between a decision that holds and one that gets reopened in finance review. Ingest bills from existing vendors are the most reliable source because they show what was actually sent, not what teams think they send.

Retention and compliance requirements set how long data is kept and where it can live, so they belong in the inputs as well. Name the signals that fall under a retention rule, the minimum and maximum periods, and whether any data must stay in a specific region or account. List the target backends and their contract terms, including pricing units, committed spend, overage rules and any data egress charges. A backend that bills by ingested gigabyte and one that bills by active series will produce very different models from the same telemetry. Also provide the hosting platform and region constraints for the Collector fleet, and describe any Collector or agent already deployed, including its version, how it is managed and which exporters it uses. Existing agents can be reused and lower the cost of the rollout, but only if the team knows what they run.

Three named owners should be confirmed before work starts: one in finance who owns the cost assumptions, one in platform engineering who owns the hosting and Collector fleet, and one in security who owns data classification, redaction and access rules. The finance owner should agree an assumption register with the delivery team before modeling begins. The register is a short written list of each assumption, its value, its source, the person who confirmed it and the date it was confirmed. Typical entries include daily volume per service, sampling rate, retention per signal, price per unit from each backend contract and expected growth. Agreeing the register up front means that later changes can be traced to a specific assumption rather than argued from memory.

Two policy decisions change volume more than almost any other input, so they should be made before the model is built. The first is the sampling policy: whether traces are sampled at the SDK, at a Collector gateway, or both, and which traffic is always kept, such as errors or specific transactions. The second is the redaction policy: which attributes must be removed or masked before data leaves the client's environment, which the redaction processor can handle in the Collector. Each decision alters the expected volume and therefore the backend bill, and the security owner should sign off on the redaction list because it defines what data is sent to third-party storage. Record both decisions in the assumption register with the date they were approved, so the model reflects policy rather than guesswork.

Finally, state what the client does not have. Gaps are normal, and a clear list of unknowns is more useful than an estimate that hides them. Mark each missing input as an open item with an owner and a date to resolve it, and ask the delivery team to show how the model range narrows as each item closes. If an ingest bill is not available for a service, the model should say so and carry a documented assumption rather than a silent guess. Clients who provide complete inputs in writing usually receive a quote that matches the scope they agreed, while incomplete inputs tend to produce a wide range and a longer discovery phase.