A monitoring system for collecting and aggregating metrics from distributed clouds

Este artículo presenta el diseño e implementación de un sistema de monitoreo que recopila, persiste y agrega métricas de múltiples niveles desde nubes distribuidas hacia su plano de control, ofreciendo acceso a través de diversas APIs para garantizar la observabilidad necesaria en este modelo de nube.

Lo esencial

Imagina que el "Cloud" (la nube) tradicional es como una gigantesca central eléctrica en una ciudad lejana. Todos los electrodomésticos de tu casa (tus aplicaciones) dependen de esa única central. Si hay un corte de luz o la central está muy lejos, tus luces parpadean o se apagan. Además, si quieres controlar tus luces en tiempo real, la señal tarda demasiado en viajar hasta la central y volver.

Para solucionar esto, nació el concepto de Nube Distribuida (DC). En lugar de una sola central, tienes pequeñas subestaciones eléctricas que aparecen y desaparecen donde las necesitas: en tu fábrica, en tu coche autónomo o en tu casa. Son flexibles, rápidas y están cerca de ti.

Pero, aquí surge el problema: ¿Cómo sabes si esas subestaciones temporales están funcionando bien? Si una se apaga y nadie se da cuenta, tus luces se quedan oscuras.

Aquí es donde entra el sistema de monitoreo que describen los autores de este paper. Vamos a explicarlo con una analogía sencilla:

1. El Sistema de "Ojos y Orejas" (Los Agentes)

Imagina que cada nodo (cada computadora o servidor en esa subestación temporal) tiene un pequeño inspector (llamado Agente).

• Qué hace el inspector: Este inspector tiene tres tipos de lentes:
  1. Lente de Hardware: Mira si el motor de la máquina está caliente, si la batería está baja o si el procesador está sudando.
  2. Lente de Contenedores: Mira las "cajas" donde viven tus programas (como si fueran apartamentos dentro de un edificio) para ver si están ocupados o vacíos.
  3. Lente de Aplicaciones: Escucha lo que tus programas específicos le dicen al inspector. Por ejemplo, si una app dice "¡Estoy procesando muchas fotos!", el inspector lo anota.

2. El "Buzón de Salud" (El Protocolo de Chequeo)

En lugar de que el inspector corra a la oficina central cada vez que ve algo, hay una regla inteligente: El Buzón de Salud.

• La oficina central (el Plano de Control) envía un mensaje periódico: "¿Estás vivo?".
• El inspector responde: "¡Sí, estoy vivo! Y aquí tienes los últimos datos que anoté en mi libreta".
• El truco: El inspector envía los datos pegados a la respuesta de "estoy vivo". Así no hacen falta dos viajes, solo uno.
• El riesgo: Si el inspector envía los datos y la oficina central se cae antes de guardarlos, esos datos se pierden. Pero los autores decidieron que es mejor perder un poco de información que llenar de basura el disco duro de las máquinas pequeñas, que tienen poco espacio.

3. La Oficina Central y el "Resumen Ejecutivo" (Agregación)

Una vez que la oficina central recibe todos los informes de los inspectores, hace dos cosas:

1. Guarda todo: Crea un archivo histórico de cómo funcionó todo.
2. Hace un resumen: Si tienes 100 subestaciones, no quieres ver 100 informes separados. El sistema suma o promedia los datos para decirte: "La subestación de la fábrica tiene un 80% de capacidad libre en total". Esto es vital para tomar decisiones rápidas.

4. ¿Quién usa esta información? (Los Clientes)

Este sistema no es solo para que los ingenieros miren gráficos bonitos. Es como un servicio de noticias en tiempo real para diferentes personas:

• El Jefe de la Nube: Quiere saber si su infraestructura está sana.
• El Programador de Tareas: Si ve que una subestación está saturada, mueve las tareas a otra que esté libre.
• El Robot de Automatización: Si ve que la temperatura sube, enciende ventiladores automáticamente.
• La Inteligencia Artificial: Usa todos esos datos históricos para aprender y predecir fallos en el futuro.

5. ¿Cómo se entrega la información?

El sistema ofrece dos formas de recibir las noticias:

• La Carta (API REST): Pides un reporte de lo que pasó entre las 2:00 y las 3:00 PM. Te lo dan en un papel (datos estáticos).
• La Radio en Vivo (API de Streaming): Te conectas a una frecuencia y escuchas los datos en tiempo real. Ideal para tableros de control que se actualizan segundo a segundo.

En resumen

Los autores crearon un sistema de vigilancia ligero y flexible para estas "nubes temporales". Funciona como un equipo de inspectores que reportan a una central, permitiendo que la tecnología sea tan dinámica como las necesidades del mundo real, sin quedarse ciega ante los fallos.

¿Por qué es importante?
Porque sin este sistema, las nubes distribuidas serían como un ejército de robots sin comunicación: rápidos y potentes, pero incapaces de coordinarse o saber si están funcionando bien. Este sistema les da la "conciencia situacional" necesaria para sobrevivir en el mundo real.

Resumen técnico

Aquí tienes un resumen técnico detallado del artículo en español, estructurado según los puntos solicitados:

Título del Sistema: Sistema de Monitoreo para la Recolección y Agregación de Métricas en Nubes Distribuidas

1. Problema

La evolución de las aplicaciones modernas, que requieren procesamiento en tiempo real de grandes volúmenes de datos, ha hecho que los centros de datos centralizados tradicionales sean ineficientes o inviables. Esto ha dado lugar al modelo de Nube Distribuida (DC), donde los usuarios crean y descartan dinámicamente nubes ad-hoc con recursos ubicados estratégicamente.

El problema central abordado es la falta de observabilidad nativa en este modelo. Los sistemas de monitoreo existentes (como Prometheus o soluciones específicas de Kubernetes) no están diseñados para las fluctuaciones constantes de los DCs (nodos uniéndose y abandonando frecuentemente), ni para las limitaciones de recursos de los dispositivos de borde. Además, se necesita una solución que proporcione visibilidad a múltiples niveles (máquina, contenedor y aplicación) y que permita la agregación de datos para una visión global del estado del sistema, algo crítico para planificadores de carga, escaladores automáticos y usuarios finales.

2. Metodología

Los autores proponen el diseño e implementación de un sistema de monitoreo nativo para DCs, integrado en la plataforma de código abierto Constellations (c12s). La arquitectura se divide en dos entornos principales:

• En los Nodos (Agentes):

  • Se implementan colectores a nivel de máquina (usando Node Exporter y Windows Exporter) y a nivel de contenedor (usando cAdvisor).
  • Un Agente de Métricas (Starometry) se encarga de recopilar datos de todos los niveles, incluyendo métricas personalizadas de aplicaciones definidas por el usuario.
  • El agente almacena temporalmente los datos en el sistema de archivos del nodo.
  • Protocolo de Transferencia: En lugar de un modelo de "pull" tradicional, se utiliza un modelo de "push" basado en el protocolo de comprobación de estado (health-check). Cuando un nodo responde a un ping del plano de control, adjunta las métricas recopiladas desde la última comunicación. Esto reduce la cantidad de solicitudes de red.

• En el Plano de Control (Control Plane):

  • Procesador: Recibe las métricas de los nodos, verifica la salud de la piscina de nodos y realiza la agregación de métricas de máquina a nivel de DC (calculando sumas o promedios globales).
  • Almacenamiento: Utiliza Prometheus como base de datos de series temporales, garantizando el soporte nativo del formato OpenMetrics.
  • Lector (Reader): Expone las métricas a los clientes mediante dos interfaces:
    1. API REST: Para consultas históricas y específicas (por nodo, DC, contenedor o aplicación).
    2. API de Streaming (basada en NATS): Permite a los clientes suscribirse a temas específicos (ej. metrics.dc.X o metrics.nodes.*) para recibir actualizaciones en tiempo real, crucial para dashboards y escalado automático.

3. Contribuciones Clave

• Arquitectura Nativa para DC: Diseño de un sistema que soporta la naturaleza dinámica y efímera de las nubes distribuidas, manejando la entrada y salida constante de nodos.
• Multinivel de Observabilidad: Capacidad de recolectar y correlacionar métricas desde el hardware (máquina), pasando por el entorno aislado (contenedores), hasta la lógica de negocio (aplicaciones personalizadas).
• Agregación Jerárquica: Implementación de una estrategia que no solo muestra el estado individual de los nodos, sino que agrega métricas clave para ofrecer una vista consolidada de todo el DC.
• Optimización de Recursos: Uso de un protocolo de "piggybacking" (transportar datos en el tráfico de salud) para minimizar la sobrecarga de red y el consumo de recursos en nodos limitados.
• Implementación Funcional: Desarrollo completo en lenguaje Go, integrado en la plataforma Constellations, utilizando tecnologías estándar de la industria (NATS, Prometheus, cAdvisor).

4. Resultados

• Validación en Laboratorio: El sistema ha sido probado exitosamente en condiciones de laboratorio con nodos simulados en máquinas virtuales, demostrando la capacidad de recolectar, almacenar y servir métricas a través de las APIs REST y de Streaming.
• Flexibilidad: El sistema permite a los usuarios definir sus propias métricas de aplicación sin restricciones, siempre que implementen la API acordada.
• Interoperabilidad: Al adherirse al estándar OpenMetrics, el sistema facilita la integración con herramientas de monitoreo y análisis de datos existentes.
• Limitaciones Identificadas: Se reconoce que la arquitectura actual es centralizada (depende del plano de control), lo que podría causar cuellos de botella en DCs masivos (miles de nodos). También se admite una posible pérdida de datos si el plano de control falla al persistir los datos antes de que el nodo los borre de su almacenamiento temporal.

5. Significado e Impacto

Este trabajo es fundamental para la viabilidad de la Nube Distribuida en escenarios del mundo real. Sin una observabilidad robusta, es imposible gestionar, depurar o escalar automáticamente infraestructuras dinámicas y heterogéneas.

• Habilitador de Automatización: Proporciona los datos necesarios para que los planificadores de carga y los escaladores automáticos tomen decisiones informadas en tiempo real.
• Soporte para IA/ML: La capacidad de exportar grandes conjuntos de datos históricos permite utilizar las métricas como conjuntos de entrenamiento para modelos de aprendizaje automático orientados a la optimización de infraestructuras.
• Futuro: Los autores planean evolucionar hacia una arquitectura más descentralizada (redes peer-to-peer dentro del DC) para escalar a miles de nodos, implementar estrategias de compresión y muestreo dinámico (pérdida controlada de datos) para reducir el almacenamiento, y desarrollar mecanismos de alerta avanzados.

En resumen, el artículo presenta una solución práctica y modular que cierra la brecha entre la teoría de las nubes distribuidas y la necesidad operativa de monitoreo, sentando las bases para infraestructuras de computación más resilientes y eficientes.