Monitoramento
Quais métricas de banco realmente antecipam um incidente
Boa parte dos painéis de banco mede o presente, não o que vem. Quais indicadores têm poder preditivo e por que os limiares clássicos falham.
Uma métrica só antecipa um incidente se tiver tendência e se a tendência tiver prazo. CPU em 95% não antecipa nada: é o incidente acontecendo. Já o crescimento semanal de um arquivo de dados contra o espaço livre, ou a idade do último backup íntegro, dão semanas de aviso. A diferença entre um painel que ajuda e um que só documenta o desastre está inteira nessa distinção.
A maioria dos painéis de banco herdados mede estado instantâneo — CPU, memória, sessões ativas. São úteis para confirmar um incidente em curso e quase inúteis para evitá-lo.
Por que os limiares clássicos falham
Boa parte dos alertas em produção replica regras de bolso que perderam validade ou nunca foram gerais.
"Page Life Expectancy abaixo de 300 é problema." Esse número veio de uma recomendação da era em que servidores tinham poucos gigabytes de memória, e circula desde então como se fosse absoluto. Em uma instância com muita RAM, PLE de 300 significa algo muito diferente do que significava naquele contexto — e em servidores com múltiplos nós NUMA, o valor global esconde o comportamento por nó. O que informa é o desvio em relação à linha de base daquela instância, não o cruzamento de um número fixo.
"CXPACKET alto significa problema de paralelismo." CXPACKET indica que houve paralelismo, o que é o comportamento pretendido para consultas grandes. Versões recentes separaram a espera de coordenação da espera real do consumidor justamente porque o tipo original era ambíguo demais para virar alerta. Alertar em cima dele produz ruído constante e nenhuma ação.
"CPU alta é gargalo de CPU." Frequentemente é plano de execução ruim, falta de índice ou parametrização que força recompilação — a CPU é o efeito. Trocar o servidor por um maior costuma comprar alguns meses e devolver o mesmo problema.
O padrão comum nos três casos: são medidas de estado tratadas como diagnóstico, sem linha de base e sem mecanismo associado.
O que tem poder preditivo
Indicadores úteis têm três características: variam devagar o suficiente para dar tempo de agir, têm relação causal clara com uma falha conhecida e podem ser comparados com o próprio histórico.
| Indicador | Falha que ele antecipa |
|---|---|
| Espaço livre × taxa de crescimento por arquivo | Parada por disco cheio, com data estimável |
| Idade do último backup restaurado e validado | Recuperação que não cabe no prazo do negócio |
| Atraso de replicação no percentil alto, não na média | Perda de dados em failover; leitura inconsistente |
| Duração das cadeias de bloqueio ao longo do dia | Travamento em pico de acesso |
| Tempo de espera dominante comparado à linha de base | Regressão de plano, índice perdido, saturação de I/O |
| Idade de transação / congelamento (PostgreSQL) | Parada de escrita por wraparound |
| Erros recorrentes no log que ninguém lê | Corrupção, falha de job, expiração de credencial |
| Variação no plano das consultas mais caras | Query que era instantânea e passou a varrer tabela |
Nenhum desses exige ferramenta cara. Todos exigem duas coisas que costumam faltar: histórico para comparação e alguém que leia a tendência.
Linha de base é o que transforma número em sinal
Sem histórico, todo valor precisa de um limiar arbitrário — e é daí que vêm os alertas que o time aprende a ignorar. Com histórico, a pergunta muda de "esse número é alto?" para "esse número é diferente do que esse servidor faz normalmente nesta hora, neste dia da semana?".
Duas consequências práticas:
O limiar vira relativo. Uma espera média de I/O que dobrou em duas semanas é sinal, mesmo que o valor absoluto ainda pareça confortável. A mesma espera estável há meses não é sinal, mesmo que o número pareça alto.
A sazonalidade deixa de gerar falso positivo. Fechamento de mês, folha, campanha — cargas que se repetem previsivelmente não deveriam disparar alerta todo mês. Se disparam, o alerta perde credibilidade e, com ela, a função.
Alerta sem ação é ruído
Um alerta que ninguém sabe o que fazer com ele treina o time a ignorar o canal inteiro, inclusive os alertas que importam. Antes de criar qualquer regra, vale exigir três respostas: qual falha ela antecipa, com quanto tempo de antecedência, e qual é a ação esperada de quem receber.
Se a ação é "olhar e ver se piora", isso não é alerta — é painel. Painel se consulta na revisão periódica; alerta acorda alguém. Misturar os dois é a origem mais comum da fadiga de alerta.
Vale o inverso também: falhas silenciosas precisam de alerta ativo, não de painel. Backup que parou de rodar, job desabilitado, réplica desconectada e credencial expirada não produzem sintoma até o momento em que são necessários — e nesse momento não há mais tempo.
De sintoma a mecanismo
Toda métrica útil aponta para um mecanismo. Bloqueio prolongado aponta para transações longas ou índice ausente, e o caminho de investigação está em como achar a query que bloqueia as outras. Idade de backup aponta para a cadeia de recuperação, tratada em seu backup restaura dentro do prazo do negócio?. Crescimento anormal em PostgreSQL aponta para autovacuum impedido, discutido em autovacuum, bloat e wraparound.
Quando a métrica não leva a um mecanismo, ela não pertence ao alerta.
Próximo passo
Se o monitoramento atual avisa junto com o usuário, ele está medindo o presente. Antecipar exige histórico, linha de base e leitura periódica por quem reconhece o padrão.
A H1 Data faz um diagnóstico gratuito do ambiente SQL Server que inclui a revisão do que está sendo medido, do que não está, e de quais sinais hoje passam despercebidos até virarem incidente.