Atlassian reconstruyó su plataforma de métricas en torno a OpenTelemetry Collector sin exigir inicialmente a los equipos de servicios que cambiaran la forma en que enviaban las métricas. En lugar de eliminar la canalización antigua y reconfigurar después miles de servicios, la empresa mantuvo la interfaz StatsD sobre UDP y sustituyó gradualmente las capas de agregación, procesamiento y enrutamiento que había detrás.
Durante la mayor parte de la última década, la plataforma anterior dependió de gostatsd, una aplicación StatsD de código abierto desarrollada por Atlassian, que funcionaba como agente lateral en los hosts y como capa de agregación en el extremo receptor. La plataforma gestionaba métricas procedentes de unos 100.000 hosts distribuidos en 14 regiones, conforme a un objetivo de nivel de servicio del 99,95 % y con baja latencia.
Cambiar el motor manteniendo estable el contrato
Los equipos de Atlassian consideraron que reconfigurar cada servicio para utilizar el SDK de OpenTelemetry antes de cambiar la infraestructura sería un proceso de varios años y conllevaría el riesgo de perder los datos de los que dependían las alertas. Por ello, separaron la interfaz de la plataforma de sus componentes internos: los servicios continuaron comunicándose con la misma dirección y en formato StatsD, mientras que las capas internas fueron sustituidas gradualmente por distribuciones personalizadas de OpenTelemetry Collector.
El diseño adoptó cuatro etapas independientes: recopilación, recepción, agregación y enrutamiento. Además, la capa de recopilación se hizo capaz de recibir StatsD y OTLP simultáneamente. Así fue posible iniciar la migración sin obligar a los equipos a cambiar las bibliotecas cliente, al tiempo que se abría el camino a las métricas creadas originalmente con OpenTelemetry.
¿Qué cambió en la práctica?
En la etapa de recopilación, el agente lateral gostatsd fue sustituido por una distribución de OpenTelemetry Collector que el equipo de trazas ya utilizaba, manteniendo el comportamiento anterior de las aplicaciones. Esto permitió combinar las métricas y las trazas en un único agente lateral, en lugar de ejecutar dos agentes en cada host.
Atlassian afirma que esta integración redujo el consumo de CPU una media aproximada del 3,9 % por servicio entre los servicios Micros de mayor coste, lo que equivale a una reducción cercana al 30 % en el coste de los agentes laterales en toda la flota. También se añadió un receptor OTLP para que la capa de recopilación pudiera recibir métricas de OpenTelemetry y reenviarlas directamente.
En la etapa de recepción, el problema principal estaba relacionado con el estado de las series temporales. Cada punto de datos perteneciente a una misma serie debía enviarse a un único agregador. El sistema antiguo, mediante un agente interno llamado nomad, utilizaba una partición basada en el par servicio-entorno. Sin embargo, las diferencias en el tamaño de los servicios provocaban la aparición de agregadores sobrecargados y otros infrautilizados.
Atlassian solucionó esto utilizando el componente loadbalancingexporter del repositorio de OpenTelemetry, con partición basada en streamID, es decir, la identidad de cada serie temporal individual. Este método permitió distribuir los datos de los servicios grandes entre el conjunto de agregadores, manteniendo cada serie en el mismo agregador. Como resultado, la distribución de CPU entre los agregadores se volvió más equilibrada, mejoró la capacidad de escalado automático y disminuyeron las alertas de carga elevada.
Reducción de datos y costes en la capa de agregación
La capa de agregación gestiona unos 4.800 millones de puntos de datos por minuto, pero solo almacena unos 220 millones, lo que supone una reducción aproximada del 96 %. Dado que la mayoría de las métricas utiliza delta temporality y que los componentes anteriores no agregaban estas diferencias de la forma esperada por los usuarios, Atlassian desarrolló un procesador específico para agregar deltas de métricas y lo publicó como código abierto bajo el ámbito atlassian-labs.
Tras la migración, la capa de agregación necesitó aproximadamente la mitad de la CPU anterior. La fuente atribuye esta mejora a varios factores, entre ellos la eliminación del análisis del formato gostatsd, una distribución de carga más eficaz y el aprovechamiento de las mejoras de la comunidad de OpenTelemetry.
En la última etapa, un enrutador interno personalizado fue sustituido por una distribución sin estado de Collector que la empresa denominó metrics-gateway. Esta distribución utiliza exportadores upstream para admitir el envío a múltiples destinos, como SignalFx y S3, junto con capacidades de reintento, colas y control de la contrapresión. Según el diseño anunciado, añadir un nuevo destino pasa a ser un cambio de configuración en lugar de un proyecto de integración independiente.
Lecciones de la migración gradual
- Empieza por los equipos adecuados: Atlassian eligió entornos de desarrollo y pruebas, así como servicios que sufrían más problemas, para obtener comentarios tempranos dentro de un ámbito menos sensible.
- Supervisa continuamente la producción: El análisis de perfiles bajo cargas de producción reveló el comportamiento y el coste de los componentes de una forma que no ofrecían las pruebas pequeñas ni las referencias sintéticas.
- Mantén la paridad operativa: Como la migración puede prolongarse durante meses o años mientras ambos sistemas funcionan en paralelo, la empresa recomendó mantener, en la medida de lo posible, las herramientas y los procedimientos operativos compartidos.
- Amplía el alcance por etapas: El despliegue siguió porcentajes graduales, comenzando por el 1 %, después el 10 % y el 50 %, hasta llegar al 100 %, probando los problemas en los servicios menos sensibles antes de abordar las rutas críticas.
¿Por qué es importante este enfoque?
La experiencia demuestra que adoptar un nuevo estándar de infraestructura no exige necesariamente cambiar las interfaces de todos los consumidores al mismo tiempo. Mantener estable el contrato externo convirtió la migración de un proyecto organizativo que involucraba a todos los equipos en un proyecto dirigido por la plataforma de infraestructura, abriendo gradualmente el camino a OTLP y a los componentes de OpenTelemetry.
Atlassian señala que gostatsd y nomad representaban conjuntamente alrededor del 38 % de las solicitudes de CPU en los clústeres de métricas, mientras que nomad por sí solo representaba aproximadamente el 13 % del total de recursos. Por tanto, el efecto de la transición no se limita a unificar las herramientas; también está relacionado con la eliminación de componentes personalizados costosos y con la reducción del número de piezas que requieren mantenimiento interno.
Sin embargo, esto no significa que la migración se haya completado en lo que respecta a la instrumentación de los servicios. El siguiente paso mencionado por la empresa es trasladar las propias herramientas de instrumentación al SDK de OpenTelemetry y abandonar gradualmente los clientes de Datadog y DogStatsD, así como las bibliotecas StatsD internas que todavía se utilizan. Asimismo, los resultados de rendimiento y las cifras presentadas aquí describen la experiencia de Atlassian en su entorno y no garantizan que los mismos valores se repitan en todas las infraestructuras de monitorización.