Quase todo ambiente monitora CPU, memória e disco do servidor de banco. São métricas úteis e, para prever uma queda de banco, praticamente inúteis: quando a CPU dispara, o problema já está acontecendo há um tempo e os usuários já reclamaram.
As métricas que dão antecedência são outras. Elas são específicas do banco, vivem dentro dele e quase nunca estão no painel padrão de infraestrutura.
As métricas que realmente avisam
Conexões em uso contra o limite
A mais importante, e a mais subestimada.
Banco não avisa que vai esgotar conexões — ele simplesmente passa a recusar. E, quando isso acontece, a aplicação inteira para de uma vez, sem degradação gradual. É uma queda abrupta e total.
Monitore o percentual de conexões em uso, com alerta em 70% e em 85%. E monitore também conexões ociosas dentro de uma transação — são conexões que a aplicação abriu, iniciou uma transação e abandonou. Elas seguram recursos, bloqueiam a limpeza automática e são um sintoma claro de bug de aplicação. É a métrica mais reveladora sobre a qualidade do código que conversa com o banco.
Eventos de espera
A pergunta "o banco está lento por quê?" tem resposta direta nesta métrica: o que as sessões ativas estão esperando.
- Esperando disco: leitura ou escrita saturada.
- Esperando bloqueio: concorrência, transação longa segurando outras.
- Esperando rede: cliente lento consumindo o resultado.
- Esperando CPU: consulta cara demais.
Cada uma aponta para uma correção diferente, e a distribuição dessas esperas ao longo do tempo é o melhor painel de diagnóstico que existe para um banco. Vale mais que qualquer gráfico de uso de recurso.
Atraso de replicação
Se há réplica, esta métrica é obrigatória e precisa ter alerta.
Réplica atrasada é duas coisas ruins ao mesmo tempo: leitura desatualizada, se a aplicação usa a réplica para consultas, e perda de dado no failover, porque o que não replicou se perde ao promover.
Monitore em tempo, não em bytes — "40 segundos atrás" é acionável, "120 MB de atraso" não diz nada a quem está de plantão.
E monitore também se a replicação está rodando. Replicação parada não gera atraso crescente em algumas configurações; ela simplesmente para, silenciosamente.
Idade das transações e limpeza automática
Específico do PostgreSQL e crítico: pela forma como ele mantém versões de linha, existe um limite de envelhecimento de transações. Se a limpeza automática não acompanhar, o banco toma medidas drásticas para proteger a integridade — incluindo recusar novas escritas.
É uma parada total e evitável, com semanas de antecedência visível. Monitore a idade das transações mais antigas e alerte bem antes do limite.
Junto com isso, monitore transações longas em aberto. Uma transação esquecida há horas impede a limpeza de avançar e é frequentemente a causa raiz do problema acima.
Inchaço de tabelas e índices
Tabelas com muita atualização acumulam versões antigas. O banco ocupa mais disco do que os dados justificam, e as consultas ficam lentas porque leem páginas vazias.
Cresce devagar, sem sintoma, até o dia em que a consulta que levava 200 ms leva 4 segundos. Monitorar o inchaço das maiores tabelas permite agir antes.
Taxa de acerto do cache
Percentual de leituras atendidas pela memória em vez do disco. Queda dessa taxa antecede degradação de desempenho de forma confiável, e costuma indicar que o volume de dados cresceu além da memória disponível — uma decisão de capacidade, não um problema pontual.
Consultas mais custosas por tempo acumulado
Não a mais lenta isoladamente — a que soma mais tempo no período. Uma consulta de 50 ms executada um milhão de vezes por hora consome muito mais que uma de 8 segundos rodada uma vez.
Acompanhar o ranking dessa métrica ao longo do tempo revela regressão de desempenho introduzida por deploy, o que é uma das informações mais acionáveis disponíveis.
Espaço em disco, com projeção
Disco cheio derruba banco de dados de forma particularmente desagradável. Alerta em percentual fixo é insuficiente — o que importa é a tendência: "no ritmo atual, acaba em 6 dias" é acionável; "está em 82%" não diz se é estável ou se cresce rápido.
Monitore separadamente a área de dados, a área de logs de transação e a área de backup. O acúmulo de log de transação por replicação parada ou por arquivamento falhando é uma causa clássica e rápida de disco cheio.
Métricas por tipo de banco
Além das comuns, cada um tem as suas:
PostgreSQL: idade das transações, atraso e estado da replicação, transações longas, arquivamento de log funcionando, inchaço, bloqueios em espera.
MySQL e MariaDB: eficiência do pool de buffer, atraso de replicação e estado das threads de réplica, bloqueios e esperas, conexões abortadas, tamanho e taxa de escrita do log de transação. Em Galera, o estado do cluster e o controle de fluxo — que indica um nó lento freando todos os outros.
MongoDB: atraso do conjunto de réplicas, fila de operações, eficiência do cache do motor de armazenamento, distribuição de chunks quando há sharding, consultas sem índice.
Redis: memória usada contra o limite, política de remoção em ação, taxa de acerto, conexões, comandos lentos, estado da persistência. E, o mais importante: quantas chaves estão sendo removidas por falta de memória — indica que o cache está pequeno demais e o desempenho está degradando silenciosamente.
O que alertar, e para quem
O erro mais comum é alertar tudo. Alerta que dispara toda semana e não exige ação treina a equipe a ignorar — e no dia importante, será ignorado também.
Alerta que acorda alguém:
- Banco inacessível.
- Conexões acima de 85% do limite.
- Replicação parada, ou atraso acima do RPO acordado.
- Disco com menos de um dia de folga projetada.
- Idade de transação próxima do limite crítico.
- Falha de backup, ou backup que não rodou.
Alerta que gera tarefa no horário comercial:
- Conexões acima de 70%.
- Taxa de acerto do cache em queda sustentada.
- Inchaço crescendo em tabela grande.
- Consulta nova aparecendo no topo do ranking de custo.
- Disco com menos de duas semanas de folga.
- Transações longas recorrentes.
Só painel, sem alerta:
- Uso de CPU e memória.
- Volume de transações.
- Distribuição de esperas.
Repare que CPU, a métrica mais monitorada, está na última categoria. Ela é contexto para diagnóstico, não gatilho de ação.
O painel que serve na madrugada
Quem é acordado às três da manhã precisa responder três perguntas em trinta segundos: o banco está de pé? está aceitando conexão? está replicando?
Um painel de plantão com essas três respostas em destaque, e o resto abaixo, vale mais que vinte gráficos bonitos. O painel detalhado é para a investigação que vem depois.
Erros comuns
- Monitorar só CPU, memória e disco do servidor.
- Não monitorar conexões, e ter parada abrupta sem aviso.
- Ignorar conexões ociosas em transação, que indicam bug de aplicação.
- Não monitorar atraso de replicação, ou monitorar em bytes.
- Não detectar replicação parada, apenas atrasada.
- Ignorar a idade de transações no PostgreSQL até a parada de escrita.
- Alerta de disco por percentual fixo, sem projeção de tendência.
- Não separar a área de log de transação da área de dados.
- Olhar a consulta mais lenta em vez da de maior tempo acumulado.
- Alertar tudo, e treinar a equipe a ignorar.
- Alerta sem ação definida — quem recebe não sabe o que fazer.
- Nenhum painel simples para o plantão.
- Monitorar o banco e não monitorar se o backup rodou.
Onde a Solvefy/Cloud entra
Monitoramento de banco é parte do que entregamos em sustentação: instrumentação das métricas específicas de cada banco, painéis separados por uso — plantão e investigação —, alertas classificados por urgência com ação definida em cada um, e a linha de base que permite reconhecer regressão de desempenho depois de um deploy. Trabalhamos com PostgreSQL, MariaDB, MongoDB, Redis e Elasticsearch, integrados à stack de observabilidade que você já usa.
Seu banco vai avisar antes de cair, ou depois? Diagnóstico gratuito, sem compromisso, em solvefy.cloud.
Solvefy/Cloud — Infraestrutura que cresce com você.