La adopción de arquitecturas de microservicios y la escala de la infraestructura en la nube han expuesto las limitaciones de los sistemas de monitoreo tradicionales, especialmente aquellos basados en modelos pull como Prometheus, que sufren de throttling de API, pérdida de métricas y altos costos a escala. La necesidad de observabilidad en tiempo casi real, junto con el deseo de evitar el vendor lock-in y reducir los costos de licenciamiento, ha impulsado la adopción de estándares abiertos como OpenTelemetry.
Este artículo aborda el problema fundamental de cómo integrar un sistema de métricas nativo de la nube (CloudWatch) con una solución de observabilidad de código abierto (OpenTelemetry) autoalojada dentro de un entorno de red privado (VPC), manteniendo una arquitectura push-based para eficiencia y escalabilidad. La solución propuesta resuelve la brecha de conectividad entre servicios gestionados y recursos privados, un desafío común en arquitecturas de nube híbrida o con estrictos requisitos de seguridad y soberanía de datos.
Arquitectura del Sistema
La arquitectura propuesta es un sistema de ingesta de métricas push-based que consta de cuatro componentes principales: CloudWatch Metric Streams, Amazon Data Firehose, AWS Lambda y el OpenTelemetry Collector. CloudWatch Metric Streams captura métricas en tiempo casi real y las envía a un Amazon Data Firehose stream. Data Firehose, un servicio de entrega de streaming de datos, está configurado para invocar una función AWS Lambda de forma síncrona para la transformación de datos.
Esta función Lambda actúa como un puente, recibiendo los datos de métricas en formato JSON de Firehose y empujándolos de forma segura a un endpoint privado dentro de la VPC del cliente. Este endpoint es un Network Load Balancer (NLB) que distribuye el tráfico TCP a instancias EC2 que ejecutan el OpenTelemetry Collector. El Collector, a su vez, procesa (filtrado, batching, enriquecimiento) y exporta las métricas a varios backends de observabilidad. Un bucket S3 se configura como destino redundante para Firehose, aunque no se utiliza activamente en este flujo de datos primario. La elección de un NLB en capa 4 asegura una distribución eficiente del tráfico a los colectores, que operan como contenedores en instancias EC2 dentro de una subred privada.
Flujo de Métricas de CloudWatch a OpenTelemetry en VPC
- 1 CloudWatch Metric Streams Captura métricas en tiempo casi real.
- 2 Amazon Data Firehose Recibe métricas, las bufferiza y las envía a Lambda.
- 3 AWS Lambda (Transform Function) Transforma métricas y las envía al endpoint privado.
- 4 Network Load Balancer (NLB) Distribuye tráfico TCP a colectores OpenTelemetry.
- 5 OpenTelemetry Collector (EC2) Recibe, procesa y exporta métricas a backends.
- 6 Observability Backends Almacena y visualiza métricas (ej. Grafana Cloud, Honeycomb).
| Capa | Tecnología | Justificación |
|---|---|---|
| data-processing | Amazon CloudWatch Metric Streams | Servicio de ingesta de métricas en tiempo casi real, fuente de datos. vs CloudWatch GetMetricData API (pull-based) Formato de salida JSON para métricas. |
| messaging | Amazon Data Firehose | Servicio de entrega de streaming de datos, bufferiza y enruta métricas. vs Amazon Kinesis Data Streams (requiere más gestión) Configurado para invocar AWS Lambda para transformación. |
| compute | AWS Lambda | Función de transformación y puente de red para enviar métricas a VPC privada. vs AWS PrivateLink (para Firehose a VPC, si fuera compatible directamente) Invocación síncrona por Firehose, envía a HTTP endpoint. |
| networking | Network Load Balancer (NLB) | Distribuye tráfico TCP a los colectores OpenTelemetry dentro de la VPC. vs Application Load Balancer (ALB, si se necesitara capa 7) Opera en capa 4, endpoint interno de VPC. |
| compute | Amazon EC2 | Aloja los contenedores del OpenTelemetry Collector en una subred privada. vs Amazon ECS/EKS (para orquestación de contenedores más avanzada) Instancias en subred privada dentro de VPC. |
| data-processing | OpenTelemetry Collector | Recibe, procesa (filtrado, batching, enriquecimiento) y exporta telemetría. vs Prometheus (pull-based, con exporter) Componentes: Receivers, Processors, Exporters. Garantía de entrega 'at-least-once'. |
| storage | Amazon S3 | Destino de respaldo para Data Firehose (no utilizado en el flujo principal). |
Trade-offs
Ganancias
- ▲ Latencia para alertas en tiempo real
- ▲ Costo de API calls (reducción de polling)
- ▲▲ Costo de licenciamiento de terceros
- ▲ Flexibilidad y prevención de vendor lock-in
- ▲ Pérdida de métricas por throttling
Costes
- △ Complejidad de la arquitectura (introducción de Lambda y NLB)
- △ Gestión de infraestructura (EC2 para OTel Collector)
Fundamentos Teóricos
El problema de la recolección y procesamiento de datos de monitoreo a escala se relaciona con los principios de sistemas distribuidos y procesamiento de streams. La transición de un modelo pull a un modelo push, como se describe en el artículo, refleja la evolución de los sistemas de monitoreo hacia arquitecturas basadas en eventos, que son inherentemente más escalables y eficientes para el procesamiento de datos en tiempo real. Esto se alinea con los conceptos de sistemas reactivos y arquitecturas orientadas a eventos, donde los componentes reaccionan a flujos de datos en lugar de sondear activamente el estado.
La implementación de una función Lambda para transformar y enrutar datos a un endpoint privado es un patrón común en la computación sin servidor para superar las limitaciones de conectividad de red, similar a los patrones de 'sidecar' o 'proxy' en microservicios, pero aplicado en un contexto de función como servicio. La necesidad de garantizar la entrega de datos ('at-least-once delivery') por parte del OpenTelemetry Collector es un requisito fundamental en sistemas distribuidos, abordado por algoritmos de consenso y protocolos de mensajería que aseguran la durabilidad y fiabilidad de los datos frente a fallos de red o de componentes.