CNCFIris Grace Endozo, Farzad Vazirnia and Albert Kerr, Atlassian6 min readadvanced
OpenTelemetry everywhere: Migrating a metrics platform at scale
Summary
Atlassian replaced its decade‑old gostatsd‑based metrics pipeline with a fully OpenTelemetry‑based stack by keeping the StatsD‑UDP contract on the client side and swapping in purpose‑built OTel Collector distributions for collection, ingest, aggregation, and forwarding. The migration was done incrementally, saved ~3.9% CPU per service, cut sidecar cost ~30% fleet‑wide, halved aggregation CPU, and…
- Preserve the existing client contract (StatsD over UDP) and let the collector speak both StatsD and OTLP to avoid a massive re‑instrumentation effort.
- Use a single OTel Collector distribution per pipeline stage so you can iterate on one stage without touching the others.
- Replace the sidecar stack (StatsD + tracing) with a unified collector sidecar, saving ~3.9% CPU per service and ~30% sidecar cost at scale.
- Introduce a stream‑ID based load‑balancing exporter to spread a single high‑traffic service across shards, eliminating hot‑shard CPU spikes and tightening autoscaling.
The post shows a pragmatic path to migrate a massive, production‑critical metrics pipeline to OpenTelemetry without breaking existing services, delivering measurable cost reductions and operational simplifications that other large‑scale orgs can replicate.
8/10
