Atlassian reconstruye su pipeline de métricas sobre OpenTelemetry a escala de 100.000 hosts
La compañía mantiene la interfaz StatsD sobre UDP y reescribe todo lo de detrás con distribuciones del Collector, con un 96% menos de puntos almacenados.
Atlassian ha explicado cómo sustituyó gostatsd por OpenTelemetry en el pipeline de métricas que recibe datos de unos 100.000 hosts repartidos en 14 regiones. El servicio anterior sostenía un SLO del 99,95%, así que la migración tenía que ocurrir sin romper las alertas que dependen de esas métricas. El relato lo firman Iris Grace Endozo, Farzad Vazirnia y Albert Kerr en el blog de la CNCF.
El motivo no es que gostatsd fallara: funcionó durante años. El problema es que solo habla UDP y no sirve para trazas ni logs, y cada vez más servicios emitían ya datos en formato OpenTelemetry. Seguir con la herramienta vieja obligaba a reimplementar lo que la comunidad del Collector ya estaba construyendo. Así que no pidieron a miles de servicios que migraran al SDK: mantuvieron la interfaz StatsD sobre UDP y reconstruyeron lo de detrás. "Mantuvimos la interfaz y reconstruimos todo detrás de ella, lo que convirtió una migración de toda la organización en una migración del equipo de plataforma".
Cuatro etapas separadas
Atlassian montó distribuciones del Collector a medida para cuatro fases: recolección, ingesta, agregación y reenvío. Es el modelo de pipeline del Collector, con receptores que aceptan datos, procesadores que los modifican y exportadores que los envían a uno o varios destinos.
En la recolección, el sidecar de gostatsd se cambió por la distribución del Collector que ya usaba el equipo de trazas. Las aplicaciones siguen enviando paquetes StatsD a la misma dirección, y un receptor OTLP deja que los servicios nuevos manden métricas nativas. Meter las métricas en el sidecar de trazas ahorró de media un 3,9% de CPU en cada uno de los servicios Micros más caros y recortó el coste de los sidecars alrededor de un 30% en toda la flota. Para serverless hay una extensión Lambda que conserva la interfaz.
La ingesta era más delicada porque la agregación tiene estado: todos los puntos de una serie temporal deben acabar en el mismo agregador. El antiguo proxy nomad hacía hash por servicio y entorno contra un shard, lo que apelotonaba los servicios grandes en unas pocas réplicas. El sistema nuevo usa el exportador de balanceo de carga de opentelemetry-contrib y hace hash por stream ID: cada serie se mantiene junta y un servicio grande se reparte por todo el grupo. Atlassian reporta CPU más repartida, menos shards calientes y mejor escalado fuera de horas punta.
Dónde está el ahorro
La agregación se lleva el mayor recorte de volumen: la plataforma recibe unos 4.800 millones de puntos por minuto y almacena unos 220 millones, un 96% menos. Como los componentes upstream no agregaban métricas delta como la empresa necesitaba, Atlassian escribió su propio procesador de agregación y lo publicó en GitHub. Esa etapa consume la mitad de CPU para el mismo tráfico. "El perfilado continuo en producción es lo que de verdad nos dijo dónde optimizar", resumen los autores.
La última pieza es metrics-gateway, una distribución del Collector sin estado que sustituye a un servicio de reenvío propio. Los exportadores reparten datos a destinos como SignalFx y S3, y el Collector aporta reintentos, colas y backpressure. Añadir un destino es ahora un cambio de configuración.
En lo operativo empezaron por desarrollo y staging, eligieron primeros adoptantes con algo que ganar y subieron por tramos del 1%, 10%, 50% y 100%. Recomiendan mantener los flujos conocidos mientras conviven los dos sistemas y perfilar bajo carga real, no con pruebas pequeñas. La agregación de gostatsd y nomad todavía suponen cerca del 38% de las peticiones de CPU en sus clústeres de métricas, y nomad solo alrededor del 13%. Retirarlos cerrará el pipeline de punta a punta; después queda mover la instrumentación de StatsD, DogStatsD y clientes de proveedor al SDK.
No es el único camino. Airbnb emitió en paralelo desde una librería común y eligió vmagent de VictoriaMetrics para la agregación en streaming, con más de 100 millones de muestras por segundo. Skyscanner estandarizó instrumentación y transporte sobre OpenTelemetry y movió más de 300 microservicios actualizando una librería compartida. Atlassian optó por la capa de compatibilidad. Iwahori, de GREE, calificó el enfoque de bien pensado y valoró el enrutado por stream ID y el procesador delta propio, aunque preguntó cómo escala una capa de agregación con estado; la respuesta apunta a configuración manual.
