Amazon DVA-C02: Monitoramento, Logging e Depuração (CloudWatch, X-Ray, Rastreamento, Alarmes) — Guia de estudos

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

Faz parte do AWS Developer Associate DVA-C02 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

CloudWatch Logs, Métricas e Filtros de Métrica de Log

O CloudWatch Logs é o pipeline principal para telemetria de aplicações e da plataforma; os desenvolvedores devem projetar os logs para serem estruturados (JSON) para que o Metrics e o Insights possam analisá-los (parse) de forma confiável. Para métricas de aplicação personalizadas, prefira o CloudWatch Embedded Metric Format (EMF) ou o PutMetricData para necessidades de dimensões imediatas e alta resolução; o EMF incorpora um JSON _aws nas linhas de log e permite que o CloudWatch extraia muitas métricas em uma única chamada PutLogEvents, o que é eficiente em custo e throughput. Quando você precisar derivar métricas de logs textuais no lado do serviço, crie filtros de métrica (PutMetricFilter) em um grupo de logs que mapeiem padrões de filtro para MetricTransformations; isso gera métricas do CloudWatch que podem ser plotadas em gráficos e usadas em alarmes. As APIs operacionais comuns são CreateLogGroup, CreateLogStream e PutLogEvents (fique atento ao sequenceToken e aos limites de tamanho de lote do PutLogEvents), e AssociateKmsKey para anexar uma chave KMS gerenciada pelo cliente a um grupo de logs para criptografia em repouso (encryption at rest). Atenção ao IAM: PutLogEvents e PutMetricData exigem permissões explícitas, e as concessões (grants) do KMS devem permitir que o principal do serviço (service principal) use as chaves para criptografia. Use políticas de retenção para controlar custos e prefira métricas de alta resolução (PutMetricData com StorageResolution=1) somente quando precisar de visibilidade abaixo de um minuto.

Rastreamento e X-Ray para Sistemas Distribuídos

O rastreamento distribuído (distributed tracing) instrumenta os fluxos de requisição entre serviços para revelar onde ocorrem latência e erros; o AWS X-Ray é a opção integrada. Habilite o rastreamento Ativo (Active tracing) em funções Lambda (Lambda TracingConfig Mode: Active) e habilite o X-Ray para os estágios (stages) do API Gateway para propagar o cabeçalho de rastreamento (trace header) do X-Ray. Use o SDK do AWS X-Ray em seu runtime (aws-xray-sdk-core para Node, aws_xray_sdk para Python, AWSXRayRecorder para Java) para criar subsegmentos, adicionar anotações (indexadas, valores pequenos) e metadados (não indexados, objetos maiores). Capture chamadas de SDK downstream envolvendo (wrapping) os clientes do AWS SDK com o gravador (recorder) do X-Ray para que o SDK instrumente automaticamente as requisições para o S3, DynamoDB e chamadas HTTP. Para cargas de trabalho em contêineres (containerized workloads), execute o daemon do X-Ray como um sidecar ou use a camada (layer) do daemon; ele aceita pacotes UDP (porta padrão 2000) e os envia em lote para o serviço X-Ray. Configure regras de amostragem (CreateSamplingRule) para evitar ruído, mas ajuste as regras ou use a substituição (override) do SDK para fluxos críticos que você sempre deseja rastrear. Esteja ciente dos limites de tamanho do documento de segmento e nunca coloque PII (Informações de Identificação Pessoal) em anotações, pois elas são indexadas e pesquisáveis.

Alarmes, Notificações e Design de Alertas

Os alarmes devem detectar eventos acionáveis, reduzir o ruído e se integrar com runbooks. Use os CloudWatch Alarms em métricas nativas, métricas personalizadas (de PutMetricData ou filtros de métrica) ou expressões de matemática de métrica (metric math); ajuste DatapointsToAlarm e EvaluationPeriods para evitar oscilação (flapping) e prefira alarmes compostos para condições de múltiplos sinais (downstream quebrado + taxa de erros aumentada) para reduzir o volume de alertas. As ações de alarme podem publicar em tópicos do SNS para fluxos de trabalho humanos/de automação, invocar o Auto Scaling ou o Systems Manager OpsCenter (criar OpsItems), ou rotear através de regras do EventBridge para playbooks complexos (source: aws.cloudwatch). Para necessidades rápidas de plantão (on-call), use SNS -> ponto de extremidade (endpoint) HTTP ou integração com PagerDuty; para remediação automatizada, use EventBridge -> Step Functions ou Lambda com o mínimo de privilégios no IAM (least-privilege). Considere modelos de detecção de anomalias para estabelecer uma linha de base (baselining) do tráfego e defina limites OK com histerese. As armadilhas comuns incluem criar muitos alarmes dimensionados (explosão nos custos de monitoramento), depender apenas de gatilhos de um único ponto de dados e falhar em proteger os tópicos de notificação (políticas de acesso do SNS) para que os alertas não vazem para consumidores não intencionais.

Padrões de Solução de Problemas e Práticas de SDK/API

Comece a solucionar problemas estabelecendo uma linha do tempo do esperado versus o observado e, em seguida, correlacione logs, métricas e traces. Use o CloudWatch Logs Insights para consultas ad-hoc (fields @timestamp, @message | parse … | stats count() by bin(1m)) para encontrar picos e, então, mude o foco para os traces do X‑Ray para latências detalhadas. Para APIs baseadas em Lambda, verifique os cold starts, os tempos de anexo da ENI da VPC (para funções em uma VPC) e se os destinos do Lambda ou DLQs (Dead-Letter Queues) estão configurados para capturar invocações assíncronas com falha. Para capturar invocações com falha, use Lambda Destinations (onFailure para SNS, SQS ou EventBridge) ou uma DLQ assíncrona para preservar os payloads. Ao instrumentar o código, lide com o throttling da API implementando backoff exponencial com jitter e monitorando erros 429 por meio de filtros de métrica ou contadores EMF. Pegadinhas comuns: PutLogEvents exige o token de sequência correto e CreateLogStream primeiro; PutMetricData pode sofrer throttling — agrupe em lote e emita métricas agregadas; o X‑Ray exige as permissões xray:PutTraceSegments e xray:PutTelemetryRecords (política gerenciada AWSXRayDaemonWriteAccess); e a amostragem pode ocultar problemas, a menos que você ajuste as regras para fluxos de baixa frequência, mas críticos.

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

Cenário: A Acme Retail opera um serviço de checkout serverless na AWS usando API Gateway -> Lambda -> DynamoDB. A equipe executa o CloudWatch Logs e o X‑Ray de forma centralizada, mas não possui métricas de throughput de dispositivos por minuto e precisa de alertas confiáveis sobre picos de latência da API sem criar alertas ruidosos.

Desafio: Capturar contagens de dispositivos/mensagens por minuto quase em tempo real, garantir o rastreamento de ponta a ponta para solicitações lentas e criar um alarme de baixo ruído que acione uma Lambda de remediação automatizada e notifique a equipe de plantão.

Abordagem Recomendada:

Instrumente a Lambda de checkout para emitir uma métrica personalizada de alta resolução usando a API PutMetricData com Namespace=Acme/Checkout, MetricName=DeviceReportsPerMinute, Timestamp=now, Value=1 e StorageResolution=1; agrupe-os em lote na memória e descarregue a cada 30s para evitar o throttling da API.
Incorpore também JSON no formato EMF nos logs da Lambda para obter dimensões mais ricas (customerId, region) e dependa do CloudWatch Logs para extrair métricas adicionais via PutLogEvents e filtros de métrica (PutMetricFilter) para contagem de erros.
Habilite o rastreamento do X-Ray: defina o TracingConfig Mode da Lambda como Active, habilite o X-Ray no stage do API Gateway e use o SDK do X-Ray para adicionar anotações (sem PII) e subsegmentos em torno de chamadas HTTP externas para APIs de terceiros.
Crie um alarme composto do CloudWatch que combine uma métrica de alta latência do 95º percentil (usando metric math) com um pico em DeviceReportsPerMinute; defina EvaluationPeriods=3, DatapointsToAlarm=2, e a Ação para um tópico SNS que aciona um endpoint da equipe de plantão, além de uma regra do EventBridge que invoca uma Lambda de remediação (com uma role de privilégio mínimo).

Justificativa: A emissão de métricas de alta resolução e EMF fornece tanto contagens imediatas por minuto quanto uma dimensionalidade mais rica; o X‑Ray fornece a causa raiz da latência até as chamadas downstream; alarmes compostos reduzem o ruído ao exigir condições correlacionadas antes de alertar e permitem a automação via EventBridge.

← Segurança · Todos os domínios · Armazenamento →

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