Observabilidade de PostgreSQL na AWS: da métrica do CloudWatch à causa raiz

CPU em 92% é um sintoma. A decisão de quem opera é descobrir se a causa é regressão de plano, tempestade de conexões, dívida de vacuum, checkpoints, latência de storage ou demanda legítima — e qual mudança é segura. Uma observabilidade útil conecta quatro camadas: experiência da aplicação, carga SQL, internals do PostgreSQL e infraestrutura cloud.

Defina objetivos de serviço antes dos alarmes

Comece por SLOs de disponibilidade e latência das transações críticas e crie níveis de aviso e crítico a partir do error budget. Alarmes de infraestrutura sem impacto viram ruído; alarmes de aplicação sem contexto do banco atrasam o diagnóstico. Cada acionamento precisa de dono, runbook, evidências esperadas e escalonamento.

Traduza a promessa do negócio em SLIs mensuráveis

Para disponibilidade, defina evento bom com precisão: por exemplo, checkout confirmado em até 800 ms e sem duplicidade. SLI = eventos bons / eventos válidos. Exclua somente condições previstas no contrato; remover timeouts silenciosamente destrói o indicador. Use distribuições de latência nas jornadas importantes, pois a média esconde a cauda sentida pelos usuários.

Alertas por burn rate costumam ser mais acionáveis que limiares estáticos. Queima rápida em janela curta detecta falha severa; queima lenta em janela longa encontra degradação persistente. Saturação do banco vira evidência para acionamento quando consome o error budget ou se aproxima de um limite conhecido.

Colete as quatro camadas

CloudWatch fornece métricas e eventos do RDS. Enhanced Monitoring adiciona detalhe do sistema operacional. As ferramentas de performance de banco da AWS ajudam a analisar carga e waits. Dentro do PostgreSQL, habilite e dimensione pg_stat_statements conscientemente, ative track_io_timing após medir overhead e exporte logs com retenção definida. Higienize amostras SQL e valores conforme a classificação dos dados.

Use identificadores que atravessem as camadas

Propague trace/request ID pela aplicação e logs. Normalize SQL em fingerprint estável para literais não criarem milhões de “queries”. Registre banco/instância, role, application name, versão do deploy e hash/versão do plano. Alinhe relógios e intervalos. Sem essas chaves, a equipe vê picos simultâneos, mas não prova que representam o mesmo evento causal.

Controle overhead e cardinalidade

Coleta disputa recursos com produção. Prefira deltas de views cumulativas, limite amostras SQL, retenção e evite query crua, user ID ou request ID como dimensões de séries. Alta cardinalidade pertence a logs/traces com indexação controlada, não a todo label de métrica. Teste CPU, I/O, storage e rede da coleta no pico e defina como ela degrada.

Alerte risco, não todo movimento

• Disponibilidade: falha de conexão, writer indisponível, failover/reboot e backup com erro.
• Saturação: CPU sustentada, pouca memória, orçamento de conexões, storage, fila e latência.
• Carga: regressão de p95, novo fingerprint caro, bloqueios e transações longas.
• Saúde: dívida de vacuum, risco de transaction ID, pico de temporários, checkpoints solicitados e retenção de WAL.
• Replicação: replay lag, backlog de slot, consumidor inativo e conflitos de recovery.

Use janelas múltiplas: um alarme rápido pega falhas severas; outro mais lento confirma degradação persistente. Envie warnings para uma fila e acione uma pessoa somente quando ela puder agir. Deduplicate sintomas quando um evento do banco explica todos.

Preserve evidências do incidente

No início, capture sessões ativas, waits, árvore de bloqueio, deltas das queries, versões de plano, parâmetros, deploys e métricas AWS. Contadores cumulativos exigem deltas; snapshots exigem timestamp. Não repita diagnósticos pesados em um primary já saturado.

Siga uma triagem de baixo risco

1. Confirme impacto e blast radius: endpoint, tenant, banco ou frota.
2. Cheque mudanças: deploy, parâmetro, failover, manutenção, secret ou tráfego.
3. Classifique wait/recurso dominante e identifique blockers antes de matar sessões.
4. Compare mix de queries e planos com o último baseline saudável.
5. Escolha a menor mitigação reversível, observe recuperação e preserve evidência.

Reiniciar pode apagar o estado da causa raiz e ampliar o incidente com tempestade de reconexão. Cancelar, modular tráfego, desligar feature ruim ou adicionar capacidade temporária pode ser mais seguro, mas cada ação exige dono e rollback pré-aprovados.

Transforme incidentes em melhoria de detecção

A revisão deve registrar impacto, linha do tempo, gatilho, condições contribuintes, por que os controles não impediram, como o monitoramento detectou e ações mensuráveis. Valide alarmes com game days: falhe uma conexão, alcance um limite de volume em teste, bloqueie uma transação, rotacione um segredo e execute failover controlado.

Como o PG Monitoring transforma telemetria AWS em diagnóstico PostgreSQL

O PG Monitoring preserva o contexto que métricas genéricas não têm: histórico normalizado de queries, mudanças de plano, waits, bloqueios, saúde de vacuum/tabelas, replicação, incidentes e capacidade. O operador parte de um sintoma AWS, chega à mudança exata da carga e compara com baseline saudável. Detecção de anomalias e regressões reduz o intervalo entre “algo mudou” e “esta query ou mecanismo criou o risco”.