Amazon DEA-C01: Monitoramento e Solução de Problemas de Pipeline de Dados — Guia de estudos

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

Faz parte do Amazon Data Engineer Associate DEA-C01 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

O monitoramento e a solução de problemas de pipelines de dados são essenciais para garantir a entrega pontual e precisa de dados de streaming e em lote na AWS. Este domínio abrange as técnicas de telemetria, alertas e diagnóstico para serviços como Kinesis, Firehose, Glue, DMS, Lambda e as trilhas de auditoria da AWS que auxiliam na investigação de incidentes. Um monitoramento eficaz reduz o Tempo Médio para Detectar/Recuperar (Mean Time To Detect/Recover) ao expor o lag do consumidor, a pressão de recursos do job, a latência de entrega e o acesso não autorizado. As seções a seguir fornecem sinais concretos, padrões de CLI/console e critérios de decisão para operar e remediar fluxos de dados de produção.

Métricas e alarmes do CloudWatch para serviços de dados

O CloudWatch é o plano de telemetria principal: crie filtros de métricas, dashboards e alarmes para as principais métricas de serviço e integre os alarmes com o SNS, EventBridge ou Systems Manager para remediação automatizada. Use aws cloudwatch put-metric-alarm para criar alarmes programaticamente; as flags típicas incluem --metric-name, --namespace, --statistic (ou --extended-stat), --threshold, --evaluation-periods e --comparison-operator. Para dashboards, envie métricas personalizadas (por exemplo, de metadados de jobs do Glue) usando aws cloudwatch put-metric-data com um namespace como “MyCompany/DataPipeline”.

Concentre-se nestas métricas e padrões acionáveis:

• Glue: monitore BytesRead, BytesWritten, RecordsProcessed e DPUHrs para detectar mudanças no volume de dados, assimetria (skew) e custo. Alarmes: queda repentina em RecordsProcessed ou picos em DPUHrs por registro.
• Kinesis: monitore GetRecords.IteratorAgeMilliseconds para o lag do consumidor e IncomingBytes/IncomingRecords para a pressão na origem.
• Firehose: monitore DeliveryToS3.DataFreshness e DeliveryToS3.Records para identificar latência de entrega e perda de dados.
• DMS: monitore FullLoadRows, CDCLatencyMilliseconds e AppliedChanges para a saúde da replicação.

Critérios de decisão para alertas:

• Use alarmes compostos (CloudWatch composite alarms) para reduzir o ruído: combine IteratorAgeMilliseconds > X para 3 pontos de dados E taxa de erro do consumidor > Y.
• Para a seleção de limiares, derive baselines de dados históricos de 7 a 14 dias e defina limiares dinâmicos usando modelos de detecção de anomalias (PutAnomalyDetector) quando as cargas de trabalho forem sazonais.

Monitoramento e tratamento de erros em jobs do Glue

O Glue emite métricas para o CloudWatch e grava logs em /aws-glue/jobs/output (logs de execução do job) e /aws-glue/jobs/error (erros). Use o CloudWatch Logs Insights para consultar as execuções dos jobs: execute consultas pelo console ou com aws logs start-query com uma string de consulta como fields @timestamp, @message | filter @message like /ERROR/ | sort @timestamp desc | limit 20. Acompanhe BytesRead, BytesWritten, RecordsProcessed e DPUHrs a partir das métricas de execução do job do Glue — DPUHrs se correlaciona diretamente com o custo e o paralelismo do job.

Modos de falha comuns do Glue e remediação:

• OutOfMemory (OOM) ou Executor lost: aumente o tipo de worker/contagem de DPUs, mude para o tipo de worker G.2X para maior consumo de memória, ou otimize o particionamento do Spark (repartition/coalesce) e use predicados pushdown para reduzir o volume de entrada.
• Assimetria de dados (skew) causando ‘stragglers’ (processos lentos): use chaves de partição para rebalancear, aumente o paralelismo ou use as opções split/resolve do DynamicFrame do Glue quando apropriado.
• Job travado ou inicialização longa: habilite os job bookmarks e monitore as Glue JobMetrics em busca de “TimeWaitingForResources” para identificar contenção de capacidade.

Trade-offs de decisão:

• Aumente as DPUs quando CPU/memória forem o gargalo e a previsibilidade do tempo de execução for importante; prefira otimizações de código (particionamento, cache apenas quando necessário) se os custos precisarem ser controlados.
• Use o Glue streaming para transformações quase em tempo real (near-real-time); use o Glue ETL em lote para transformações Spark complexas e cargas de trabalho maiores compatíveis com instâncias Spot.

Monitoramento do Kinesis e do Firehose

Lag do Consumidor do Kinesis: confie em GetRecords.IteratorAgeMilliseconds para detectar o quão atrasados os consumidores estão. Se GetRecords.IteratorAgeMilliseconds estiver consistentemente alto:

• Escale aumentando a contagem de shards (reshard/scale), ou
• Melhore o desempenho do consumidor usando processamento em lote (batching), utilizando enhanced fan-out (para um throughput de até 2 MB/s por consumidor) ou a Kinesis Client Library (KCL) v2 com checkpointing aprimorado.

Use aws kinesis describe-stream para inspecionar a contagem de shards e aws cloudwatch get-metric-statistics para GetRecords.IteratorAgeMilliseconds. Ao comparar as opções de remediação, considere:

• Adicionar shards: aumenta o throughput de ingestão e leitura; requer resharding e rebalanceamento.
• Enhanced fan-out: evita o throughput de leitura compartilhado, mas aumenta o custo por consumidor.
• Otimização do consumidor: reduz a necessidade de shards extras e o custo, mas requer esforço de engenharia.

Métricas de entrega do Firehose: DeliveryToS3.DataFreshness quantifica a latência de entrega; configurações típicas de buffering_delay são de 60 a 900 segundos e manterão os registros até que o bufferSize ou o bufferInterval seja atingido. Se DeliveryToS3.DataFreshness estiver alto:

• Verifique as dicas de buffer do Firehose (BufferIntervalInSeconds, BufferSizeInMBs) no console ou via aws firehose describe-delivery-stream.
• Inspecione os erros do CloudWatch (DeliveryToS3.RecordsFailed) e as permissões do bucket S3 (erros de KMS se estiver criptografado).

Lembre-se da semântica de buffering do Firehose: o serviço atrasa intencionalmente até o intervalo de buffer; reduza o intervalo de buffer para diminuir a latência, ao custo de escritas mais frequentes no S3.

CloudTrail e auditoria de acesso a dados

O CloudTrail fornece atividade de API e, opcionalmente, eventos de dados para o S3 e Lambda, que não são habilitados por padrão. Para capturar eventos de S3 no nível do objeto, habilite explicitamente os eventos de dados no CloudTrail através do console ou com aws cloudtrail create-trail --include-global-service-events e adicione os recursos de dados do S3. Sem habilitar os eventos de dados do S3, você não verá GetObject/PutObject no CloudTrail, o que é uma lacuna comum durante as investigações.

Use os logs do CloudTrail combinados com o CloudWatch Logs Insights para correlacionar métricas operacionais (ex: logs de jobs do Glue) com eventos de acesso. Padrões de consulta:

• CloudWatch Logs Insights: filter @message like /GetObject/ | stats count() by userIdentity.principalId
• Use regras do EventBridge para reagir a chamadas de API específicas (ex: PutBucketAcl) e encaminhar para o SNS para alertas rápidos.

As tarefas de replicação do DMS também publicam métricas no CloudWatch: monitore FullLoadRows para verificar a conclusão da cópia inicial, CDCLatencyMilliseconds para detectar latência na replicação (lag) e AppliedChanges para garantir que as transações estão sendo aplicadas no destino. Crie alarmes para CDCLatencyMilliseconds que excedam os SLAs de negócio e para um baixo valor de AppliedChanges após um aumento nas linhas de carga total (full load rows).

Armadilhas Comuns e Critérios de Decisão

• Alto IteratorAgeMilliseconds no Kinesis confundido com problemas na origem — abordagem correta: verifique o checkpointing e o tempo de processamento do consumidor; escale adicionando shards ou use o enhanced fan-out somente após analisar o perfil de CPU/IO do consumidor.
• Erros de OOM em jobs do Glue tratados aumentando cegamente os DPUs — abordagem correta: analise o perfil dos estágios do Spark, otimize o particionamento e a filtragem de dados; aumente o DPU ou o tipo de worker somente se os limites de recursos forem confirmados.
• Atraso no buffer do Firehose causando percepção de perda de dados — abordagem correta: verifique BufferIntervalInSeconds e BufferSizeInMBs; reduza o intervalo para necessidades de baixa latência e aceite taxas de escrita/custos mais altos.
• Presumir que o CloudTrail registra leituras de objetos S3 por padrão — abordagem correta: habilite os eventos de dados do S3 no CloudTrail para capturar GetObject/PutObject para auditorias forenses.
• Falta de alarmes para o lag do CDC do DMS — abordagem correta: crie alarmes do CloudWatch para CDCLatencyMilliseconds e compare AppliedChanges vs FullLoadRows; investigue a rede ou o backlog de transações quando o lag aumentar.
• Excesso de alertas em picos transitórios — abordagem correta: use períodos de avaliação (evaluation-periods), pontos de dados para alarme (datapoint-to-alarm) ou detecção de anomalias para reduzir o ruído e use alarmes compostos para condições correlacionadas.

Problema Prático: Cenário de Caso de Uso

A Acme Analytics executa a ingestão de clickstream em tempo real via Kinesis, enriquece eventos usando jobs de ETL do Glue, persiste lotes antigos (stale batches) via Firehose no S3 e replica bancos de dados legados com o DMS. Eles observam atrasos de ponta a ponta: lag do consumidor no Kinesis, OOMs em jobs do Glue e o Firehose mostrando um alto valor para DeliveryToS3.DataFreshness.

1. Analise o perfil dos consumidores do Kinesis: colete a métrica GetRecords.IteratorAgeMilliseconds, inspecione os logs do consumidor e execute uma análise de custo comparando o enhanced fan-out do Kinesis com o escalonamento de shards.
2. Examine as métricas do CloudWatch e os Logs Insights do job do Glue em busca de stack traces de OOM; teste o reparticionamento + predicado de pushdown localmente ou em um job menor; somente então aumente o DPU/tipo de worker, se necessário.
3. Inspecione as configurações de buffer do Firehose (BufferIntervalInSeconds) e a métrica DeliveryToS3.DataFreshness; reduza o intervalo de buffer para SLOs críticos e valide as permissões de escrita no S3/KMS.
4. Configure alarmes compostos no CloudWatch combinando IteratorAgeMilliseconds, a taxa de erro do job do Glue e a métrica DataFreshness do Firehose; entregue os alertas para um tópico SNS de plantão (on-call) e acione um runbook via EventBridge.
5. Habilite os eventos de dados do S3 no CloudTrail e correlacione os eventos GetObject/PutObject com os horários de início dos jobs do Glue e as alterações aplicadas pelo DMS (AppliedChanges) para detectar acessos não autorizados ou atrasados.

Esta abordagem segue as melhores práticas da AWS: monitorar as métricas de serviço corretas na granularidade adequada, preferir correções direcionadas de código e configuração antes de escalar recursos, e garantir que o registro em nível de auditoria esteja explicitamente habilitado para permitir uma análise rápida da causa raiz e remediação automatizada.

← Segurança · Todos os domínios · Otimização de Custos para Cargas de Trabalho de Dados →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →

Navegar Amazon →