Monitoramento de Proxmox VE: o que medir em nós, VMs e cluster
Autor: Pedro Tebaldi PM do KeepGreenMigrar para o Proxmox VE resolve o problema de licenciamento. Não resolve o problema de visibilidade. A console web mostra gráficos por nó e por VM. Ela não avisa, no entanto, quando o quorum oscila. Também fica calada quando um OSD do Ceph entra em estado nearfull ou quando o backup falhou por três noites seguidas.
O monitoramento de Proxmox começa exatamente onde a interface nativa para. Ou seja: correlação entre camadas, alerta com contexto e histórico longo o bastante para provar capacidade. Sem isso, a equipe costuma descobrir o incidente pelo chamado do usuário.
Este guia mapeia o que medir em cada camada e como o hypervisor expõe esses dados. Em seguida, percorre as stacks de coleta e os thresholds que valem a pena. Antes de tudo, se você ainda precisa entender a arquitetura e o modelo de cluster do Proxmox VE, o pilar cobre esse terreno. Aqui, o foco é operação.
Por que a console do Proxmox VE não basta em produção
A console web do Proxmox VE entrega gráficos RRD por objeto, sem correlação entre eles e com alerta reativo por email. Ela mostra que o nó está com CPU alta, mas não conecta esse pico à migração de VM que rodava no mesmo instante. Em produção, essa lacuna transforma diagnóstico em adivinhação.
O primeiro limite é estrutural. Cada gráfico pertence a um objeto: um nó, uma VM, um datastore. Ninguém cruza a curva de IO delay do host com a fila de disco da VM barulhenta que roda nele. Por isso, o operador precisa abrir três telas para montar uma hipótese.
O segundo limite é o alerta. A notificação nativa dispara por evento isolado, sem severidade calculada nem supressão de ruído. Um nó que reinicia gera dezenas de mensagens simultâneas: uma por VM afetada, sem nenhuma que explique a causa.
Vale destacar o custo dessa demora. O levantamento anual sobre interrupções em data centers saiu em 2026. Nele, 57% dos respondentes afirmaram que a última parada relevante custou mais de US$ 100 mil. Um em cada cinco apontou prejuízo acima de US$ 1 milhão.
Por fim, falta o histórico útil. O RRD comprime dados antigos e some com o detalhe fino de meses atrás. Quem precisa comprovar tendência de crescimento ou sustentar metas formais de disponibilidade não consegue extrair essa evidência da interface.
O que monitorar em Proxmox: as cinco camadas do ambiente
O monitoramento de Proxmox cobre cinco camadas: o nó físico, as VMs e containers LXC, o storage, o cluster e o backup. Cada uma falha de um jeito diferente e nenhuma protege a outra. Um nó saudável com storage cheio derruba serviço do mesmo modo que um nó sobrecarregado.
A tabela abaixo resume o que observar em cada camada e qual consequência operacional está em jogo. Dessa forma, ela serve de checklist ao montar o primeiro conjunto de itens da sua ferramenta.
| Camada | O que observar | Por que importa |
|---|---|---|
| Nó (host) | CPU, IO delay, load average, RAM, swap, temperatura e SMART dos discos |
A saturação do host degrada todas as VMs que rodam nele ao mesmo tempo |
| VM e container LXC | CPU, memória alocada contra memória usada, disco I/O, rede e estado do qemu-guest-agent |
Revela o vizinho barulhento antes que o usuário abra chamado de lentidão |
| Storage | Uso por datastore, saúde de OSD e PG no Ceph, ARC e scrub no ZFS, latência de escrita | Storage cheio congela VM, bloqueia snapshot e impede live migration |
| Cluster | Quorum, latência do link de corosync, estado do HA manager e atraso de replicação | A perda de quorum provoca fencing e reinicia nós tecnicamente saudáveis |
| Backup | Resultado do job, duração da janela, execução do verify e espaço no datastore do PBS | Backup que falhou em silêncio só aparece no dia em que alguém precisa restaurar |
Nenhuma dessas camadas é exclusiva do Proxmox. Em contrapartida, cada uma tem nome e endpoint próprios aqui. Se você quer o recorte agnóstico de plataforma, o catálogo de métricas de virtualização traz a visão comparada entre hypervisors.
Métricas do nó: CPU, IO delay, load average e memória
O nó é a camada mais barata de instrumentar e a mais ignorada. Coletar CPU e RAM todo mundo coleta. O problema aparece na interpretação: um host com metade da CPU ocupada pode estar perfeito ou à beira do colapso, dependendo do IO delay e do load average no mesmo intervalo.
Antes de tudo, colete o básico do host: uso de CPU por core, memória usada contra memória total, swap em uso, uptime e versão do PVE Manager. Em seguida, adicione temperatura e status SMART dos discos. Disco degradado antecede quase toda falha de storage local.
Vale ressaltar que o nó do Proxmox é um servidor Linux comum debaixo do hypervisor. Ou seja: as mesmas práticas de monitoramento de servidores físicos valem aqui, com uma camada extra de virtualização por cima.
Como ler IO delay e load average sem se enganar
O IO delay mede o tempo em que a CPU fica parada esperando o subsistema de disco responder. Cinco pontos percentuais já indicam storage limitando o host. Dez pontos sustentados fazem as VMs sentirem lentidão, mesmo com CPU sobrando no gráfico.
O load average conta processos na fila de execução em três janelas: 1, 5 e 15 minutos. A leitura correta compara o número com a quantidade de threads do host. Load 16 em um nó de 32 threads indica folga. O mesmo 16 em um nó de 8 threads indica fila.
Por isso, alerte sempre pela combinação, nunca pelo indicador isolado. CPU alta com IO delay baixo significa carga de processamento legítima. CPU moderada com IO delay alto significa gargalo de disco disfarçado de problema de CPU.
Métricas de VMs e containers LXC
VMs e containers compartilham a mesma lista curta: CPU, memória, disco I/O e rede. A diferença está em como cada um consome esses recursos. A VM QEMU carrega um sistema operacional inteiro e reserva memória. O container LXC divide o kernel do host e escala de forma bem mais elástica.
Na VM, acompanhe a memória alocada contra a memória efetivamente usada dentro do convidado. Sem o qemu-guest-agent instalado, o Proxmox enxerga apenas o consumo visto de fora, o que superestima o uso real e distorce qualquer decisão de rightsizing.
Por outro lado, no container LXC o ponto de atenção muda para os limites de cgroup. Um container que bate no teto de memória sofre OOM kill sem derrubar o host. O sintoma chega como serviço reiniciando sozinho, não como alerta de infraestrutura.
Em ambos os casos, monitore também o estado do objeto: rodando, parado, suspenso, em migração. Um dos erros mais comuns em auditoria é descobrir VM crítica desligada há semanas. Para a lista completa de indicadores por convidado, o guia de monitoramento de máquinas virtuais detalha cada métrica e seu limiar.
Storage: Ceph, ZFS e o que a interface esconde
Storage é a camada onde o Proxmox mais engana pela aparência. O resumo do datacenter mostra percentual de uso por datastore e para por aí. Ceph e ZFS, no entanto, têm estados internos que nunca aparecem naquela barra colorida.
No Ceph, monitore o estado dos OSDs, a distribuição dos placement groups e a latência de commit. O alerta que realmente importa é o nearfull: ao cruzar o limite padrão de ocupação, o cluster começa a bloquear escrita para proteger a integridade. Nesse ponto, VMs travam sem aviso prévio.
Da mesma forma, no ZFS acompanhe a taxa de acerto do ARC, o resultado do último scrub e o estado de cada dispositivo do pool. Um disco em DEGRADED mantém o pool funcionando, porém consome a redundância inteira. O segundo disco a falhar leva o dado junto.
Ainda assim, o indicador mais valioso não é instantâneo: é a tendência. Crescimento de 3% ao mês em um datastore significa saturação em pouco mais de um ano. Esse tipo de leitura pertence ao planejamento de capacidade e só existe com retenção de histórico maior que a do RRD nativo.
Cluster: quorum, corosync e o risco de fencing
O cluster do Proxmox se coordena pelo corosync, que exige quorum para autorizar qualquer operação de escrita na configuração compartilhada. Perdeu quorum, o nó entra em modo somente leitura. Com HA ativo, ele se autoexclui e reinicia, mesmo que a VM estivesse funcionando perfeitamente.
Monitore três sinais nessa camada. Primeiro, o estado do quorum e a contagem de nós ativos. Depois, a latência e a perda de pacotes no link dedicado do corosync. Por último, o estado do HA manager e da replicação de storage entre nós.
A latência do corosync merece atenção especial. O protocolo tolera muito pouco atraso. Por isso, um switch congestionado ou uma placa em modo de economia de energia derruba o cluster inteiro. Nesse caso, não existe falha real de hardware: o sintoma parece aleatório e a causa está na rede.
Cabe ressaltar um detalhe operacional: replicação atrasada não gera alarme nativo proporcional ao risco. Um job de replicação parado há dois dias significa dois dias de RPO perdidos. A operação de um cluster de virtualização depende dessa checagem contínua, não da inspeção manual eventual.
Backup: o Proxmox Backup Server também precisa de alerta
Backup é a camada mais negligenciada do monitoramento de Proxmox. O job roda de madrugada, envia email de resumo e ninguém lê. Quando a restauração falha, a descoberta chega junto com o incidente que motivou a restauração.
Por isso, monitore quatro itens do Proxmox Backup Server. O resultado do último job por VM, a duração da janela, a execução do verify e o espaço livre no datastore. Uma janela que cresce mês a mês avisa com bastante antecedência que ela vai invadir o horário comercial.
Nesse sentido, o verify merece destaque próprio. Ele valida a integridade dos chunks já gravados, algo que o simples sucesso do job não garante. Backup gravado com chunk corrompido aparece como sucesso na interface e falha na hora de restaurar.
Além disso, acompanhe a cobertura: quantas VMs existem no cluster contra quantas aparecem em algum job. VM nova criada fora do processo padrão fica sem backup por meses até alguém notar. Esse é o tipo de lacuna que só um item calculado detecta.
Como o Proxmox expõe métricas: API REST, pvesh e metric server
O Proxmox expõe tudo por três caminhos. Primeiro, a API REST em /api2/json na porta 8006. Depois, a CLI pvesh, que consome essa mesma API localmente. Por último, o metric server nativo, que empurra dados para um destino externo.
Qualquer ferramenta de mercado usa uma dessas três portas de entrada.
A API REST é a rota preferida das ferramentas agentless. Ela devolve JSON para cluster, nós, VMs, containers e storages, com autenticação por API token. Dessa forma, você monitora o ambiente inteiro sem instalar nada dentro dos hosts.
Usuário dedicado e API token somente leitura
Monitoramento nunca precisa de permissão de escrita. Crie um usuário próprio, associe a role PVEAuditor no path raiz e gere um token dedicado. Assim, o vazamento do segredo não vira comprometimento do ambiente.
Depois disso, valide a coleta antes de configurar a ferramenta. O pvesh consulta os mesmos endpoints que o coletor vai usar, o que separa problema de permissão de problema de configuração.
Metric server nativo: Graphite, InfluxDB e OpenTelemetry
O caminho mais leve dispensa coletor externo: o próprio PVE empurra as métricas para um destino.
Segundo a documentação oficial do servidor de métricas externo, o hypervisor suporta Graphite, InfluxDB e OpenTelemetry, com a definição gravada em /etc/pve/status.cfg.
Para quem prefere o modelo pull do Prometheus, o repositório oficial do exporter entrega métricas de cluster, nó, convidados e storage na porta 9221, também com acesso somente leitura.
Ferramentas de monitoramento de Proxmox comparadas
Não existe ferramenta melhor no absoluto. Existe a que combina com o tamanho do parque, com a maturidade do time e com a exigência contratual de SLA. A tabela abaixo compara as cinco abordagens que aparecem em ambientes reais.
| Stack | Esforço de setup | Onde costuma falhar | Perfil de ambiente |
|---|---|---|---|
| Console nativa e metric server | Baixo | Sem correlação, sem SLA e sem visão de parque misto | 1 a 5 nós com alerta reativo por email |
| Zabbix com template oficial | Médio | ZFS e verificação de backup exigem template complementar | Parque médio já padronizado na ferramenta |
| Prometheus, exporter e Grafana | Alto | Alerta, retenção longa e manutenção do stack ficam por sua conta | Times com engenharia dedicada de plantão |
| Checkmk com special agent | Médio | Um host por convidado exige disciplina rígida de nomenclatura | Ambientes que priorizam checagem de backup |
| Camada enterprise multi-vendor | Contrato | Custo de licença acima das opções abertas | Parque misto com SLA formal e relatório executivo |
Vale destacar que a escolha muda quando o Proxmox não é a única plataforma da casa. Em migrações pós-Broadcom, o cenário típico mantém VMware residual, Hyper-V remanescente e Proxmox crescendo ao mesmo tempo. Cada console mostra a própria verdade, sempre em nomenclatura diferente.
Nesse cenário, comparar disponibilidade entre plataformas vira trabalho manual de planilha. Quem já estruturou a visibilidade do ambiente VMware ou aplicou o mesmo raciocínio no monitoramento de Hyper-V conhece o problema: três ferramentas, três definições de indisponibilidade, nenhum número consolidado.
Por isso, organizações com SLA contratado combinam as duas coisas. A operação do dia a dia continua na console nativa de cada plataforma. Acima dela, uma camada de monitoramento em tempo real unifica alerta, correlação e relatório executivo.
Thresholds e runbooks que sustentam a operação
Alerta sem threshold calibrado vira ruído em duas semanas. Alerta sem runbook vira mensagem que ninguém sabe tratar. Os valores abaixo funcionam como ponto de partida na maioria dos ambientes Proxmox. Ainda assim, ajuste cada um deles depois de duas ou três semanas de baseline.
| Sinal monitorado | Atenção | Crítico |
|---|---|---|
| CríticoQuorum do cluster | 1 nó fora | Quorum perdido |
| AltoIO delay do nó | 5% por 10 min | 10% por 15 min |
| AltoUso de OSD ou datastore | 80% | 85% (nearfull) |
| MédioMemória do nó | 85% | 92% ou swap ativo |
| BaixoJob de backup por VM | 1 falha | 2 falhas seguidas |
Trate esses números como hipótese inicial. Um cluster com storage NVMe tolera IO delay muito menor antes de doer. Já um ambiente com discos SATA convive com valores mais altos sem impacto perceptível no usuário.
Quatro runbooks para os incidentes mais comuns
Perda de quorum. Verifique primeiro a rede do corosync, não os nós. Confirme latência e perda de pacote no link dedicado, cheque se algum switch reiniciou e só depois investigue o serviço em cada host. Fencing por rede é muito mais frequente que falha real de nó.
Coleta parada com nó saudável. Quando os gráficos congelam mas o host responde, o suspeito é o pvestatd. Reinicie o serviço no nó afetado e valide a volta dos dados. O ambiente segue funcionando durante a pane, o que faz a falha passar despercebida por dias.
OSD em nearfull. Não espere o bloqueio de escrita. Identifique o OSD mais cheio, avalie rebalanceamento e libere espaço com remoção de snapshot antigo. Em paralelo, revise a tendência de crescimento para decidir entre adicionar disco ou reduzir provisionamento.
Falha de backup ou replicação. Cheque espaço no datastore de destino antes de qualquer outra hipótese. Depois, valide a janela: job que passou a durar o dobro costuma indicar disco de destino degradado. Por fim, rode o verify manual para confirmar a integridade do que já está gravado.
Monitoramos sua infraestrutura 24×7, antes que o problema chegue ao usuário.
Detectamos falhas em servidores, aplicações e redes em tempo real com alertas inteligentes, dashboards e relatórios de SLA.
Conclusão
O monitoramento de Proxmox amadurece em três movimentos. Primeiro, sair do gráfico por objeto e enxergar as cinco camadas: nó, convidados, storage, cluster e backup. Depois, escolher o caminho de coleta que combina com o time. Ou seja: o metric server nativo, o template oficial de uma ferramenta consolidada ou um exporter com Prometheus.
Por último, calibrar threshold e escrever runbook. Sem essas duas peças, qualquer stack vira gerador de ruído em poucas semanas. A diferença entre um ambiente observável e um ambiente instrumentado está justamente aí: no que a equipe faz quando o alerta chega.
Vale lembrar que a maioria dos ambientes brasileiros que adotam Proxmox hoje não parte do zero. Eles convivem com plataformas legadas durante a transição e precisam sustentar o mesmo SLA de antes. Nesse contexto, a visão unificada deixa de ser conforto e vira requisito.
Se a sua operação chegou nesse ponto, fale com um especialista da OpServices para desenhar a camada de monitoramento do seu ambiente virtualizado.
Perguntas Frequentes
O Proxmox tem monitoramento nativo?
Qual é a melhor ferramenta de monitoramento para Proxmox?
pve_exporter e Grafana pela flexibilidade. Já ambientes com parque misto e SLA contratado precisam de uma camada enterprise multi-vendor, que unifica Proxmox, VMware e Hyper-V em um único painel.Quais permissões o usuário de monitoramento do Proxmox precisa ter?
pve e associa a role PVEAuditor no path raiz. Esse papel dá acesso de auditoria a cluster, nós, convidados e storages. Monitoramento nunca precisa de permissão de escrita, então evite reaproveitar contas administrativas ou o usuário root. Depois, gere um API token específico para a ferramenta: assim você revoga o acesso sem trocar senha e limita o impacto caso o segredo vaze.Como criar o API token para monitorar o Proxmox?
pveum no shell do nó. Primeiro crie o usuário com pveum user add monitor@pve. Depois conceda a role com pveum acl modify / --users monitor@pve --roles PVEAuditor. Por fim, gere o token com pveum user token add monitor@pve leitura --privsep 0. O segredo aparece uma única vez na saída, então guarde antes de fechar o terminal. A ferramenta de monitoramento consome esse token na API da porta 8006, sem agente instalado no host.O template oficial do Zabbix monitora backups e ZFS?
