Toda instância RDS PostgreSQL vem com três camadas nativas de observabilidade: métricas do CloudWatch, Performance Insights e, para os mais aventureiros, o DevOps Guru for RDS. Juntas, elas respondem razoavelmente bem "o que está acontecendo". Quase nunca respondem "por quê", e raramente dizem o que fazer antes que os usuários percebam. Este post detalha exatamente onde cada ferramenta nativa para, e onde uma camada de monitoramento nativa do Postgres precisa entrar.
O que a AWS te dá de cara
- Métricas do CloudWatch — contadores de infraestrutura (CPUUtilization, FreeableMemory, ReadIOPS, WriteIOPS, DatabaseConnections, ReplicaLag) com granularidade de 1 minuto por padrão, 1 segundo com Enhanced Monitoring ativado.
- Performance Insights — uma visão contínua do top SQL por carga, dividido por wait event, com 7 dias de histórico grátis e até 24 meses no plano pago.
- Enhanced Monitoring — métricas em nível de SO (CPU por processo, disco, memória) coletadas por um agente rodando no host do RDS, cobrado separadamente.
- DevOps Guru for RDS — detecção de anomalias baseada em ML sobre as métricas acima, sinaliza desvios de uma linha de base aprendida.
É uma base sólida. Também é, por design da própria AWS, genérica: foi feita para funcionar de forma idêntica para MySQL, MariaDB, PostgreSQL e SQL Server. Genericidade tem um custo — nada disso entende internamente o Postgres.
Onde o CloudWatch para
O ReplicaLag no CloudWatch é um número único em segundos, amostrado a cada minuto. Ele diz que existe lag agora. Ele não diz:
- Se o lag é causado por uma query longa segurando um snapshot na réplica, throughput de rede, ou a réplica atrasada no replay do WAL.
- Se o lag está em tendência de alta e vai estourar seu SLA em 20 minutos, ou é um pico isolado que vai se corrigir sozinho.
- Qual standby específico, se você roda mais de um, está em risco.
Pegadinha: o ReplicaLag do CloudWatch pode mostrar 0 mesmo enquanto slots de replicação lógica acumulam WAL silenciosamente no primário porque um subscriber travou — o CloudWatch não enxerga retenção em nível de slot, só o lag físico de streaming.
Onde o Performance Insights para
O Performance Insights é genuinamente útil para "qual SQL está consumindo mais tempo de sessão ativa agora." Mas é um visualizador de carga em um ponto no tempo, não um detector de regressão:
- Mostra o top SQL atual por wait event, não "o plano de execução desta query específica mudou de Index Scan para Seq Scan há três dias."
- Não tem noção do histórico de plano de uma query, então uma mudança de plano causada por estatística desatualizada ou um autovacuum que nunca rodou passa despercebida até a carga já estar alta o suficiente para aparecer no painel.
- Não rastreia bloat de tabela ou índice, proporção de dead tuples, nem efetividade do autovacuum — um dos maiores causadores dos próprios picos de CPU e IO que o Performance Insights mostra depois do fato.
- Retenção longa (além de 7 dias) é um add-on pago cobrado por vCPU por instância, o que pesa rápido numa frota.
Onde o DevOps Guru para
A detecção de anomalias do DevOps Guru é treinada em métricas de infraestrutura (o mesmo conjunto do CloudWatch). É bom em "a CPU está 3 desvios-padrão acima do padrão usual para este horário." Não tem modelo dos modos de falha específicos do Postgres: risco de wraparound de transaction ID, esgotamento de pool de conexões por tipo de query, um índice faltante que colapsaria um sequential scan em um index scan, ou um slot de replicação prestes a encher o disco de WAL. Isso exige conhecimento de domínio sobre como o Postgres realmente funciona, não detecção genérica de anomalia em série temporal.
Lado a lado
| Capacidade | CloudWatch + PI + DevOps Guru | PG Monitoring |
|---|---|---|
| Métricas de infra (CPU, IOPS, memória) | Sim, nativo | Sim, além de correlacionado com atividade de query |
| Detecção de regressão de plano de execução | Não | Sim — rastreia planos EXPLAIN ao longo do tempo por fingerprint de query |
| Causa raiz do replication lag | Só o valor do lag | Lag + causa (replay de WAL, snapshot longo, rede, backlog de slot) + previsão de tendência |
| Rastreamento de autovacuum/bloat | Não | Proporção de dead tuples por tabela, estimativa de bloat, efetividade do vacuum |
| Recomendações de índice | Não | Geradas por IA, com custo antes/depois quantificado e DDL segura |
| Visão multi-instância / multi-nuvem | Por instância, só AWS | Um único painel entre RDS, Aurora, self-managed, outras nuvens |
| Retenção além de 7 dias | Plano pago, cobrado por vCPU | Incluído |
| Assistente de IA com contexto do banco | Não | Copilot com schema, histórico de queries e contexto de incidentes |
Configurando monitoramento contínuo no RDS
Como o RDS não concede acesso a filesystem ou superusuário, um agente push é o modelo prático: ele conecta pelo protocolo padrão do PostgreSQL (sem precisar de agente de SO no host do RDS) e lê de views já expostas pelo RDS:
-- Ativar no parameter group (exige reboot se ainda não estiver ativo)
shared_preload_libraries = 'pg_stat_statements'
pg_stat_statements.track = 'all'
track_io_timing = onCom isso ativado, uma role de monitoramento com pg_monitor (role nativa do Postgres, disponível no RDS desde o Postgres 10) consegue ler pg_stat_statements, pg_stat_activity, pg_stat_replication e afins sem superusuário:
CREATE ROLE pg_monitoring_agent WITH LOGIN PASSWORD '<redacted>';
GRANT pg_monitor TO pg_monitoring_agent;
GRANT pg_read_all_stats TO pg_monitoring_agent;Aponte o agente para o endpoint do RDS, libere o security group para o IP de saída do agente na porta 5432, e as métricas começam a fluir no mesmo modelo push que o CloudWatch usa — só que com detalhe de plano e bloat que o CloudWatch nunca coleta.
Conclusão
CloudWatch, Performance Insights e DevOps Guru não estão errados — são exatamente o que uma plataforma de nuvem agnóstica de banco pode razoavelmente entregar. A lacuna que deixam é exatamente onde a expertise específica do Postgres importa: regressão de plano, saúde do vacuum, internals de replicação e recomendações acionáveis em vez de só números para observar. O PG Monitoring roda junto com sua configuração de CloudWatch existente — não substitui seus painéis de billing da AWS, preenche tudo que a AWS estruturalmente não pode saber sobre como o Postgres em si está se comportando.