Este artículo describe la migración de una infraestructura de métricas a gran escala desde StatsD a OpenTelemetry (OTel) y Prometheus, utilizando vmagent para la agregación. El objetivo principal era abordar los desafíos de escalabilidad, corrección y rendimiento al adoptar una nueva solución de monitoreo, priorizando la recolección de métricas antes de la adopción generalizada de nuevas herramientas.
Inicialmente, los servicios utilizaban StatsD con un sidecar llamado Veneur para la recolección y reenvío. La nueva estrategia definió OTLP como protocolo preferido para servicios internos y Prometheus para cargas de trabajo de código abierto, manteniendo StatsD como alternativa para sistemas heredados. Se adoptó el OpenTelemetry Collector (OTel Collector) como componente central para la recolección, permitiendo una migración gradual a través de una estrategia de 'escritura dual', donde los servicios emitían métricas simultáneamente a StatsD y OTLP. Esto facilitó la adopción gradual y minimizó la interrupción.
La migración a OTLP trajo beneficios significativos, incluyendo una reducción drástica en el tiempo de CPU utilizado para el procesamiento de métricas (del 10% a menos del 1%), mayor fiabilidad y la capacidad de utilizar histogramas nativos de Prometheus. Sin embargo, se identificó un problema de rendimiento con servicios de alto volumen que emitían métricas de alta cardinalidad, lo que provocó problemas de memoria. Para mitigar esto, se implementó la 'temporariedad delta' en la configuración de la biblioteca de métricas para estos servicios, reduciendo la carga de memoria en proceso.
Finalmente, se implementó vmagent, una herramienta de VictoriaMetrics, para la agregación de métricas, evitando la necesidad de almacenar datos sin procesar y reduciendo los costos. Se configuraron dos capas de vmagent: routers (sin estado) y agregadores (con estado). La arquitectura resultante integra OTLP como flujo de datos principal, con StatsD como respaldo, y vmagent para la agregación, creando una infraestructura de monitoreo escalable y preparada para el futuro. La elección de vmagent se basó en su soporte para agregación de streaming, escalabilidad horizontal, documentación clara y un código base relativamente pequeño.