Atlassian migra 100.000 hosts a OpenTelemetry
Atlassian migra su pipeline de métricas a OpenTelemetry sin que los servicios modifiquen su código. La agregación ya solo necesita la mitad de CPU.
Atlassian migra el pipeline de métricas de unos 100.000 hosts de gostatsd al OpenTelemetry Collector sin que ningún servicio tenga que modificar su interfaz. La nueva etapa de agregación funciona con el mismo tráfico usando aproximadamente la mitad de CPU. Los antiguos agregadores de gostatsd y el proxy nomad siguen funcionando por ahora.
Lo esencial en breve
- La interfaz StatsD se mantiene, detrás de ella trabaja el OpenTelemetry Collector. Los servicios envían por UDP a la dirección habitual y la nueva distribución del Collector acepta en paralelo OTLP.
- Una nueva clave de shard distribuye uniformemente los grandes servicios por el pool. La clave streamID del loadbalancingexporter mantiene así cada serie temporal en el mismo shard.
- La agregación compacta unos 4,8 mil millones de puntos de datos por minuto a unos 220 millones. Con el mismo tráfico, la etapa funciona con aproximadamente la mitad de CPU.
Límites del pipeline anterior
El pipeline de métricas de Atlassian recopila telemetría de unos 100.000 hosts en 14 regiones. Hasta ahora funcionaba con gostatsd, una implementación de código abierto del protocolo StatsD mantenida por la empresa.
El pipeline operaba con un SLO del 99,95 %, un objetivo interno de nivel de servicio. Además, gostatsd solo aceptaba métricas por UDP y no ofrecía solución para trazas ni logs. El equipo habría tenido que replicar manualmente cada novedad de la comunidad de OpenTelemetry.
¿Qué es el OpenTelemetry Collector? El OpenTelemetry Collector es un software de arquitectura modular para recibir, procesar y reenviar datos de telemetría. Acepta protocolos como OTLP o StatsD y exporta a backends como SignalFx o S3. Los reintentos, las colas y la limitación de tasa (throttling) forman parte de su funcionalidad estándar, y muchos componentes los desarrolla conjuntamente la comunidad de OpenTelemetry.
Migración en cuatro etapas
Atlassian desplegó en cada una de las cuatro etapas (recopilación, ingesta, agregación y entrega) una distribución propia del Collector y así pudo remodelar cada etapa por separado. En la interfaz hacia las aplicaciones no cambió nada. Los servicios siguen enviando métricas StatsD por UDP a la misma dirección, mientras la nueva distribución del Collector acepta en paralelo OTLP, el protocolo nativo de OpenTelemetry.
Ya solo con unificar el sidecar de StatsD y el de trazas, los procesos auxiliares de cada host, se lograron ahorros. En los servicios más costosos ahorró de media alrededor de un 3,9 por ciento de CPU por servicio; a escala de toda la flota, los costes de los sidecars se redujeron alrededor de un 30 por ciento.
Distribución uniforme de la carga
Un agregador debe ver todos los puntos de datos de una serie temporal para poder agregarlos. El anterior proxy propio llamado nomad lo garantizaba asignando mediante hash el par de servicio y entorno a un shard, es decir, a una parte fija del pool de agregadores. Como la carga de métricas se concentra en pocos servicios grandes, sus shards quedaban bajo carga constante.
En la nueva arquitectura, el loadbalancingexporter del OpenTelemetry Collector asume esta tarea. Con la clave de enrutamiento streamID, un hash sobre todas las características de una serie temporal, distribuye un servicio grande uniformemente por el pool, mientras cada serie temporal permanece en el mismo shard. La carga de CPU por shard pasó de picos aislados altos y réplicas inactivas a una distribución plana. Desde entonces, el pool puede reducirse fuera de las horas punta.
Agregación con la mitad del esfuerzo
La etapa de agregación acepta unos 4,8 mil millones de puntos de datos por minuto y, tras agregarlos, reenvía unos 220 millones. La mayoría de las métricas de Atlassian se presentan como deltas, es decir, como variación desde el último reporte. Ningún componente existente agregaba estos deltas como los usuarios esperan.
Por ello, Atlassian escribió el Atlassian Aggregation Processor y lo publicó como código abierto. Se basa en un componente estándar de la comunidad de OpenTelemetry, agrega los valores delta por defecto cada 60 segundos y reenvía sin cambios los demás tipos de métricas.
Con el mismo tráfico, la nueva etapa de agregación funciona con aproximadamente la mitad de CPU. Los agregadores ya no tienen que parsear el formato gostatsd, la carga se reparte de forma más uniforme y el equipo hereda las optimizaciones de la comunidad.
Entrega y siguiente paso
La entrega la realizaba hasta ahora un forwarder interno de desarrollo propio. Hoy funciona como una distribución del Collector sin estado llamada metrics-gateway, que reparte los datos a SignalFx, S3 y otros backends. Los reintentos, las colas y la limitación de tasa ante sobrecarga vienen de serie con el Collector.
Para las funciones serverless, donde no puede ejecutarse un sidecar, una extensión Lambda de OTel de desarrollo propio sustituye a la extensión de gostatsd. Conserva la dirección StatsD y las variables de entorno, sin necesidad de cambios en el código.
Los antiguos agregadores de gostatsd y el proxy nomad siguen funcionando por ahora. Entre ambos representan todavía alrededor del 38 por ciento de las solicitudes de CPU en los clústeres de métricas; nomad por sí solo, cerca del 13 por ciento de los recursos totales. Tras su desmantelamiento, el pipeline funcionará íntegramente sobre OpenTelemetry.
Iris Grace Endozo, Farzad Vazirnia y Albert Kerr, de Atlassian, ven como siguiente paso trasladar la instrumentación al SDK de OpenTelemetry. Hasta ahora, los servicios están instrumentados mediante librerías cliente de proveedores y de desarrollo propio, es decir, con puntos de medición en el código, entre ellos DogStatsD de Datadog y librerías StatsD.
Preguntas frecuentes
¿Qué es gostatsd en Atlassian?
gostatsd es una implementación de código abierto del protocolo StatsD mantenida por Atlassian. Solo acepta métricas por UDP y no cubre trazas ni logs. Los agregadores de gostatsd representan, junto con el proxy propio nomad, todavía alrededor del 38 por ciento de las solicitudes de CPU en los clústeres de métricas.
¿Por qué era un problema la clave de shard?
El proxy anterior asignaba mediante hash el par de servicio y entorno a un shard. Como la carga se concentra en pocos servicios grandes, precisamente sus shards quedaban bajo carga constante. La clave streamID distribuye un servicio uniformemente por el pool y mantiene cada serie temporal en el mismo shard.
¿Qué cambia para los equipos de servicios?
En la operación diaria no cambia nada: los servicios siguen enviando StatsD por UDP a la misma dirección. Para las funciones serverless, una extensión Lambda con la misma dirección y las mismas variables de entorno asume esta función. Como siguiente paso, Atlassian quiere trasladar la instrumentación al SDK de OpenTelemetry.
Selección editorial
cloudmagazinOpenTelemetry: instrumentar una vez, elegir el backend con libertadcloudmagazinRequests altos de Kubernetes pagan nodos vacíoscloudmagazinAWS deja que un agente de IA busque junto al equipo en las incidenciasFuente de la imagen: generado por IA (septiembre 2026)
Traducido del original en alemán con inteligencia artificial. La versión alemana es la de referencia.
