Monitoramento do RDS e Performance Insights

Uma API de pagamentos dá timeout por uns 4 minutos toda manhã às 09:05. Você abre o console do RDS. CPUUtilization chega no máximo a 41%. FreeableMemory está plana. ReadLatency fica em 2 milissegundos. FreeStorageSpace tem espaço de sobra. Toda métrica que você tem diz que o banco está saudável, e o banco claramente não está.

Nada está quebrado no seu monitoramento. Você está olhando a camada errada. As métricas de instância do CloudWatch medem a máquina em que o banco roda. Elas não conseguem enxergar 30 sessões enfileiradas atrás de um lock de linha, porque um lock não custa CPU, nem memória, nem I/O. Ele custa tempo, e tempo não é algo que o hypervisor consiga medir.

O RDS te dá 3 camadas de monitoramento, cada uma olhando o banco de um lugar diferente. Saber qual delas responde qual pergunta é a maior parte da habilidade aqui.

3 camadas, 3 perguntas diferentes

Leia a coluna do meio de novo, porque ela é a lição inteira numa linha. A camada 1 fica fora da instância e enxerga totais de recurso. A camada 2 fica dentro do sistema operacional e enxerga processos. A camada 3 fica dentro do engine do banco e enxerga sessões. O incidente das 09:05 é invisível na camada 1 e óbvio na camada 3.

As métricas do CloudWatch que valem acompanhar

O RDS envia métricas ao CloudWatch em períodos de 1 minuto por padrão, no namespace AWS/RDS com a dimensão DBInstanceIdentifier. Esses data points de 60 segundos ficam disponíveis por 15 dias.

Duas dessas escondem armadilhas.

DatabaseConnections não é contagem de sessões. Ela conta conexões de rede de clientes, então deixa de fora as sessões que o engine abre para si mesmo, sessões do scheduler de jobs, sessões de execução paralela, sessões cuja conexão de rede morreu antes da limpeza e as próprias conexões de gerenciamento do RDS. A contagem real de sessões é maior, às vezes muito maior, e são as sessões que consomem memória de conexão.

BurstBalance e EBSIOBalance% são baldes diferentes. BurstBalance é o balde de créditos de I/O do próprio volume gp2. EBSIOBalance% e EBSByteBalance% descrevem a capacidade de burst de EBS da DB instance, que existe em muitos tamanhos de instância independentemente do tipo de armazenamento, e são baseados no throughput de todos os volumes, incluindo o volume raiz. Quando EBSByteBalance% cai para zero, é a instância que está ficando sem capacidade, e a resposta é uma classe maior, não mais IOPS provisionados. Trocar esses 2 leva você a comprar a coisa errada.

Enhanced Monitoring: a visão que o CloudWatch não consegue dar

O CloudWatch lê CPU no hypervisor. O Enhanced Monitoring lê com um agent que roda dentro do sistema operacional da DB instance. Essa diferença é o motivo de os 2 números raramente baterem exatamente, e a distância cresce nas classes menores, onde mais máquinas virtuais dividem um host físico.

O agent te compra algo que o hypervisor não entrega em granularidade nenhuma: a quebra por processo e por thread. Quando a CPU está em 90% e você precisa saber se é o engine do banco, um backup ou uma thread de manutenção desgovernada, essa é a única camada que responde.

Os detalhes que caem na prova:

• A granularidade é de 1, 5, 10, 15, 30 ou 60 segundos. Passar --monitoring-interval 0 desliga o recurso.
• As métricas vão para o CloudWatch Logs, no log group RDSOSMetrics, com retenção padrão de 30 dias. Você muda isso no log group, e não na DB instance.
• Ele exige uma role do IAM. O console consegue criar a rds-monitoring-role para você; via CLI ou API, você cria por conta própria, com a policy AmazonRDSEnhancedMonitoringRole e uma relação de confiança para o service principal monitoring.rds.amazonaws.com. Quem chama precisa de iam:PassRole.
• Ligar o recurso não exige reboot.
• O console do RDS atualiza, no melhor caso, a cada 5 segundos. Se você configurar granularidade de 1 segundo, os dados de 1 segundo vêm do CloudWatch Logs, não do console.

aws rds modify-db-instance \
  --db-instance-identifier payments-prod \
  --monitoring-interval 5 \
  --monitoring-role-arn arn:aws:iam::123456789012:role/rds-monitoring-role

Aqui está o engano que essa camada cria. Como o console do RDS desenha o Enhanced Monitoring em gráficos, as pessoas assumem que dá para alarmar sobre aqueles valores do mesmo jeito que se alarma sobre CPUUtilization. Não dá, pelo menos não diretamente. A saída do Enhanced Monitoring são eventos de log, então alarmar sobre ela significa criar antes um metric filter do CloudWatch Logs sobre o RDSOSMetrics e depois alarmar sobre a métrica que esse filtro produz.

DB load: a métrica que responde "por quê"

A camada 3 mede algo diferente de todas as métricas acima. Não um recurso, e sim trabalho em andamento.

Uma sessão é a conversa de uma aplicação com o banco. Uma sessão está ativa quando ela enviou trabalho e está esperando resposta: ou rodando em CPU, ou esperando um recurso, como uma página ser lida para a memória, um lock ser liberado ou uma escrita de log terminar. Sessões ociosas não contam.

DB load é o número de sessões ativas, e a unidade dele é sessões ativas médias (AAS). O Performance Insights amostra essa contagem uma vez por segundo. O AAS é o total de sessões contadas dividido pelo número de amostras.

Pegue 5 amostras consecutivas de 1 segundo:

O DB load desse intervalo é 2 AAS: em média, 2 sessões estavam ativas a qualquer momento. A média importa. Um pico de 1 segundo com 40 sessões quase não mexe no AAS, enquanto 5 sessões travadas por um minuto inteiro empurram o número com força. Esse é o viés certo, porque o que machuca um banco é fila sustentada, e não rajada momentânea.

Para cada sessão ativa que amostra, o Performance Insights também captura o comando SQL, se a sessão estava em CPU ou esperando, o host e o usuário. Essas 4 informações são o que torna o número acionável, em vez de apenas interessante.

Ler o gráfico: Max vCPU, waits e top SQL

O gráfico de DB load desenha uma linha horizontal na contagem de vCPUs da DB instance, rotulada Max vCPU. Essa é a referência que transforma um número abstrato num veredito.

Trabalhe isso numa db.r6g.2xlarge, que tem 8 vCPUs:

• DB load estável em 3 AAS: 3 sessões ativas contra 8 vCPUs de capacidade. Confortável.
• DB load em 8 AAS, quase tudo em CPU: a instância está saturada em CPU. Mais vCPUs ajudariam.
• DB load em 21 AAS com 18 delas esperando: 21 sessões estão ativas, mas só algumas estão trabalhando. As outras 18 estão na fila atrás de alguma coisa. Aumentar vCPUs não muda nada, porque CPU nunca foi a restrição.

Esse último caso é o que as pessoas leem errado, e é exatamente por isso que a carga é dividida em métricas separadas no CloudWatch:

DBLoadNonCPU dominando é o sinal para parar de olhar tamanho de instância e começar a olhar o que as sessões estão esperando. É para isso que serve a dimensão de wait event. Fatie o DB load por wait event e você em geral encontra 2 ou 3 eventos respondendo pela maior parte da carga: leituras de I/O, locks de linha, flushes de log. Os nomes específicos variam por engine, mas o formato da resposta não.

Depois fatie por top SQL para achar quais comandos estão produzindo aquele wait. É comum uma query entre centenas responder pela maioria do DB load. O Performance Insights também captura planos de execução das queries mais pesadas a cada 5 minutos, então você consegue ver como o engine escolheu rodar a query que está te machucando. Dá para fatiar por host e por usuário também, e é assim que você identifica um único servidor de aplicação mal comportado ou uma conta de relatórios.

O fluxo, nessa ordem: o DB load diz o quão ruim, os wait events dizem que tipo de ruim, o top SQL diz quem está causando, e o plano diz por que aquela query é lenta.

De volta ao incidente das 09:05. O DB load salta para 25 AAS numa instância de 8 vCPUs, quase inteiramente num wait event de lock de linha, e o top SQL mostra um único UPDATE na tabela de contas. Um job em lote noturno segura uma transação longa, e as escritas da API ficam na fila atrás dela. Nenhuma métrica de recurso mostraria isso, porque recurso nenhum estava sob pressão.

O Performance Insights agora é CloudWatch Database Insights

A AWS aposentou o console do Performance Insights em 31 de julho de 2026. O console agora redireciona para o CloudWatch Database Insights. Nada na medição por baixo mudou: é o mesmo DB load, as mesmas sessões ativas médias, os mesmos wait events e top SQL. O que mudou é onde você olha e como aquilo é empacotado.

O que vale lembrar:

• O modo Standard é o padrão, e é para ele que as instâncias que usavam Performance Insights caíram automaticamente, mantendo o período de retenção que já tinham.
• A API do Performance Insights não mudou. Templates de CloudFormation, configurações de Terraform e scripts que definem PerformanceInsightsEnabled e PerformanceInsightsRetentionPeriod continuam funcionando exatamente como escritos.
• A retenção continua em 7 dias por padrão, sem custo extra, ou de 1 a 24 meses num tier pago.
• Planos de execução e análise sob demanda agora exigem o modo Advanced.

Para a prova, trate "Performance Insights" e "a visão de DB load no Database Insights" como a mesma resposta. Uma questão que descreve achar o top SQL por trás de um pico de carga aponta para essa camada de qualquer jeito.

Recomendações proativas

O Performance Insights acompanha métricas selecionadas, aprende um limiar a partir do baseline daquele recurso específico e levanta uma recomendação proativa quando os valores cruzam esse limiar por tempo suficiente. A ideia é pegar o problema enquanto ele ainda está se formando, em vez de depois que ele te acorda de madrugada.

As recomendações aparecem no console do RDS, na página Recommendations da conta inteira, ordenadas por severidade, ou na aba Recommendations de um banco específico. Cada uma traz o problema detectado, gráficos da métrica contra o limiar aprendido e uma análise explicando a ação sugerida. Você age ou descarta.

Um requisito que cai: recomendações proativas exigem um tier pago de retenção. Os 7 dias gratuitos não bastam para o recurso construir um baseline, então uma instância na retenção padrão não produz nenhuma.

Alarmar na camada certa

Alarmes se comportam de forma diferente por camada, e é aqui que as camadas deixam de ser uma distinção acadêmica.

A camada 1 é direta. Métricas de AWS/RDS são métricas comuns do CloudWatch, então o alarme é um alarme normal:

aws cloudwatch put-metric-alarm \
  --alarm-name payments-prod-low-storage \
  --namespace AWS/RDS \
  --metric-name FreeStorageSpace \
  --dimensions Name=DBInstanceIdentifier,Value=payments-prod \
  --statistic Average \
  --period 300 \
  --evaluation-periods 2 \
  --threshold 10737418240 \
  --comparison-operator LessThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:dba-oncall

A camada 2 exige antes um metric filter do CloudWatch Logs, porque o Enhanced Monitoring produz eventos de log.

A camada 3 é dividida. As métricas DBLoad, DBLoadCPU, DBLoadNonCPU e DBLoadRelativeToNumVCPUs são publicadas no CloudWatch, no namespace AWS/RDS, então você alarma sobre elas normalmente. Toda outra counter metric do Performance Insights não é publicada direto, e você chega nela com a função de metric math DB_PERF_INSIGHTS, que a transforma numa série temporal que você consegue plotar e alarmar, inclusive com alarmes de alta resolução abaixo de um minuto.

Um comportamento a esperar: as métricas DBLoad só são publicadas quando existe carga na instância. Buracos no gráfico de um banco parado são normais, então configure como seu alarme trata dados ausentes em vez de ler um buraco como falha.

Qual camada responde qual sintoma

Dicas para a prova

• "Todas as métricas do CloudWatch normais mas o banco está lento" é questão de Performance Insights sempre. Métricas de recurso não enxergam espera.
• "Nível de processo" ou "CPU e memória por processo na DB instance" aponta para Enhanced Monitoring, e só para ele. Você não consegue instalar o agente do CloudWatch numa instância do RDS, então qualquer alternativa que ofereça isso já nasce errada.
• O Enhanced Monitoring vai para o CloudWatch Logs. Se uma alternativa disser que as métricas dele aparecem direto nas métricas do CloudWatch, elimine.
• Fique de olho nos números de granularidade: métricas do CloudWatch a 60 segundos, Enhanced Monitoring de 1 a 60 segundos, amostragem do Performance Insights a 1 segundo.
• Max vCPU é linha de referência, não limite rígido. DB load acima dela significa fila, e só a divisão entre CPU e não CPU diz se uma instância maior é a resposta.
• BurstBalance é o volume gp2. EBSIOBalance% e EBSByteBalance% são a DB instance. Baldes diferentes, correções diferentes.
• Recomendações proativas exigem retenção paga. Os 7 dias gratuitos dão o dashboard, não as recomendações.
• CPUCreditBalance só existe nas classes db.t e é publicada em frequência de 5 minutos, então um alarme com período de 1 minuto sobre ela não vai se comportar como você espera.

A única coisa a reter: escolha a camada de monitoramento pelo lugar onde a resposta mora, e não pelo console que você abriu primeiro. Métricas de recurso dizem que a máquina está bem; o DB load diz que o banco não está. A próxima lição pega a causa mais comum dessa diferença, sessões se acumulando mais rápido do que o banco consegue atender, e resolve com pool de conexões e uma lista curta de alavancas de ajuste.