advanced29 min studyLesson 400 in Engineering

Budget telemetry as a production workload with its own evidence

Translate event rates, bytes, retention, replication, and burst margins into a capacity plan, then monitor the pipeline independently of its own blind spots.

On this page

What you’ll understand

  • Calculate telemetry bandwidth and steady-state retention with explicit byte and time units.
  • Separate average demand, burst headroom, failure capacity, and recovery margin.
  • Plan self-monitoring that detects stale, dropped, or partially accepted evidence.

Metrics, logs, and traces consume CPU, memory, network, storage, and query capacity just like other production workloads. Their demand often rises when the service is already unhealthy. A plan based only on average compressed bytes can fail during a burst, a cardinality explosion, or a collector outage. Build a budget from measured signal shapes and named stages, then monitor whether the resulting evidence remains complete and fresh enough for the operational promises it supports.

Keep demand and storage units explicit

For event signals, measure records per second and serialized bytes per record after the chosen attributes and sampling policy. For metrics, include active series, scrape or export frequency, histogram representation, and churn. Distinguish wire-compressed bytes, backend logical ingestion, retained compressed payload, and indexes. A backend's billing or capacity unit may count a different stage from the network interface. Record decimal GB versus binary GiB and seconds versus days so a familiar-looking number does not mix incompatible denominators.

Retention multiplies demand over time, while replication and indexing can add further storage. These are separate factors whose values depend on the system and data. Measure them rather than adopting one universal bytes-per-span or bytes-per-sample constant. A sampled trace can have a variable number of spans and large attributes, so average trace size alone can hide a dangerous tail. Log-schema changes and high-cardinality attributes can alter both event size and indexing work. Capacity fixtures should include realistic distributions and controlled worst cases, not only empty or highly compressible payloads.

Dretained≈r s (86400Td) c k RD_{\rm retained}\approx r\,s\,(86400T_d)\,c\,k\,R
For a steady event rate r records/s, average raw size s bytes, retention T_d days, compressed/raw fraction c, index/storage multiplier k, and replication count R, this estimates retained bytes. Factors are explicit hypothetical or measured assumptions; overlapping accounting, changing distributions, WAL, and transient queues can alter the result.↔ Scroll wide equations horizontally.

Provision the bottleneck and the failure margin

Measure throughput and resource use at producers, agents, gateways, exporters, and storage ingestion rather than assigning the entire path one capacity number. A CPU-heavy processor, a network quota, a finite exporter queue, or an index bottleneck can dominate independently. Scaling collectors also needs correct routing for stateful operations such as tail sampling or temporality conversion; arbitrary load balancing can split state and damage measurement. Preserve the processing contract while adding capacity, and verify achieved throughput rather than assuming a replica count implies proportional service.

Average utilization does not establish burst or failure tolerance. Choose a target utilization with explicit headroom, then check what capacity remains when a component or failure domain is unavailable. Include the spare service needed to drain queued debt after recovery. A system running at its normal arrival rate can stay permanently behind after an outage even though new data no longer accumulates faster. Admission limits or lower telemetry detail can protect service health, but every reduction changes observability and should expose its own loss or selection evidence to consumers.

Cplanned≥rpeakρtarget,Kstorage=DGB pGB-monthC_{\rm planned}\ge\frac{r_{\rm peak}}{\rho_{\rm target}},\qquad K_{\rm storage}=D_{\rm GB}\,p_{\rm GB\text{-}month}
The first planning inequality uses peak compatible records/s and target utilization rho between zero and one; it is not a queueing latency guarantee. The second multiplies retained decimal GB by an explicitly assumed budget coefficient per GB-month. Actual pricing, stage definitions, and other resource charges need their own evidence.↔ Scroll wide equations horizontally.

Monitor evidence health, not only collector uptime

Track accepted, refused, dropped, retried, and exported volume, queue capacity and age, processing latency, and last successful backend observation. Reconcile boundaries using known fixtures or heartbeats while preserving their timestamp assumptions. Collector process uptime does not prove its exporters are succeeding, and backend ingestion does not prove the data is queryable within the required freshness window. Use an independent availability check or evidence channel for critical blind spots so the same broken export path cannot be the sole authority on whether it is broken.

The queue lab illustrates a fixed service-margin comparison only. Reset, set both arrival λ=2 and service μ=3, predict drainage of the initial four jobs, then Play or Step. For a separate overload case, Reset and re-enter both λ=4 and μ=2, predict growth, then inspect. Edits retain elapsed time and recompute from the initial four rather than switch a live accumulated queue. This unbounded fluid model does not predict collector hardware, routing correctness, finite-buffer drops, prices, or query freshness. Those claims require the measured stage budgets and independent checks above.

A transparent hypothetical retention budget

A log stream emits 20,000 records/s averaging 400 raw bytes. Assume steady seven-day retention, compressed/raw fraction 0.25, storage/index multiplier 1.4, and two replicas. Use decimal GB. For illustration only, assign an invented storage coefficient of 0.02 budget credits per GB-month.

  1. Raw bandwidth is 20,000 × 400 = 8,000,000 bytes/s. Over one day that is 691,200,000,000 bytes, or 691.2 decimal GB.

  2. The retained estimate is 691.2 × 7 × 0.25 × 1.4 × 2 = 3,386.88 GB under the stated factors, excluding additional transient/WAL space.

  3. At the explicitly invented coefficient, storage budget is 3,386.88 × 0.02 = 67.7376 credits per month, about 67.74. This is dimensional accounting, not a vendor quote, and excludes ingestion, query, network, and CPU charges.

The result

The transparent assumptions produce about 3.387 decimal TB of retained storage. A usable capacity decision still needs measured factor distributions, stage bottlenecks, burst margins, and failure recovery.

Explore the model

Interactive lab

Interactive lab · queue

Headroom must also drain old evidence

Reset, set both λ=2 and μ=3, predict drainage from four jobs, then Play or Step. Reset and re-enter λ=4 and μ=2 for a separate overload case. Edits retain elapsed time and recompute from initial four. This fluid model has no collector hardware, finite-buffer drops, routing state, billing, or query-freshness mechanism.

Headroom must also drain old evidenceFluid backlog starts at 4 and follows max(0, 4 + (λ − μ)t). The separate M/M/1 residence-time formula assumes Poisson arrivals, exponential service and λ < μ. Current readings: Fluid backlog: 4; Net rate · λ − μ: −1 /s; M/M/1 mean residence: 1 s. All parameters are adjustable with the labeled controls below.02.557.51001.534.56Elapsed time · sFluid backlogλ < μ
Fluid backlogCurrent time
Fluid backlog
4
Net rate · λ − μ
−1 /s
M/M/1 mean residence
1 s
t = 0 s

Fluid backlog starts at 4 and follows max(0, 4 + (λ − μ)t). The separate M/M/1 residence-time formula assumes Poisson arrivals, exponential service and λ < μ. Parameter changes pause playback and recompute the model at the current elapsed time. Reset restores both parameters and returns time to zero. Playback starts paused. Adjust either parameter, then choose Play or Step.

Look forCapacity planning combines measured stage demand, explicit units, recovery margin, and independent evidence that the pipeline is working.

Check your understanding

Collectors remain running and accept data, but an exporter is failing and its queue is aging. Which observation best addresses the pipeline's actual evidence health?

Try it yourself

A pipeline peaks at 24,000 equal-cost records/s. Under a simple utilization budget of at most 0.6, what total compatible service capacity is required? Explain why that number alone does not prove survival of a collector failure.

Take a moment to make a prediction or work it out on paper. Open a hint when you need one.

Give me a hint

Divide peak demand by target utilization, then inspect how much of the capacity remains in the failed configuration.

Compare with the solution

The planned compatible capacity is at least 24,000/0.6 = 40,000 records/s under the simplified budget. Failure survival depends on the capacity, routing, and state that remain when the specified component or domain is lost, plus burst and recovery requirements. Forty thousand nominal capacity spread across an unknown topology is not by itself a failure-tolerance or latency guarantee.

Take it with you

  • Budget records, series, bytes, retention, indexes, and replication at explicitly named boundaries.
  • Peak headroom, stateful routing, failure capacity, and recovery margin are separate requirements.
  • Collector uptime must be supplemented by loss, age, backend freshness, and independent end-to-end evidence.

Read further

Original sources and deeper explanations to follow at your own pace.

Optional progress, saved in this browser when available. Revisit any lesson at any time.

Lesson not marked complete.