Introducción
Monitorizar aplicaciones y servicios en entornos distribuidos como Kubernetes o EC2 siempre implicó un trade-off: usar Prometheus para su flexibilidad y query language (PromQL) o migrar a soluciones nativas de cloud para simplificar la operación. Hasta ahora, integrar Prometheus con Amazon CloudWatch requería deployar, escalar y mantener un OpenTelemetry Collector autogestionado, lo que añadía complejidad operativa, costos de infraestructura y riesgo de fallas en la recolección de métricas.
Qué ocurrió
Amazon CloudWatch incorporó colectores gestionados para Prometheus, una funcionalidad que elimina la necesidad de administrar agentes. AWS se encarga del provisionamiento, escalado y recolección de métricas, entregándolas en formato OpenTelemetry (OTLP). Las métricas pueden consultarse con PromQL junto a las métricas nativas de AWS, centralizando alarmas, dashboards y correlación entre servicios.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para los equipos de DevOps e infraestructura, este cambio reduce la sobrecarga operativa. Ya no es necesario mantener un OpenTelemetry Collector en EC2 o Kubernetes (con su respectivo escalado, actualizaciones y configuración de service discovery). Esto es especialmente relevante en entornos con EKS: según el Cluster Operations Survey 2023 de the CNCF, el 46% de los usuarios de Kubernetes en producción gestionan entre 10 y 100 clusters, y el 25% maneja más de 100. Multiplicar collectors autogestionados en estos escenarios incrementa costos y riesgo de inconsistencias.
Para seguridad, centralizar las métricas en CloudWatch simplifica la detección de anomalías. Por ejemplo, métricas de memoria o CPU inusuales en un pod de EKS pueden integrarse con CloudWatch Alarm para triggerear respuestas automáticas (como escalar Horizontal Pod Autoscaler o notificar al equipo). Además, al usar el endpoint OTLP de CloudWatch (no agentes locales), se reduce la superficie de ataque asociada a mantener software adicional en los nodes.
En el plano cloud, la integración nativa con servicios como Amazon MSK (Kafka) y OpenSearch permite monitorear métricas críticas (lag de consumidores, latencia de indexación) sin configuraciones manuales. AWS genera dashboards automáticos para estos servicios, acortando el time-to-insight.
Detalles técnicos
Los colectores gestionados soportan cuatro mecanismos de discovery, según el entorno:
- Kubernetes service discovery: Autodetección de pods en clusters de EKS (versiones 1.20+). El collector detecta automáticamente los endpoints de métricas expuestos en PodMonitor, ServiceMonitor o rules de Prometheus.
- DNS-based service discovery: Vía AWS Cloud Map, útil para servicios en ECS con discovery de servicios habilitado.
- Direct instance scraping: Escaneo directo de instancias EC2 (Linux/Windows) que exponen un endpoint de métricas (puerto 9090 por defecto).
- Open monitoring endpoints: Métricas expuestas por Amazon MSK (versiones 2.1+), OpenSearch Service (versiones 1.0+) y otros servicios con endpoints Prometheus compatibles.
Las métricas se ingieren en CloudWatch como métricas de OpenTelemetry, con los siguientes límites:
- Retención: 15 meses ( igual que las métricas nativas de CloudWatch).
- Resolución: 1 segundo (para EKS, EC2) o el intervalo de scrape configurado (mínimo 15 segundos).
- Cardinalidad: Hasta 100 dimension combinations por métrica (límite de CloudWatch).
El collector gestiónado soporta:
- PromQL para consultas en el CloudWatch Metrics Explorer.
- Alarmas basadas en expresiones PromQL.
- Grafana (via Amazon Managed Service for Grafana) con CloudWatch como datasource.
La funcionalidad está disponible en todas las regiones donde existe el endpoint OTLP de CloudWatch, excepto Asia Pacific (New Zealand). El costo es por hora de collector (USD 0.20/hora por collector) + el cargo estándar de ingestion de métricas OpenTelemetry (USD 0.50 por millón de métricas).
Qué deberían hacer los administradores y equipos técnicos
- Evaluar la migración:
– Priorizar clusters de EKS, instancias EC2 critiques o servicios MSK/OpenSearch donde el overhead operativo sea mayor.
- Configurar un collector gestiónado:
– Definir el scrape configuration en YAML. Ejemplo para EKS:
scrape_configs:
- job_name: eksservice-discovery
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_scrape]
action: keep
regex: true
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_port]
action: replace
target_label: __address__
regex: (\d+)
replacement: ${1}
– Asociar el collector a un IAM role con permisos para descubrir recursos (ej: eks:DescribeCluster para EKS, ec2:DescribeInstances para EC2).
- Validar y ajustar:
Prometheus).– Ajustar el scrape_interval (default: 60s) según la latencia aceptable.
– Configurar alarmas con expresiones PromQL. Ejemplo para CPU > 80% en un pod:
(sum(rate(pod_cpu_usage_seconds_total{job="eksservice-discovery", namespace="mi-app"}[5m])) by (pod) / sum(rate(pod_cpu_limit_seconds_total{job="eksservice-discovery", namespace="mi-app"}[5m])) by (pod)) * 100 > 80
- Optimizar costos:
relabel_configs (ej: dropear labels como pod si no son necesarios).– Usar metric_relabel_configs para filtrar métricas irrelevantes antes de ingestión.
- Descomisionar recursos obsoleto:
– Eliminar permisos IAM y security groups asociados a los collectors antiguos.
Conclusión
Los colectores gestionados de CloudWatch para Prometheus cerrán una brecha importante en el monitoreo de workloads en AWS. Al eliminar la necesidad de mantener infraestructura de recolección, permiten que los equipos se enfoquen en definir qué monitorear (no cómo monitorear). La integración nativa con EKS, EC2 y servicios managed como MSK y OpenSearch, junto con el soporte para PromQL, ofrece una experiencia unificada sin sacrificar la flexibilidad de Prometheus. Para entornos a escala, el ahorro en tiempo operativo justifica el costo adicional, especialmente si ya se usan CloudWatch para métricas nativas.