Amazon DOP-C02: Monitoramento, Logs e Observabilidade — Guia de estudos

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

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

Visão Geral

Monitoramento, logs e observabilidade na AWS exigem a combinação de métricas, logs, traces, eventos e telemetria de saúde em sinais acionáveis. Arquiteturas eficazes usam o Amazon CloudWatch para métricas, alarmes e dashboards; o CloudWatch Logs e o Logs Insights para ingestão e análise de logs; o AWS X-Ray para rastreamento distribuído; o AWS CloudTrail para auditoria e integridade; o Amazon EventBridge para detecção e automação orientadas a eventos; o AWS Health para eventos de serviço específicos da conta; e pipelines centralizados (Kinesis Data Firehose e OpenSearch) para busca e correlação em escala. Os padrões abaixo enfatizam a redução de ruído, o roteamento preciso de sinais, a automação e as operações em múltiplas contas e Regiões (multi-account/multi-Region).

Métricas, Alarmes, Dashboards e Alarmes Compostos do CloudWatch

As métricas do CloudWatch são a base para SLOs, escalabilidade e alertas. Publique métricas personalizadas com dimensões granulares para isolar sinais (por exemplo, apiOperation, appVersion, statusCode). Use o CloudWatch Embedded Metric Format (EMF) com logs estruturados para emitir dimensões de alta cardinalidade de forma eficiente a partir do Lambda, contêineres e EC2, evitando o overhead da API PutMetricData.

Configure alarmes com uma avaliação robusta:

Escolha períodos alinhados à granularidade dos dados e às janelas de SLO.
Defina datapointsToAlarm (m de n) para resiliência contra ruídos transitórios.
Use TreatMissingData para evitar falsos positivos durante implantações ou pausas.
Utilize bandas de detecção de anomalias quando os baselines variarem com a sazonalidade, e a matemática de métricas (metric math) para indicadores derivados (latência p95, percentuais de erro, taxas de saturação).
Anexe ações aos alarmes: notificar via SNS, criar OpsItems no OpsCenter, executar uma Automação do SSM ou recuperar instâncias EC2. As políticas de escalabilidade podem referenciar estados de alarme para tomar ações, mas alarmes compostos não podem acionar a escalabilidade diretamente.

Alarmes compostos reduzem a fadiga de alarmes ao combinar múltiplos alarmes subjacentes com lógica AND/OR. Por exemplo, alerte apenas quando a latência p95 estiver alta E a taxa de erros 5xx exceder o limite E a saturação da CPU persistir, alinhando-se assim ao impacto no usuário. Alarmes compostos aceitam atualizações de estado de alarmes filhos entre Regiões/contas por meio da observabilidade entre contas (cross-account) ou de streams de métricas para uma conta central.

Dashboards visualizam indicadores-chave entre serviços. Use widgets para métricas, resultados de consultas do Logs Insights e Status de Alarme. Padronize as convenções de dashboard (nomes, intervalos de tempo, sobreposições de SLO) e utilize visualizações entre Regiões/contas com o CloudWatch Observability Access Manager (OAM). Para correlação ad hoc, fixe widgets do Logs Insights e do X-Ray ServiceLens lado a lado com widgets de mapa de serviço e taxas de erro do Kinesis Firehose.

CloudWatch Logs: Log Groups, Filtros de Métrica, Filtros de Subscrição e Logs Insights

Estruture os log groups por aplicação/componente e estágio do ciclo de vida. Defina políticas de retenção explícitas (não confie em “Nunca Expirar”) e habilite a criptografia com KMS quando necessário. Use políticas de recursos e permissões granulares no IAM para controlar produtores e consumidores (subscribers). Para ingestão de alta vazão (high-throughput), garanta concorrência e envio em lote (batching) adequados para os log streams.

Filtros de métrica (Metric filters) transformam padrões de log em métricas. Defina um padrão de filtro com tokens extraídos (JSON ou delimitados por espaço) e mapeie os tokens para dimensões de métrica. Isso suporta casos de uso como métricas por API, por versão e por código de resposta, publicadas diretamente dos logs sem modificar os produtores. Garanta que as unidades e os valores padrão estejam corretos; prefira 1 por evento e derive taxas via matemática de métricas. Use essas métricas para alertas de SLO e dashboards.

Filtros de subscrição (Subscription filters) fazem o stream de logs quase em tempo real para:

Kinesis Data Firehose para transformação e entrega ao S3/OpenSearch.
Kinesis Data Streams para consumidores personalizados.
Lambda para roteamento personalizado, ofuscação de PII (Informações de Identificação Pessoal) ou notificações orientadas a eventos. Use um destino do CloudWatch Logs com uma IAM role para subscrições entre contas (cross-account). Planeje para novas tentativas (retry) e backpressure; o Lambda e o Firehose fornecem retries integrados e DLQs/buckets S3 para erros, respectivamente.

O CloudWatch Logs Insights fornece consulta interativa e serverless sobre os logs. Os operadores principais incluem fields, filter, parse, stats, sort, limit, dedup e bin para agrupamento por tempo. Faça o parse de campos JSON ou use um parsing do tipo grok para logs de texto. Exemplos:

filter status >= 500 | stats count() by apiOperation, appVersion
parse @message /duration=(?<ms>\d+)/ | stats pct(@ms,95) by service Salve consultas usadas com frequência com QueryDefinition para reuso pela equipe, e incorpore-as em dashboards como widgets de consulta. Para automação, agende um Lambda via EventBridge para executar StartQuery/GetQueryResults e publicar resumos no SNS ou OpsCenter. Restrinja o escopo da consulta a log groups e janelas de tempo específicos para controlar os custos.

AWS X-Ray: Rastreamento, Regras de Amostragem, Mapas de Serviço e Anotações

O X-Ray captura traces distribuídos entre serviços para encontrar contribuidores de latência e limites de falha. Instrumente os serviços com o AWS Distro for OpenTelemetry (ADOT) ou os SDKs do X-Ray, propague o cabeçalho de trace (por exemplo, X-Amzn-Trace-Id) e execute o daemon/agente do X-Ray onde necessário (ECS/EKS/EC2). Muitos serviços gerenciados se integram nativamente (API Gateway, ALB por meio de logs de acesso que fazem proxy dos traces, Lambda com rastreamento ativo, Step Functions por meio de subsegmentos).

As regras de amostragem controlam o volume de dados e a fidelidade do sinal. Use um conjunto de regras de amostragem centralizado com:

Reservatório fixo por segundo para traces de linha de base por serviço.
Porcentagem de amostragem baseada em taxa para escalar com o throughput.
Prioridade de regra e correspondência de serviço/URL para caminhos críticos (hot paths) e cenários de erro. Aumente a amostragem durante incidentes e para o tráfego canário para garantir a observabilidade enquanto gerencia os custos.

Os mapas de serviço visualizam o grafo de chamadas, mostrando as conexões (edges) com latência, taxas de erro e indicadores de throttling. Aprofunde-se (drill down) nos traces para examinar segmentos e subsegmentos em busca de dependências downstream. Use anotações (pares de chave-valor indexados) para filtragem de alta cardinalidade, como customerTier, apiOperation, appVersion ou IDs de requisição da AWS. Use metadados para contexto verboso e não indexado para evitar a sobrecarga do índice (index blowout). Combine grupos de traces do X-Ray com o CloudWatch ServiceLens para correlacionar logs, métricas e traces em uma única visualização. Crie expressões de filtro (por exemplo, annotation.appVersion = “2.3.1” and fault = true) para isolar regressões e exportar IDs de trace para pesquisa de logs direcionada.

Governança e Eventos: CloudTrail, EventBridge e AWS Health

O CloudTrail registra a atividade de API para governança e análise forense. Habilite uma trilha organizacional (organization trail) em todas as contas e todas as Regiões, entregue para um bucket S3 centralizado com SSE-KMS, habilite a validação de arquivos de log e integre com o CloudWatch Logs para detecção quase em tempo real. Diferencie as classes de eventos:

Eventos de gerenciamento: plano de controle (control plane) (por exemplo, CreateUser, RunInstances). Configure para incluir eventos somente de leitura (read-only) e somente de escrita (write-only) conforme necessário.
Eventos de dados: operações de alto volume no plano de dados (data plane), como acesso em nível de objeto no S3, invocações do Lambda, APIs de item do DynamoDB, chamadas do servidor de API do EKS. Defina o escopo dos eventos de dados seletivamente (por bucket/função/tabela) para controlar os custos. Use o CloudTrail Insights para detectar picos incomuns de API e envie os eventos do CloudTrail para o EventBridge para autorremediação. Valide a integridade dos logs usando arquivos de resumo (digest files) e o comando da AWS CLI cloudtrail validate-logs durante as auditorias.

O EventBridge fornece uma malha de eventos (event fabric) para detecção e automação. Use o barramento de eventos padrão (default event bus) para eventos de serviços da AWS e crie barramentos personalizados para eventos do domínio da aplicação. Defina padrões de eventos (event patterns) que correspondam a source, detail-type, campos de detail, prefixos, intervalos numéricos e “anything-but”. Aplique transformadores de entrada (input transformers) para remodelar os eventos, anexe políticas baseadas em recursos para publicação entre contas (cross-account) e configure tentativas (retry)/DLQ nos alvos (targets). Alvos comuns incluem Lambda (remediação), Step Functions (orquestração), SQS (desacoplamento), Systems Manager Automation (ações de operações), CodePipeline (gatilhos de CI) e SNS (notificações). Arquive e reproduza (replay) eventos para se recuperar de interrupções nos consumidores e use o registro de esquemas (schema registry) para gerar modelos de eventos fortemente tipados.

O AWS Health expõe eventos de serviço específicos da conta, mudanças agendadas e problemas operacionais. Integre via EventBridge com source aws.health e detail-type AWS Health Event para rotear para canais de incidentes, abrir OpsItems no OpsCenter ou acionar ações seguras de desligamento/escalonamento para janelas de manutenção. Use a Visualização Organizacional (Organizational View) com uma conta de administrador delegado para agregar eventos do Health de todas as contas e considere a API do AWS Health ou a solução AWS Health Aware para enviar notificações selecionadas para sistemas de plantão (on-call).

← Infraestrutura como Código e Gerenciamento de Configuração · Todos os domínios · Segurança →

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