O dominio de Monitoramento e Registro representa 15% do exame DOP-C02. As perguntas vao alem de saber qual servico coleta quais dados: avaliam se voce consegue projetar um pipeline completo desde a coleta ate a analise e automacao de acoes. Pense em um engenheiro de planto resolvendo um incidente de producao as 3 da manha: o exame pergunta qual combinacao de ferramentas e correta para cada situacao.
Projeto do Pipeline de Coleta de Logs
A base do monitoramento eficaz e coletar dados corretamente. CloudWatch e uma plataforma poderosa onde um unico agente pode coletar logs e metricas personalizadas simultaneamente.
CloudWatch Agent e Metricas Personalizadas
As metricas padrao do CloudWatch para EC2 nao incluem utilizacao de memoria nem I/O de disco detalhado. Para coleta-las, voce deve instalar o CloudWatch Agent. O agente funciona de maneira identica no EC2 (Linux e Windows) e em servidores on-premises.
Considere uma empresa de videogames que opera milhares de instancias EC2. Ela mantinha um daemon de coleta de logs desenvolvido internamente e experimentava gaps de configuracao frequentes ao lancar novas instancias. A solucao e CloudWatch Agent combinado com AWS Systems Manager State Manager. O State Manager aplica o agente automaticamente a novas instancias, enquanto o SSM Parameter Store armazena a configuracao centralizada e versionada do agente.
| Metodo de Coleta | Alvo | Caracteristicas Principais | |----------------|------|--------------------------| | CloudWatch Agent | EC2, on-premises | Metricas de memoria/disco e coleta de arquivos de log | | CloudWatch Embedded Metric Format (EMF) | Lambda, ECS, EC2 | Incorpora metricas em logs JSON, sem chamadas diretas ao PutMetricData | | AWS Distro for OpenTelemetry (ADOT) | Containers, serverless | Padrao OpenTelemetry, envia para X-Ray e CloudWatch simultaneamente |
EMF e eficaz para reduzir custos de API. Enviar multiplos pontos de dados de metricas individualmente via PutMetricData gera cobranças por chamada. EMF envia logs JSON estruturados ao CloudWatch Logs e a AWS extrai automaticamente as metricas. O custo e menor que chamadas diretas ao PutMetricData, e as metricas extraidas suportam alarmes igual a metricas padrao do CloudWatch.
Kinesis Data Firehose com Transformacao Lambda
Um cenario comum no exame envolve uma plataforma IoT recebendo logs em diferentes formatos de milhares de dispositivos, precisando armazena-los no S3 e consultar com Athena. A resposta e Kinesis Data Firehose com uma transformacao Lambda.
Kinesis Data Firehose e um servico completamente gerenciado que nao requer administracao de servidores. Uma funcao Lambda atua como processador de transformacao de dados, convertendo varios formatos de log para JSON antes de gravar no S3. As configuracoes de tamanho de buffer (1-128 MB) e intervalo de buffer (60-900 segundos) fornecem entrega em lotes em tempo quase real.
A distincao do Kinesis Data Streams e clara. Data Streams requer gerenciamento de shards e implementacao de checkpoints, aumentando a complexidade operacional. Firehose entrega automaticamente para S3, Redshift ou OpenSearch sem codigo de consumidor. Firehose tambem e menos caro.
Registros com falha de transformacao sao preservados em um bucket S3 separado, garantindo zero perda de dados. Esse comportamento de "preservacao de registros de erro" e testado quando a pergunta inclui a condicao "nenhuma perda de dados e aceitavel."
Politicas de Assinatura em Nivel de Conta e Agregacao de Logs Entre Contas
Quando centenas de grupos de logs sao adicionados dinamicamente, configurar filtros de assinatura individualmente e impraticavel operacionalmente. As politicas de assinatura em nivel de conta do CloudWatch Logs, configuradas uma vez, se aplicam automaticamente a todos os grupos de logs atuais e futuros na conta. Esse e o padrao de resposta quando a pergunta combina "minimizar sobrecarga operacional" com um numero crescente de grupos de logs.
Arquitetura de agregacao de logs multi-conta:
Cada conta membro: configurar politica de assinatura em nivel de conta do CloudWatch Logs Conta central de Auditoria: Kinesis Data Firehose aguardando para receber logs Filtros de assinatura das contas membro encaminham diretamente para o Firehose central (entrega entre contas) Politica de Ciclo de Vida S3: transicao automatica para S3 Glacier apos 90 dias
A distincao entre Export Task e filtro de assinatura importa. Export Tasks sao em lote e manuais, com atrasos de ate 12 horas. Filtros de assinatura sao em tempo real e automaticos, fornecendo entrega em tempo quase real.
Campos de Tempo nos Logs de Acesso do ALB
Os logs de acesso do ALB dividem o tempo de processamento de solicitacoes em tres campos. O exame pede que voce os distinga com precisao.
| Campo | Significado | O que Indica quando Alto | |-------|-------------|------------------------| | request_processing_time | Tempo desde receber solicitacao do cliente ate encaminhar ao destino | Gargalo no ALB | | target_processing_time | Tempo para o destino processar a solicitacao | Problema de desempenho na aplicacao ou banco de dados | | response_processing_time | Tempo desde receber resposta do destino ate enviar ao cliente | Latencia de rede ou caminho de retorno do ALB |
Quando target_processing_time e alto, o problema esta no codigo da aplicacao ou nas consultas de banco de dados. Quando request_processing_time e alto, o gargalo e o proprio ALB. Esses campos sao analisados usando CloudWatch Logs Insights ou Athena.
Rastreamento Distribuido e Monitoramento Hibrido
Rastreamento Distribuido com X-Ray
Em uma arquitetura de microsservicos, quando uma chamada API especifica e lenta, identificar qual servico e o gargalo e dificil. X-Ray visualiza o caminho completo que uma solicitacao percorre atraves de varios servicos.
Conceitos chave do X-Ray: Trace: o caminho de execucao completo de uma unica solicitacao Segment: a unidade de trabalho realizada em cada servico Subsegment: unidades de trabalho granulares como chamadas a APIs externas e consultas de banco de dados Mapa de Servico: representacao visual de dependencias de servicos e tempos de resposta
Voce pode instrumentar Lambda, ECS, EC2, API Gateway e Elastic Beanstalk usando o SDK do X-Ray. Lambda suporta X-Ray Active Tracing, que habilita rastreamento basico sem alteracoes de codigo.
Amazon Managed Grafana + Prometheus para Ambientes Hibridos
Para monitoramento unificado de ambientes hibridos que misturam EKS, ECS e on-premises, a combinacao Amazon Managed Grafana + Amazon Managed Service for Prometheus aparece no exame. Esse par e completamente gerenciado sem administracao de servidores, sendo compativel com o ecossistema Prometheus.
O modelo de coleta de metricas difere do CloudWatch. CloudWatch usa um modelo push; Prometheus usa um modelo pull, fazendo scraping de targets para metricas. Grafana suporta ambas as fontes de dados, permitindo dashboards unificados que combinam metricas do CloudWatch e Prometheus.
Ferramentas de Analise do CloudWatch Logs
Logs Insights e Filtros de Metricas
CloudWatch Logs Insights fornece analise interativa de logs usando uma linguagem de consulta semelhante a SQL com capacidades de busca em tempo quase real. Isso o torna adequado para consultar logs de aplicacoes do Elastic Beanstalk, ECS e outros servicos em tempo real. Athena e um servico de consultas em lote que analisa dados ja armazenados no S3.
CloudWatch Logs Metric Filter detecta padroes regex em streams de log em tempo real e converte correspondencias em metricas personalizadas do CloudWatch. E configurado completamente no console sem nenhum codigo, mantendo baixa a sobrecarga operacional.
Cenario do Centro de Operacoes de Seguranca: quando logs de firewall devem acionar alertas imediatos em eventos de severidade CRITICAL sem servicos de seguranca adicionais, a resposta e CloudWatch Logs Metric Filter + CloudWatch Alarm + SNS. Esse padrao de tres servicos e a resposta quando as condicoes incluem "sem codigo necessario", "minimizar sobrecarga operacional" e "baseado em CloudWatch Logs existente."
Distincao entre Metric Filter e Subscription Filter: Metric Filter: correspondencia de padroes produz metricas de contagem que acionam Alarmes (para alertas) Subscription Filter: transmite eventos de log para Lambda, Kinesis ou Firehose em tempo real (para pipelines de dados)
Automatizacao Baseada em Eventos e Auto-Recuperacao
Padroes de Eventos do EventBridge
EventBridge e o hub para construir cadeias de automatizacao a partir de eventos emitidos por servicos AWS. Padroes de eventos importantes para o exame:
| Servico | Valor source | Eventos Chave | |--------|-------------|--------------| | EC2 Auto Scaling | aws.autoscaling | EC2_INSTANCE_LAUNCH_UNSUCCESSFUL | | AWS Trusted Advisor | aws.trustedadvisor | Limite de servico se aproximando de 80% | | AWS Health | aws.health | Aposentadoria de instancia, interrupcao de servico | | AWS Config | aws.config | Mudanca de conformidade de configuracao |
Cenario de falha no lancamento de instancia do Auto Scaling: durante um evento promocional, o Auto Scaling falhou em lancar instancias mas a equipe so soube horas depois. A correcao e uma regra do EventBridge que detecta eventos EC2_INSTANCE_LAUNCH_UNSUCCESSFUL e os direciona para SNS para notificacao imediata. Nenhuma infraestrutura adicional alem de EventBridge e SNS e necessaria.
Nao confunda com Lifecycle Hooks. Lifecycle Hooks sao executados apos um lancamento bem-sucedido de instancia enquanto esta no estado Pending. Eles nao conseguem detectar uma falha de lancamento.
CloudWatch Alarms + Lambda para Auto-Remediacao
Alarmes do CloudWatch vao alem de notificacoes simples. Eles podem acionar funcoes Lambda para executar acoes de remediacao automatizadas.
Cenario de deteccao de login SSH direto e isolamento automatico: uma empresa proibe SSH e requer acesso somente via Session Manager, mas registros de login