Postagens

Mostrando postagens com o rótulo CloudWatch

Entendendo Instâncias T3 Burstáveis: CPU Credits e Por Que Seu Servidor Fica Lento

Você sobe uma instância T3 para um ambiente de staging, tudo funciona bem por horas — até que, do nada, a CPU trava em 5% e a aplicação começa a responder com latência absurda. Sem erro no log, sem alarme disparado, sem explicação óbvia. Esse é o comportamento clássico de esgotamento de créditos de CPU em instâncias T3, e entender o mecanismo por trás disso é o que separa um diagnóstico de 5 minutos de horas de investigação inútil. TL;DR: Instâncias T3 e CPU Credits Conceito Comportamento CPU Credit Unidade que permite uso de CPU acima da baseline por 1 minuto Baseline de CPU Percentual garantido de CPU por tipo de instância (ex: t3.micro = 10%) Acúmulo de créditos Créditos acumulam quando CPU fica abaixo da baseline Esgotamento CPU é limitada à baseline quando créditos acabam (modo Standard) Modo Un...

Alertas por E-mail via SNS: Por Que Você Não Está Recebendo as Notificações

Você configurou um tópico SNS, adicionou um endpoint de e-mail e aguardou os alertas chegarem — mas a caixa de entrada continua vazia. Na maioria dos casos, o problema não está na configuração do tópico em si: está na confirmação de assinatura que o SNS exige antes de começar a entregar mensagens. TL;DR — Diagnóstico Rápido de Alertas SNS por E-mail Sintoma Causa Provável Ação Nenhum e-mail recebido após publicação Assinatura pendente (não confirmada) Confirmar o link recebido ou recriar a assinatura E-mail de confirmação nunca chegou Filtrado como spam ou link expirado Verificar spam; recriar a assinatura via CLI Status da assinatura é 'PendingConfirmation' Link de confirmação não foi clicado Recriar a assinatura para gerar novo link Assinatura confirmada mas sem entrega Política de filtro de mensagens ativa Verificar FilterPolicy no atributo da assinatura Como o SNS Gerencia Assinaturas de...

Monitoramento de Memória RAM no EC2: Por que o CloudWatch Agent é Obrigatório

Você abre o console do CloudWatch, navega até as métricas da sua instância EC2 e percebe que CPU, rede e disco de I/O estão lá — mas RAM não aparece em lugar nenhum. Não é um bug, não é permissão faltando: o CloudWatch simplesmente não coleta métricas de memória por padrão, e entender por que isso acontece evita horas de busca no lugar errado. TL;DR — Monitoramento de Memória no EC2 Ponto Detalhe Métricas padrão do EC2 Coletadas pelo hipervisor AWS — CPU, rede, disco de I/O de bloco. Sem acesso ao SO convidado. Memória RAM e disco usado Visíveis apenas de dentro do SO. Exigem o CloudWatch Agent instalado na instância. CloudWatch Agent Processo rodando dentro do SO que publica métricas customizadas no namespace CWAgent . IAM necessário A instância precisa de uma IAM Role com a policy CloudWatchAgentServerPolicy . Custo Métricas customizadas têm custo separado das métricas padrão — verifique a tabela ...

Configurando um Alarme de Cobrança no Free Tier da AWS com CloudWatch

Você acabou de criar sua conta AWS, ativou alguns serviços para testar e, algumas semanas depois, recebe uma fatura inesperada. Isso acontece com mais frequência do que deveria — configurar um alarme de cobrança para o AWS Free Tier é a primeira coisa que qualquer engenheiro deveria fazer antes de qualquer outra coisa na conta. TL;DR — Resumo Rápido Etapa O que fazer Serviço envolvido 1 Habilitar métricas de cobrança na conta Billing Console 2 Criar tópico SNS e confirmar e-mail Amazon SNS 3 Criar alarme no CloudWatch com threshold de $5 Amazon CloudWatch 4 Verificar o alarme via CLI AWS CLI Como o Alarme de Cobrança do CloudWatch Funciona Antes de executar qualquer comando, vale entender o fluxo. A métrica EstimatedCharges do namespace AWS/Billing só é publicada na região us-east-1 — independentemente de onde seus recursos estão rodando. Isso não é configurável. Se você criar o alarme em outra...

ALB Retornando 502 Bad Gateway: Instâncias Saudáveis, Resposta Inválida

Você abre o console da AWS, confere o target group e todas as instâncias estão Healthy . Mesmo assim, o ALB continua retornando 502 Bad Gateway para os clientes. Esse é um dos cenários mais frustrantes em operações com Application Load Balancer — o health check passa, mas a aplicação real falha silenciosamente na camada de protocolo HTTP. TL;DR — Diagnóstico Rápido do 502 no ALB Causa Raiz Sinal Observável Camada Resposta HTTP malformada da aplicação 502 imediato, sem latência Aplicação Conexão fechada antes da resposta completa 502 intermitente sob carga Keep-alive / TCP Timeout de idle no ALB menor que no backend 502 em requisições longas Configuração ALB Header HTTP inválido ou tamanho excedido 502 em rotas específicas Protocolo HTTP Target desregistrado durante requisição ativa 502 durante deploy/scale-in Ciclo de vida Como o ALB Processa Respostas — Antes de Depurar O ALB opera na camada ...