Introducción
Nadie toca el pipeline de métricas que funciona. Esa inercia es la razón por la cual Atlassian mantuvo gostatsd, su implementación open-source de StatsD, durante casi una década sirviendo a aproximadamente 100.000 hosts en 14 regiones con un SLO del 99,95%. El problema no era que gostatsd fallara: era que el ecosistema entero migró a OpenTelemetry y el pipeline se quedó atrapado en un modelo UDP-only, sin soporte nativo para trazas, logs ni para los componentes que la comunidad del OTel Collector publicaba cada trimestre. Iris Grace Endozo, Farzad Vazirnia y Albert Kerr, del equipo de plataforma de Atlassian, documentaron en el blog de la CNCF (septiembre de 2026) cómo resolvieron ese dilema sin un proyecto de re-instrumentación que involucrara a miles de equipos de producto.
La decisión no fue «reemplazar todo mañana». Fue una apuesta de arquitectura: mantener el contrato que los servicios conocen (StatsD por UDP hacia una dirección fija) y reconstruir todo lo que hay detrás con distribuciones del OpenTelemetry Collector. El resultado es un pipeline end-to-end en OTel que ya no depende de código propietario interno, con reducciones de CPU medibles en cada etapa y una superficie operativa que se reduce a un único codebase.
Qué ocurrió
El trigger concreto fue la acumulación de deuda funcional. Cada vez más servicios internos emitían datos en formato OTLP, y gostatsd simplemente no los entendía. Cada feature nueva del OTel Collector —procesadores de batching, exporters a backends emergentes, pipelines de correlación— era algo que el equipo de Atlassian eventualmente tendría que reimplementar a mano. La frase del equipo es directa: «We will lose that race. It’s only a question of when.»
La migración se ejecutó en cinco etapas secuenciales, cada una aislable y reversible. En la capa de collection, reemplazaron el sidecar de gostatsd por la distribución del OTel Collector que el equipo de tracing ya operaba en producción desde hacía años, lo que eliminó la pregunta «¿es esto production-ready a nuestra escala?». La aplicación seguía disparando StatsD por UDP al mismo puerto; nadie en los equipos de producto notó el cambio. En paralelo, habilitaron un receptor OTLP en esa misma capa para recibir métricas nativas de OTel sin exigir migración de SDK.
En ingest, resolvieron un problema clásico de agregación stateful. El proxy interno «nomad» roteaba por hash de (service, environment) hacia un shard, pero la distribución de carga seguía una cola larga: los shards con los servicios más grandes se convertían en hot shards. La solución fue usar el loadbalancingexporter contrib del OTel Collector, que permite hashear por streamID (la identidad de una serie temporal individual) en vez de por servicio. Una serie grande se distribuye uniformemente sobre el pool, y cada serie individual siempre cae en el mismo shard. El resultado: la CPU por shard pasó de barras desparejas con réplicas ociosas a una distribución plana, con autoscaling más ajustado y sin más páginas por hot shard.
En aggregation, la etapa que hace viable el costo, procesan ~4.800 millones de datapoints por minuto y los reducen a ~220 millones, un 96% de compresión. Como la mayoría de sus métricas usan delta temporality y ningún componente upstream agregaba deltas con la semántica que sus usuarios esperaban, escribieron un procesador propio y lo publicaron como open-source en atlassian-labs. El tier de agregación pasó a correr con aproximadamente la mitad de CPU.
En forward, reemplazaron un forwarder interno ad-hoc por una distribución stateless del Collector (metrics-gateway) con exporters comunitarios para fan-out a SignalFx, S3 y otros backends. Agregar un destino nuevo pasó de ser un proyecto a ser un cambio de configuración. Por último, en Lambda, donde no se puede correr un sidecar, construyeron una extensión OTel Lambda que mantiene la misma dirección StatsD y las mismas variables de entorno: cero cambios de código para los servicios serverless.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
El impacto financiero es concreto y ya medible. Los agregadores de gostatsd y el proxy nomad representan aproximadamente el 38% de los CPU requests en los clusters de métricas de Atlassian. Nomad, solo, consume un 13% de los recursos totales. Eliminar ambos componentes libera capacidad real, no teórica. En la capa de collection, plegar métricas dentro del sidecar de tracing y eliminar el sidecar de StatsD ahorró un 3.9% de CPU promedio por servicio en los Micros services más costosos, lo que equivale a un recorte cercano al 30% del costo de sidecars a escala de flota.
Para equipos de infraestructura y SRE, el cambio operativo es igual de relevante. De mantener dos sidecars por host (uno para StatsD, otro para tracing) se pasa a uno solo. De operar cuatro servicios internos distintos (gostatsd, nomad, forwarder propio, agregadores) se pasa a un único codebase de OTel Collector con configuraciones por etapa. Agregar un procesador, un exporter o un nuevo backend es escribir un componente y modificar un YAML, no levantar un servicio nuevo con su propio ciclo de vida, alertas y runbook.
Detalles técnicos
La arquitectura final distribuye el OTel Collector en cuatro etapas con responsabilidades acotadas:
# Esquema conceptual de la distribución por etapas
collection:
# Reemplaza gostatsd sidecar. Recibe StatsD UDP + OTLP.
# Distribución: misma que el equipo de tracing ya operaba.
receivers: [statsd, otlp]
processors: [memory_limiter, batch]
exporters: [otlp]
ingest:
# Reemplaza nomad. Roteo stateful por streamID.
receivers: [otlp]
processors: [memory_limiter]
exporters: [loadbalancing] # hash_key: streamID
aggregation:
# Delta aggregation processor (open-source, atlassian-labs).
# ~4.8B datapoints/min → ~220M (96% reduction).
receivers: [otlp]
processors: [delta_aggregation, memory_limiter]
exporters: [otlp]
forward:
# metrics-gateway: stateless, fan-out a SignalFx, S3, etc.
receivers: [otlp]
exporters: [signalfx, s3, otlp]
# Retries, queuing y backpressure heredados de la comunidad.
Para el caso de AWS Lambda, la extensión OTel Lambda reemplaza el sidecar de gostatsd. El contrato externo es idéntico: misma dirección UDP, mismas variables de entorno. No se requiere modificar el handler ni los clients de métricas dentro de la función.
El loadbalancingexporter del contrib del OTel Collector es el componente que resuelve el problema de hot shards en la etapa de ingest. La diferencia clave está en la clave de hasheo: service concentra tráfico; streamID lo distribuye. Cada serie temporal individual mantiene afinidad de shard (necesario para agregación stateful correcta), pero un servicio con miles de series se spreadea sobre el pool.
Qué deberían hacer los administradores y equipos técnicos
Si operan un pipeline de métricas basado en StatsD, Graphite o un collector propietario interno y evalúan migrar a OpenTelemetry, el caso de Atlassian ofrece un playbook replicable:
Conclusión
La migración de Atlassian no es un caso de «OpenTelemetry es mejor que StatsD». Es un caso de gestión de deuda técnica a escala: cuando el ecosistema avanza y tu componente interno se queda atrás, el costo de mantener la paridad crece cada sprint. La solución no fue un big-bang org-wide sino una sustitución etapa por etapa, preservando el contrato externo y absorbiendo la complejidad dentro del equipo de plataforma. Los números —30% menos costo de sidecars, 50% menos CPU en agregación, eliminación del 38% de CPU de los clusters— justifican el esfuerzo sin necesidad de una narrativa de modernización. Para cualquier equipo que opera un pipeline de métricas propietario, el patrón es claro: cambien el motor, dejen el volante donde está.
Fuentes
- https://www.cncf.io/blog/2026/09/17/opentelemetry-everywhere-migrating-a-metrics-platform-at-scale/