Amazon DEA-C01: Monitoreo y resolución de problemas de pipelines de datos — Guía de estudio

By Laurynas Brazys · 2 August 2026 · #amazon #dea-c01 #certification #exam-prep #study-guide

Forma parte de la Amazon Data Engineer Associate DEA-C01 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

La monitorización y resolución de problemas de las canalizaciones de datos es fundamental para garantizar la entrega puntual y precisa de datos de streaming y por lotes en AWS. Este dominio abarca la telemetría, las alertas y las técnicas de diagnóstico para servicios como Kinesis, Firehose, Glue, DMS, Lambda y los registros de auditoría de AWS que respaldan la investigación de incidentes. Una monitorización eficaz reduce el Tiempo Medio de Detección/Recuperación (Mean Time To Detect/Recover) al exponer el retraso del consumidor (consumer lag), la presión sobre los recursos de los trabajos, la latencia de entrega y el acceso no autorizado. Las siguientes secciones ofrecen señales concretas, patrones de CLI/consola y criterios de decisión para operar y remediar los flujos de datos de producción.

Métricas y alarmas de CloudWatch para servicios de datos

CloudWatch es el plano de telemetría principal: cree filtros de métricas, paneles (dashboards) y alarmas para las métricas clave de los servicios e integre las alarmas con SNS, EventBridge o Systems Manager para una remediación automatizada. Use

undefined

para crear alarmas programáticamente; los indicadores (flags) típicos incluyen –metric-name, –namespace, –statistic (o –extended-stat), –threshold, –evaluation-periods y –comparison-operator. Para los paneles, envíe métricas personalizadas (p. ej., desde los metadatos de un trabajo de Glue) usando

undefined

con un namespace como “MyCompany/DataPipeline”.

Céntrese en estas métricas y patrones procesables:

Glue: monitorice BytesRead, BytesWritten, RecordsProcessed y DPUHrs para detectar cambios en el volumen de datos, asimetría (skew) y costes. Alarmas: caída repentina en RecordsProcessed o picos en DPUHrs por registro.
Kinesis: monitorice GetRecords.IteratorAgeMilliseconds para el retraso del consumidor (consumer lag) e IncomingBytes/IncomingRecords para la presión en el origen.
Firehose: monitorice DeliveryToS3.DataFreshness y DeliveryToS3.Records para detectar latencia de entrega y pérdida de datos.
DMS: monitorice FullLoadRows, CDCLatencyMilliseconds y AppliedChanges para la salud de la replicación.

Criterios de decisión para las alertas:

Use alarmas compuestas (CloudWatch composite alarms) para reducir el ruido: combine IteratorAgeMilliseconds > X para 3 puntos de datos Y la tasa de error del consumidor > Y.
Para la selección de umbrales, derive líneas base a partir de datos históricos de 7 a 14 días y establezca umbrales dinámicos usando modelos de detección de anomalías (PutAnomalyDetector) cuando las cargas de trabajo sean estacionales.

Monitorización y manejo de errores en trabajos de Glue

Glue emite métricas a CloudWatch y escribe logs en /aws-glue/jobs/output (logs de ejecución del trabajo) y /aws-glue/jobs/error (errores). Use CloudWatch Logs Insights para consultar las ejecuciones de los trabajos: ejecute consultas a través de la consola o con

undefined

con una cadena de consulta como

undefined

. Rastree BytesRead, BytesWritten, RecordsProcessed y DPUHrs desde las métricas de ejecución del trabajo de Glue—DPUHrs se correlaciona directamente con el coste y el paralelismo del trabajo.

Modos de fallo comunes en Glue y su remediación:

OutOfMemory (OOM) o pérdida de Executor: aumente el tipo de trabajador/número de DPU, cambie al tipo de trabajador G.2X para un uso de memoria más intensivo, u optimice el particionamiento de Spark (repartition/coalesce) y use predicados de empuje (pushdown predicates) para reducir el volumen de entrada.
Asimetría de datos (data skew) que causa nodos rezagados (stragglers): use claves de partición para reequilibrar, aumente el paralelismo o use las opciones split/resolve de DynamicFrame de Glue cuando sea apropiado.
Trabajo atascado o arranque lento: habilite los marcadores de trabajo (job bookmarks) y monitorice “TimeWaitingForResources” en las JobMetrics de Glue para identificar la contención de capacidad.

Compromisos en la toma de decisiones:

Aumente las DPU cuando la CPU/memoria sean el cuello de botella y la previsibilidad del tiempo de ejecución sea importante; prefiera optimizaciones de código (particionamiento, caché solo cuando sea necesario) si se deben controlar los costes.
Use Glue streaming para transformaciones casi en tiempo real; use Glue ETL por lotes (batch) para transformaciones complejas de Spark y cargas de trabajo más grandes compatibles con instancias Spot.

Monitorización de Kinesis y Firehose

Retraso del consumidor de Kinesis (Consumer Lag): confíe en GetRecords.IteratorAgeMilliseconds para detectar cuán atrasados están los consumidores. Si GetRecords.IteratorAgeMilliseconds es consistentemente alto:

Escale aumentando el número de shards (reshard/scale), o
Mejore el rendimiento del consumidor mediante el procesamiento por lotes (batching), usando la distribución ramificada mejorada (enhanced fan-out) (para un rendimiento por consumidor de hasta 2 MB/seg) o la Kinesis Client Library (KCL) v2 con un sistema de puntos de control (checkpointing) mejorado.

Use

undefined

para inspeccionar el número de shards y

undefined

para IteratorAgeMilliseconds. Al comparar las opciones de remediación, considere:

Añadir shards: aumenta el rendimiento de ingesta y lectura; requiere una nueva fragmentación (resharding) y reequilibrio (rebalancing).
Enhanced fan-out: evita el rendimiento de lectura compartido pero aumenta el coste por consumidor.
Optimización del consumidor: reduce la necesidad de shards adicionales y el coste, pero requiere esfuerzo de ingeniería.

Métricas de entrega de Firehose: DeliveryToS3.DataFreshness cuantifica la latencia de entrega; los ajustes típicos de buffering_delay son de 60 a 900 segundos y retendrán los registros hasta que se alcance bufferSize o bufferInterval. Si DeliveryToS3.DataFreshness es alto:

Revise las sugerencias de búfer de Firehose (BufferIntervalInSeconds, BufferSizeInMBs) en la consola o a través de

undefined

Inspeccione los errores de CloudWatch (DeliveryToS3.RecordsFailed) y los permisos del bucket de S3 (errores de KMS si está cifrado).

Recuerde la semántica de almacenamiento en búfer (buffering) de Firehose: el servicio retrasa intencionadamente la entrega hasta el intervalo del búfer; reduzca el intervalo del búfer para disminuir la latencia a costa de escrituras más frecuentes en S3.

CloudTrail y auditoría de acceso a datos

CloudTrail proporciona actividad de API y, opcionalmente, eventos de datos para S3 y Lambda, los cuales no están habilitados por defecto. Para capturar eventos de S3 a nivel de objeto, habilite explícitamente los eventos de datos en CloudTrail a través de la consola o con aws cloudtrail create-trail --include-global-service-events y añada los recursos de datos de S3. Sin habilitar los eventos de datos de S3, no verá los eventos GetObject/PutObject en CloudTrail, lo que es una omisión común durante las investigaciones.

Use los registros de CloudTrail en combinación con CloudWatch Logs Insights para correlacionar métricas operativas (p. ej., registros de trabajos de Glue) con eventos de acceso. Patrones de consulta:

CloudWatch Logs Insights: filter @message like /GetObject/ | stats count() by userIdentity.principalId
Use reglas de EventBridge para reaccionar a llamadas de API específicas (p. ej., PutBucketAcl) y reenviarlas a SNS para obtener alertas rápidas.

Las tareas de replicación de DMS también publican métricas en CloudWatch: monitoree FullLoadRows para la completitud de la copia inicial, CDCLatencyMilliseconds para detectar la latencia de replicación, y AppliedChanges para asegurar que las transacciones se están aplicando en el destino. Cree alarmas para CDCLatencyMilliseconds cuando exceda los SLAs de negocio y para un valor bajo de AppliedChanges después de un aumento en las filas de carga completa (full load rows).

Errores Comunes y Criterios de Decisión

Un IteratorAgeMilliseconds alto en Kinesis confundido con problemas en el origen — enfoque correcto: verificar el checkpointing y el tiempo de procesamiento del consumidor; escalar añadiendo shards o usar enhanced fan-out solo después de analizar el uso de CPU/IO del consumidor.
Errores OOM en trabajos de Glue gestionados aumentando ciegamente los DPU — enfoque correcto: analizar las etapas de Spark, optimizar el particionamiento y el filtrado de datos; aumentar los DPU o el tipo de worker solo si se confirman los límites de recursos.
Retraso en el búfer de Firehose que causa una percepción de pérdida de datos — enfoque correcto: verificar BufferIntervalInSeconds y BufferSizeInMBs; reducir el intervalo para necesidades de baja latencia y aceptar mayores tasas de escritura/costo.
Asumir que CloudTrail registra las lecturas de objetos de S3 por defecto — enfoque correcto: habilitar los eventos de datos de S3 en CloudTrail para capturar GetObject/PutObject para auditorías forenses.
Falta de alarmas de latencia de CDC en DMS — enfoque correcto: crear alarmas de CloudWatch sobre CDCLatencyMilliseconds y comparar AppliedChanges vs FullLoadRows; investigar la red o el backlog de transacciones cuando la latencia aumenta.
Exceso de alertas por picos transitorios — enfoque correcto: usar evaluation-periods, datapoint-to-alarm o detección de anomalías para reducir el ruido y usar alarmas compuestas para condiciones correlacionadas.

Problema Práctico: Escenario de Caso de Uso

Acme Analytics realiza una ingesta de clickstream en tiempo real a través de Kinesis, enriquece eventos usando trabajos ETL de Glue, persiste lotes antiguos a través de Firehose en S3 y replica bases de datos heredadas con DMS. Observan retrasos de extremo a extremo: latencia del consumidor en Kinesis, errores OOM en trabajos de Glue y Firehose mostrando un valor alto en DeliveryToS3.DataFreshness.

Analizar los consumidores de Kinesis: obtener la métrica GetRecords.IteratorAgeMilliseconds, inspeccionar los registros del consumidor y realizar un análisis de costos entre Kinesis enhanced fan-out y el escalado por shards.
Examinar las métricas de CloudWatch del trabajo de Glue y Logs Insights en busca de stack traces de OOM; probar el reparticionamiento + predicado de pushdown localmente o en un trabajo más pequeño; solo entonces aumentar el DPU/tipo de worker si es necesario.
Inspeccionar la configuración del búfer de Firehose (BufferIntervalInSeconds) y DeliveryToS3.DataFreshness; reducir el intervalo del búfer para SLOs críticos y validar los permisos de escritura en S3/KMS.
Configurar alarmas compuestas de CloudWatch que combinen IteratorAgeMilliseconds, la tasa de error del trabajo de Glue y Firehose DataFreshness; entregar alertas a un tema de SNS para el personal de guardia y activar un runbook a través de EventBridge.
Habilitar los eventos de datos de S3 en CloudTrail y correlacionar los eventos GetObject/PutObject con los tiempos de inicio de los trabajos de Glue y los cambios aplicados de DMS para detectar accesos no autorizados o retrasados.

Este enfoque sigue las mejores prácticas de AWS: monitorear las métricas de servicio correctas con la granularidad adecuada, preferir correcciones de código y configuración específicas antes de escalar recursos, y asegurar que el registro a nivel de auditoría esté habilitado explícitamente para permitir un análisis rápido de la causa raíz y una remediación automatizada.

← Seguridad · Todos los dominios · Optimización de costos para cargas de trabajo de datos →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →