Atlassian moves its metrics to OpenTelemetry without touching any clients
Victoria Shinder1 min readAtlassian has described how it rebuilt the metrics platform that receives data from about 100,000 hosts across 14 regions, replacing its gostatsd-based pipeline with OpenTelemetry, InfoQ reports from a post by three Atlassian engineers on the CNCF blog. The service carried a 99.95% availability objective, so the change had to happen without disrupting metrics that production alerts depend on.
The engineers say gostatsd had been reliable for years, but its UDP-only design could not carry traces or logs, and more services were already producing OpenTelemetry data. Instead of asking thousands of services to move from StatsD clients to the OpenTelemetry SDK, the team kept the StatsD-over-UDP interface and rebuilt everything behind it. In their words, that turned an organisation-wide migration into a platform-team migration.
The new pipeline uses purpose-built OpenTelemetry Collector distributions for four stages: collection, ingest, aggregation and forwarding. For collection, the gostatsd sidecar was replaced by the Collector distribution the tracing team already ran; applications keep sending StatsD packets to the same address, and newer services can send OpenTelemetry metrics directly. Folding metrics into the tracing sidecar saved an average of 3.9% CPU on each of Atlassian's most expensive services, and the team estimates it cut sidecar cost by about 30% across the fleet. An OpenTelemetry Lambda extension keeps the same interface for serverless workloads.
What it means
The transferable idea is the order of work: freeze the interface clients use, then replace the machinery behind it in stages. Stateful aggregation, where every point of a time series must reach the same aggregator, is the stage the write-up singles out as hardest, and it is the part to read in full before copying the design.