Monitoramento de infraestrutura falha por dois motivos opostos e igualmente comuns. No primeiro, ninguém monitora nada além de "o host responde ao ping", e o incidente é descoberto pelo cliente. No segundo, há centenas de alertas, quase todos irrelevantes, e a equipe aprendeu a ignorar o canal — o que é funcionalmente idêntico a não monitorar. O que resolve não é mais métrica: é escolher as poucas que antecipam o problema em vez de anunciá-lo.

Sintoma, causa e antecedência

Vale separar três tipos de métrica, porque o papel de cada uma é diferente.

Sintoma é o que o usuário sente: aplicação lenta, serviço fora. Precisa ser monitorado, mas quando dispara o dano já começou.

Causa é o que explica: disco saturado, memória esgotada, OSD travado. Serve para diagnosticar rápido.

Antecedência é o que avisa antes: capacidade que vai encher em cinco dias, retransmissão de Corosync crescendo, setor realocado aumentando. É aqui que o monitoramento paga o investimento, porque transforma incidente em tarefa agendada.

O objetivo é ter as três, com a maioria dos alertas que acordam alguém vindo das duas primeiras, e a maior parte do valor vindo da terceira.

O que a interface do Proxmox já dá — e o que falta

O painel nativo mostra CPU, memória, rede e I/O por nó e por VM, com histórico. É bom e resolve a consulta pontual, quando você já sabe onde olhar.

Três coisas faltam. Não há alerta configurável de verdade, então ninguém é avisado sem alguém estar olhando. Não há agregação entre nós com visão única do cluster. E não há retenção longa para análise de tendência, que é exatamente o que produz antecedência.

Por isso o desenho usual acrescenta uma camada externa: um exportador de métricas do Proxmox, Prometheus coletando, Grafana visualizando e Alertmanager notificando. Alternativas integradas como Zabbix ou Checkmk também funcionam bem — a escolha importa menos que a disciplina sobre o que medir.

As métricas que realmente antecipam

Se você implantar apenas duas linhas dessa tabela, escolha a primeira e a sexta. Capacidade e integridade de backup são as duas que geram os incidentes mais caros e as duas mais fáceis de prever.

Capacidade: pense em dias, não em porcentagem

Alerta de "disco com 85% de uso" é ruim. Ele dispara em volume que cresce um gigabyte por mês, o que é irrelevante, e não dispara em volume que saltou de 40% para 60% em dois dias — que é o problema de verdade.

A métrica útil é a projeção: no ritmo atual de crescimento, quantos dias faltam para encher? Isso se calcula a partir da tendência recente e converte o alerta em algo que se pode agir sobre. Quinze dias de antecedência dão tempo de comprar disco, limpar dado antigo ou ajustar retenção. Noventa e cinco por cento de ocupação dão tempo de entrar em pânico.

Duas atenções específicas. Em ZFS, a performance cai bem antes de encher, então trate 80% como o limite prático, não 95%. Em Ceph, o espaço livre não é folga: é o que o cluster usa para recriar cópias quando um disco falha. Um Ceph a 85% de ocupação pode não conseguir se recuperar de uma falha de disco, e aí uma falha simples se transforma em incidente sério.

Corosync: a métrica mais negligenciada

Já dissemos que a maioria dos reinícios inexplicados de nó tem causa em rede. A boa notícia é que isso é previsível: antes de perder o vínculo, o Corosync retransmite. Retransmissão crescente é o cluster avisando que a rede não está dando conta.

Praticamente ninguém monitora isso, e é a métrica com melhor relação entre esforço e incidente evitado em cluster Proxmox. Um alerta sobre crescimento sustentado de retransmissões costuma aparecer dias antes do primeiro reinício — tempo suficiente para separar o tráfego, adicionar um segundo anel ou corrigir o switch.

Backup: monitore o resultado, não o agendamento

Este é o ponto que mais gera falsa segurança. A pergunta certa não é "o agendamento está ativo?", e sim "quando foi o último backup bem-sucedido de cada VM?".

A diferença é enorme na prática. Um agendamento ativo que falha silenciosamente há três semanas parece saudável em qualquer painel que só olhe a configuração. Monitore, então:

1. Idade do último backup bem-sucedido, por VM. Alerta quando passar do intervalo esperado com uma margem.
2. VMs sem nenhum backup. A VM criada ontem e não incluída em nenhum agendamento é o furo clássico.
3. Resultado da verificação de integridade do datastore, que confirma que o guardado é restaurável.
4. Sucesso da sincronização remota, para a cópia externa não parar sem ninguém notar.
5. Crescimento do datastore, que revela retenção mal configurada antes de o disco encher.

Alerta que merece acordar alguém

A regra que mantém o canal de alertas confiável: se ninguém precisa fazer nada agora, não é alerta — é relatório.

Divida em três níveis. O que exige ação imediata notifica de verdade: nó fora, quórum perdido, storage acima de 90%, todos os backups falhando. O que exige ação nos próximos dias vira tarefa: capacidade projetada, disco com setor realocado, certificado a vencer. E o resto é painel, consultado quando alguém investiga.

Cuide também de duas fontes de ruído. Agrupe alertas com a mesma causa — um switch que cai não deve gerar quarenta notificações. E ajuste a duração antes de disparar: CPU a 100% por dez segundos é normal, por quinze minutos é problema.

Não esqueça o hardware físico

Métrica de sistema operacional não vê tudo. Vale coletar do controlador de gestão do servidor — IPMI, iDRAC, iLO — três informações que só ele tem: temperatura e estado dos ventiladores, saúde das fontes redundantes e estado da controladora de disco com sua bateria de cache.

Fonte redundante que morreu e ninguém percebeu é redundância que não existe mais, e o segundo defeito é o que derruba o servidor. É uma das falhas silenciosas mais comuns em ambiente físico.

Comece pequeno e útil

Não tente implantar cem métricas. Um primeiro ciclo enxuto e completo vale mais do que um projeto ambicioso pela metade:

• Nó fora do ar e perda de quórum.
• Projeção de dias até encher, em todos os storages.
• Idade do último backup bem-sucedido, por VM.
• Saúde do Ceph ou do pool ZFS.
• Retransmissões do Corosync.
• SMART com setor realocado ou desgaste alto.
• Validade de certificados.

Sete itens cobrem a maioria dos incidentes caros de um cluster Proxmox. Depois de tê-los funcionando e confiáveis, acrescente o resto.

Erros comuns

• Alertar por porcentagem de disco em vez de projeção de dias.
• Não monitorar retransmissão do Corosync, e ser surpreendido por reinício de nó.
• Verificar se o agendamento de backup existe, não se o backup aconteceu.
• Ceph acima de 80% sem folga para recuperação.
• Ignorar SMART, e trocar disco só depois que ele morre.
• Canal de alertas com tanto ruído que a equipe silenciou.
• Nenhuma coleta do controlador de gestão, com fonte redundante morta sem aviso.
• Retenção curta de métricas, impedindo qualquer análise de tendência.

Onde a Solvefy/Cloud entra

Implantamos monitoramento como parte da sustentação: coletamos as métricas que antecipam incidente, configuramos limites que fazem sentido para o seu ambiente e ajustamos o ruído para que o alerta continue sendo levado a sério. Como parceiros oficiais Proxmox, sabemos onde o cluster costuma avisar antes de falhar — Corosync, capacidade e integridade de backup — e é nisso que focamos primeiro. Para quem prefere não operar o painel, acompanhamos e agimos junto com a sua equipe.

Quer saber o que o seu cluster já está tentando avisar? Fazemos um diagnóstico gratuito da infraestrutura, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.