Amazon EMR on EKS incorpora agente de diagnóstico para Apache Spark con IA

PorGustavo

Jul 10, 2026 #AWS, #Cloud

Introducción

Los equipos de Data Engineering que corren cargas de trabajo de Apache Spark en Amazon EMR sobre EKS enfrentaban un problema recurrente: cuando un job fallaba, la única opción era bucear manualmente entre logs distribuidos, métricas de Spark History Server y configuraciones de clúster para identificar la causa. Esto no solo consumía horas de ingeniería, sino que retrasaba la resolución en entornos donde los jobs pueden procesar terabytes de datos y miles de ejecutores. En julio de 2025, AWS lanzó el agente de troubleshooting con IA para Apache Spark en EMR on EKS, que automatiza el análisis de fallos y propone soluciones en lenguaje natural.

El agente no reemplaza las herramientas tradicionales, sino que las complementa con un enfoque basado en IA. En lugar de exigir a los ingenieros que interpreten archivos de log como spark-executor-*.log o que revisen manualmente el Spark UI, el sistema analiza automáticamente:

Datos del Spark History Server (versión 3.5.0 como mínimo).
Logs de ejecutores distribuidos almacenados en Amazon CloudWatch Logs.
Configuraciones del clúster (CPU, memoria, networking, IAM roles).
Eventos de Kubernetes (pods en CrashLoopBackOff, limitaciones de recursos, errores de red).

Qué ocurrió

El 15 de julio de 2025, AWS anunció la disponibilidad general del agente de troubleshooting con IA para Apache Spark en EMR on EKS. Esta funcionalidad ya existía en EMR on EC2 y EMR Serverless, pero su integración a EMR on EKS cierra una brecha crítica: los jobs de Spark en Kubernetes suelen ser más efímeros y complejos de depurar debido a la naturaleza dinámica de los pods y la orquestación con EKS.

El agente se activa desde la consola de EMR on EKS al seleccionar la opción «Troubleshoot with AI» en un job fallido. Internamente, el sistema:

Recopila datos del job fallido (ID del job, timestamp, versión de Spark).
Consulta el Spark History Server para obtener métricas como duration, task failures, y shuffle read/write.
Analiza logs de ejecutores en CloudWatch Logs (filtrando por patrones como OutOfMemoryError o Task not serializable).
Evalúa configuraciones del clúster (límites de CPU/memoria en los pods de Spark, políticas de IAM, políticas de red de EKS).
Genera un informe con:

– Causa raíz (ej: «OOM en ejecutores debido a spark.executor.memory=8g con 4 pods por nodo»).

– Recomendaciones en PySpark (ej: ajustar spark.executor.memoryOverhead a 2g, reducir spark.sql.shuffle.partitions a 200).

– Acciones inmediatas (ej: «Reiniciar pods con kubectl delete pod <pod-name>«).

El agente usa modelos de lenguaje entrenados específicamente para Spark, lo que reduce falsos positivos en diagnósticos comunes como:

Data skew: cuando un 10% de las particiones concentran el 90% de los datos, causando cuellos de botella en reduceByKey.
Resource contention: cuando los pods de Spark compiten por CPU/memoria con otros workloads en EKS.
Connectivity failures: errores como java.net.ConnectException: Connection refused en servicios externos (S3, JDBC, Kafka) debido a políticas de seguridad mal configuradas.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps y SRE

Los equipos que operan clústeres de EMR on EKS con decenas o cientos de jobs diarios verán una reducción del 30% al 50% en el tiempo medio de resolución (MTTR) de fallos en Spark, según datos internos de AWS. Esto es crítico en entornos donde:

Los jobs pueden durar horas (ej: procesamiento de datasets de 10TB+).
Los logs distribuidos superan los 50GB por día en clústeres grandes.
La rotación de ingenieros hace que la curva de aprendizaje para diagnosticar Spark sea un cuello de botella.

Además, el agente se integra con AWS CloudTrail, lo que permite auditar:

Quién consultó el agente (vía IAM).
Qué jobs se analizaron.
Qué recomendaciones se aplicaron.

Esto es clave para cumplir con políticas de SOC 2 o ISO 27001, donde la trazabilidad de cambios en entornos de producción es obligatoria.

Para equipos de Seguridad

El agente opera con permisos de solo lectura gracias a la integración con IAM. Los roles necesarios son:

emr-containers:ListJobRuns (para listar jobs fallidos).
logs:GetLogEvents (para consultar CloudWatch Logs).
sagemaker:InvokeEndpoint (si se usa MCP con SageMaker).
eks:DescribeCluster (para verificar configuraciones de networking).

AWS recomienda aplicar el principio de least privilege y restringir estos permisos a roles específicos en lugar de usar cuentas admin. El agente no modifica configuraciones ni ejecuta acciones en el clúster; solo genera recomendaciones.

Para equipos de Cloud y Arquitectura

El agente está disponible en todas las regiones de AWS donde SageMaker Unified Studio está habilitado (28 regiones a julio de 2025). No requiere cambios en la arquitectura de EKS ni en la configuración de Spark. Los requisitos mínimos son:

EMR on EKS versión 6.14.0 o superior.
Spark versión 3.5.0 o superior.
Kubernetes versión 1.27 o superior (compatibilidad con EKS).
CloudWatch Logs configurado para logs de Spark (requiere el add-on aws-for-fluent-bit en el clúster).

Detalles técnicos

Arquitectura del agente

El agente se compone de tres módulos principales:

Recopilador (Collector):

– Se ejecuta como un pod en el clúster de EKS (namespace emr-containers).

– Usa el Kubernetes Operator for EMR para detectar jobs fallidos.

– Recopila datos via:

– Spark History Server API (endpoint /api/v1/applications/{appId}).

– CloudWatch Logs Insights (consulta con filtro: { $.message = "ERROR" } | stats count by bin(5m)).

– API de EKS (para obtener configuraciones de pods y nodos).

Analizador (Analyzer):

– Basado en modelos de lenguaje fine-tuneados con datasets de fallos comunes en Spark (ej: OOM, skew, timeouts).

– Genera un JSON estructurado con:

     {
       "root_cause": "Data skew en stage 23 (task 456789)",
       "severity": "high",
       "recommendations": [
         {"action": "set spark.sql.adaptive.enabled=true", "type": "configuration"},
         {"action": "increase spark.sql.shuffle.partitions to 400", "type": "configuration"},
         {"action": "restart pods with kubectl delete pod spark-executor-abc123", "type": "immediate"}
       ],
       "evidence": ["log: 'Task 456789 took 1200s (vs avg 45s)'", "metric: 'shuffle read 95% in 1 task'"]
     }

– Usa el Model Context Protocol (MCP) para exponer recomendaciones a herramientas de IA como:

– Kiro (cliente de MCP de Anthropic).

– Claude Code (de Anthropic).

– Cursor (editor con soporte para MCP).

Interfaz (UI/CLI):

– Consola EMR on EKS: botón «Troubleshoot with AI» al seleccionar un job fallido.

– CLI: comando aws emr-containers troubleshoot-job --job-id j-1234567890 (requiere IAM emr-containers:TroubleshootJob).

– MCP Server: despliegue como pod en EKS con el manifiesto:

     apiVersion: apps/v1
     kind: Deployment
     metadata:
       name: spark-troubleshooter-mcp
     spec:
       replicas: 1
       selector:
         matchLabels:
           app: spark-troubleshooter-mcp
       template:
         spec:
           containers:
           - name: mcp-server
             image: public.ecr.aws/aws-emr/emr-mcp-spark-troubleshooter:1.0.0
             ports:
             - containerPort: 8080
             env:
             - name: AWS_REGION
               value: "us-east-1"
             - name: EMR_CLUSTER_ID
               value: "j-1234567890"

Vectores de ataque mitigados (desde la perspectiva de Seguridad)

El agente no introduce nuevos riesgos porque:

Opera con permisos de solo lectura (IAM emr-containers:DescribeJobRuns, logs:GetLogEvents).
No modifica configuraciones ni ejecuta comandos en el clúster.
Los logs de auditoría quedan registrados en CloudTrail con eventos como:

  {
    "eventName": "DescribeJobRuns",
    "userIdentity": {"type": "IAMUser", "userName": "data-engineer-alice"},
    "resources": [{"type": "AWS::EMR::JobRun", "arn": "arn:aws:emr:us-east-1:123456789012:jobrun/j-1234567890"}]
  }

Los datos analizados se almacenan temporalmente en S3 encriptado con SSE-KMS (bucket aws-emr-troubleshooter-logs-<region>) y se eliminan tras 7 días.

Limitaciones conocidas

No soporta Spark 2.x: requiere Spark 3.5.0+ (el agente usa APIs de Spark History Server que cambiaron en la versión 3.0).
No analiza jobs en ejecución: solo jobs que ya fallaron (el agente no predice fallos).
Latencia: el análisis puede tardar 2-5 minutos en jobs con logs muy grandes (ej: 100GB de logs en CloudWatch).

Qué deberían hacer los administradores y equipos técnicos

1. Verificar requisitos previos y actualizar componentes

Antes de habilitar el agente, asegúrense de que su entorno cumpla con:

EMR on EKS versión 6.14.0+:

  aws emr-containers list-clusters --query 'clusters[?status.state==`RUNNING`].{id:id,version:releaseLabel}' | jq

Si la versión es menor a 6.14.0, actualicen con:

  aws emr-containers start-cluster-update --cluster-id j-cluster-id --release-label emr-6.14.0

Spark versión 3.5.0+: Verifiquen en el Spark UI o con:

  kubectl exec -it spark-driver-pod -- spark-submit --version | grep "version 3.5"

CloudWatch Logs configurado: Asegúrense de que los logs de Spark se envíen a CloudWatch. Si usan Fluent Bit, verifiquen la configuración en el ConfigMap:

  apiVersion: v1
  kind: ConfigMap
  metadata:
    name: fluent-bit-config
  data:
    parsers.conf: |
      [PARSER]
        Name    spark
        Format  json
    filters.conf: |
      [FILTER]
        Name    modify
        Match   *
        Rename  logMessage message

2. Configurar permisos de IAM

Cree un rol de IAM con los permisos mínimos para el agente:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "emr-containers:ListJobRuns",
        "emr-containers:DescribeJobRuns",
        "emr-containers:TroubleshootJob",
        "logs:GetLogEvents",
        "logs:FilterLogEvents",
        "eks:DescribeCluster"
      ],
      "Resource": [
        "arn:aws:emr:*:*:jobrun/*",
        "arn:aws:logs:*:*:log-group:/aws/eks/*:log-stream:*",
        "arn:aws:eks:*:*:cluster/*"
      ]
    }
  ]
}

Asigne este rol al pod del agente en el namespace emr-containers:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: emr-troubleshooter
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/emr-troubleshooter-role

3. Habilitar el agente en la consola EMR on EKS

Abran la consola de EMR on EKS.
Seleccionen el clúster donde quieren habilitar el agente.
Vayan a la pestaña «Jobs» y filtren por jobs fallidos.
Hagan clic en «Troubleshoot with AI» en el job seleccionado.
Esperen a que el agente genere el informe (puede tardar 2-5 minutos).

4. Usar el agente con MCP en herramientas de IA

Si prefieren integrar el agente con herramientas como Kiro o Cursor:

Desplieguen el servidor MCP en su clúster:

   kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-emr-mcp-spark-troubleshooter/main/deploy/mcp-server.yaml

Configuren el cliente MCP (ej: en Cursor, agreguen al archivo .cursor/settings.json):

   {
     "mcpServers": {
       "emr-spark-troubleshooter": {
         "command": "kubectl",
         "args": ["port-forward", "service/spark-troubleshooter-mcp", "8080:8080"]
       }
     }
   }

Usen comandos como:

   Analiza el job j-1234567890 y sugiere ajustes para evitar skew de datos.

5. Monitorear y auditar el uso del agente

Logs de CloudTrail: Filtren eventos con eventName igual a DescribeJobRuns o TroubleshootJob.
Métricas personalizadas: Configuren un dashboard en CloudWatch con:

  Metric: TroubleshooterJobsAnalyzed
  Dimensions: Region, ClusterId, RootCause

Alertas: Creen una alarma en CloudWatch para cuando el agente analice más de 10 jobs fallidos en una hora (posible problema de configuración recurrente).

Conclusión

El agente de troubleshooting con IA para Apache Spark en Amazon EMR on EKS es un avance significativo para equipos que operan pipelines de datos a escala. Al automatizar el análisis de fallos comunes (OOM, skew, timeouts), reduce el tiempo de resolución de horas a minutos y disminuye la dependencia de expertise manual en Spark. La integración con MCP abre la puerta a flujos de trabajo donde herramientas como Cursor o Kiro pueden sugerir ajustes directamente en el IDE, cerrando la brecha entre operaciones y desarrollo.

Para equipos con decenas de jobs diarios, la recomendación es habilitar el agente inmediatamente en entornos de staging y producción, priorizando jobs críticos. La configuración es mínima (solo requiere permisos de IAM y actualización a EMR 6.14.0+), y el ROI se ve en la reducción de MTTR, especialmente en entornos donde los fallos de Spark son frecuentes y difíciles de diagnosticar.