Cloud19 de mayo de 2026, 8:00 a. m.Lectura 3 min

El error común al conectar CloudWatch con OpenTelemetry ⚠️

La observabilidad no debería ser un impuesto al crecimiento de tu infraestructura. Muchos equipos cometen el error de quedarse en modelos de monitoreo basados en 'pull' (como Prometheus), enfrentando throttling de APIs,

Artículo

Una lectura sobre tecnología y sistemas digitales, escrita para ir al punto y dejar claras las ideas principales.

Tema principal

cloud computing

Fuente

dev.to

Puntos clave

  • La observabilidad no debería ser un impuesto al crecimiento de tu infraestructura.
  • Muchos equipos cometen el error de quedarse en modelos de monitoreo basados en 'pull' (como Prometheus), enfrentando throttling de APIs, gaps de datos y costos disparados cuando la escala aumenta.
  • El verdadero reto surge cuando quieres usar OpenTelemetry (OTel) para evitar el vendor lock-in, pero tus políticas de seguridad exigen que los colectores vivan dentro de una VPC privada.
  • Aquí es donde la arquitectura estándar falla: Amazon Data Firehose no entrega datos directamente a endpoints privados.
01

Bloque 1

La observabilidad no debería ser un impuesto al crecimiento de tu infraestructura.

Muchos equipos cometen el error de quedarse en modelos de monitoreo basados en 'pull' (como Prometheus), enfrentando throttling de APIs, gaps de datos y costos disparados cuando la escala aumenta.

02

Bloque 2

El verdadero reto surge cuando quieres usar OpenTelemetry (OTel) para evitar el vendor lock-in, pero tus políticas de seguridad exigen que los colectores vivan dentro de una VPC privada.

Aquí es donde la arquitectura estándar falla: Amazon Data Firehose no entrega datos directamente a endpoints privados.

03

Bloque 3

La solución técnica para romper este bloqueo:

• CloudWatch Metric Streams: Cambiamos el modelo a 'push' para obtener latencia sub-minuto sin saturar APIs. • Lambda como Puente: Implementamos una función de transformación en Firehose que actúa como proxy seguro hacia la VPC. • Network Load Balancer (NLB): Distribuye el tráfico de métricas hacia los colectores OTel de forma eficiente. • OpenTelemetry Collector: Estandariza la telemetría y permite enviar los datos a cualquier backend (Grafana, Honeycomb, X-Ray) sin cambiar el código.

04

Bloque 4

Resultado: Reducción de costos de licenciamiento, eliminación de cuellos de botella y una arquitectura agnóstica al proveedor.

¿Ustedes siguen usando el modelo pull o ya migraron a arquitecturas push para su observabilidad?