Posted on September 17, 2026 by Iris Grace Endozo, Farzad Vazirnia and Albert Kerr, Atlassian For most of the last decade our metrics pipeline ran on gostatsd, the open-source StatsD implementation we maintain. It primarily did two jobs: as sidecar on every host and the aggregation tier at the other end. It took metrics from roughly 100k hosts across 14 regions at a 99. 95% SLO and minimal latency and it was fine. Nobody thought about it much, which is usually the sign of good infrastructure. Gostatsd served us for many, many years.
However, the community continuously and consistently converged on OpenTelemetry over the past few years. It became the thing everyone standardized on and more and more of what fed our pipeline was emitting OTel data we simply didn’t support. Gostatsd was UDP-only, had no story for traces or logs and every clever thing the OTel Collector community shipped was one more thing we'd eventually rebuild by hand just to stay level. It's only a question of when. The how is what we discuss here.
With observability wired into thousands of services and many different bespoke platforms, the obvious plan (tear out the old pipeline, get every team to re-instrument on the OTel SDK, flip the switch) is a pipe dream: a multi-year org-wide slog on a pipeline that can't take an outage with a real chance of dropping the exact data alerts fire on. The question we actually needed to answer was narrower. How do we replace the whole engine without huge impact across Atlassian services? The bet: swap the collection and pipeline, leave the interface alone A metrics pipeline is really a contract with two ends.
One end is what service owners see: "send StatsD over UDP to this address → your metrics show up in the backend. " The other is everything between that packet and long-term storage. Teams care enormously about the first end and very little about that middle layer. So we kept the interface and rebuilt everything behind it, which turned an org-wide migration into a platform-team migration. We put purpose-built OTel Collector distributions at each of the four stages (collection, ingest, aggregation, forward) so we could work on any one without touching the others.