Como monitorar Proxmox VE com o PRTG

A virtualização mudou de plataforma, e o monitoramento precisa acompanhar. Os sensores de VMware deixam de fazer sentido, as máquinas virtuais passam a morar em outro hipervisor, e o painel que avisava quando um host apertava ficou cinza. A Global Data, empresa de TI em São Paulo, é Gold Partner da Paessler, e a nossa equipe opera Proxmox VE em produção. Este guia mostra como montar o monitoramento de Proxmox VE no PRTG, da credencial no Proxmox aos alertas.

Se a migração ainda está em curso, o roteiro dela está em migração de VMware para Proxmox VE: etapas, janela e o que costuma dar errado, e o que precisa estar medido antes, durante e depois da troca, em monitoramento e backup na migração de virtualização. Este texto parte do ponto em que o ambiente já roda.

O que muda no monitoramento quando o hipervisor muda

O que se vigia continua o mesmo: o host que fica sem memória, a máquina virtual que parou, o disco que enche, o cluster que perde um nó, o backup que falhou de madrugada. O que muda é o caminho. No Proxmox VE, o PRTG busca essas informações pela API do próprio Proxmox, com sensores nativos, e completa com sensores SSH que leem o sistema operacional dos hosts. Duas coisas ficam de fora dos sensores nativos, o ZFS e o Proxmox Backup Server, e para elas o caminho é outro.

Um ponto de versão antes de tudo. Os quatro sensores nativos de Proxmox VE chegaram ao PRTG como beta, junto das versões 3.6.1 e 3.8.0 da probe multiplataforma, no início de 2026. Segundo a Paessler, eles passaram a ter suporte completo no PRTG 26.3.122. Quem roda uma versão anterior encontra os mesmos sensores marcados como beta, e precisa habilitar os recursos experimentais para vê-los. Atualizar o PRTG antes de montar o monitoramento evita trabalhar com sensor em fase de teste.

Preparar o Proxmox VE: um token de API somente leitura

Os sensores nativos conversam com a API do Proxmox VE, na porta 8006, e se autenticam com um token de API. Segundo o manual do PRTG, o usuário dono do token precisa ter o papel PVEAuditor ou superior. O PVEAuditor é o papel somente leitura do Proxmox, e é ele que basta: monitoramento lê, não altera.

O detalhe que derruba a primeira tentativa é a separação de privilégios. No Proxmox VE, um token novo nasce, por padrão, com privilégios separados: as permissões efetivas são a interseção entre as do usuário e as do próprio token, e o token precisa receber a permissão de forma explícita. Dar o papel só ao usuário não basta.

Pela linha de comando de um nó, o caminho segue o exemplo da documentação do Proxmox (troque o usuário e o nome do token pelo padrão da sua empresa):

pveum user add monitor@pve
pveum acl modify / -user monitor@pve -role PVEAuditor

pveum user token add monitor@pve prtg -privsep 1
pveum acl modify / -token 'monitor@pve!prtg' -role PVEAuditor

A permissão na raiz (/) dá ao token leitura do ambiente inteiro, que é o que o monitoramento precisa. O terceiro comando exibe o segredo do token uma única vez: copie antes de fechar o terminal.

No PRTG, crie o dispositivo com o endereço do nó e, nas configurações, preencha a seção Credentials for Proxmox: o API Token ID no formato usuário@realm!token (no exemplo, monitor@pve!prtg), o API Token Secret com o segredo copiado e a porta, que por padrão é 8006. Para um cluster com vários nós, coloque a credencial no grupo e deixe os dispositivos herdarem.

Os quatro sensores nativos de Proxmox VE

Os sensores exigem Proxmox VE 6.2 ou superior. Três deles são criados sobre um nó do cluster; o de saúde do cluster, sobre o dispositivo que representa o cluster.

Proxmox VE Node Performance. O desempenho do host: carga média (o canal principal), uso de CPU, memória disponível e em uso, espaço em disco e tempo ligado. É o sensor que responde se o nó aguenta a carga que está recebendo.

Proxmox VE Virtual Machine Status. Um sensor por máquina virtual QEMU/KVM, com estado, uso de CPU, memória alocada e usada e leitura e gravação em disco. O canal de estado é o principal: é o que avisa quando a máquina parou.

Proxmox VE Container Status. O equivalente para contêineres LXC. Contêiner em execução aparece como normal; contêiner parado aparece como aviso.

Proxmox VE Cluster Health. A saúde do cluster: se há quórum (o canal principal), quantos nós existem, quantos estão ativos e a porcentagem de nós online, que já vem com limites predefinidos. Se o cluster usa Ceph, o sensor traz também o estado do Ceph.

Camada	Sensor	Situação no PRTG
Cluster	Proxmox VE Cluster Health	Suporte completo desde o PRTG 26.3.122
Nó (host)	Proxmox VE Node Performance	Suporte completo desde o PRTG 26.3.122
Máquina virtual	Proxmox VE Virtual Machine Status	Suporte completo desde o PRTG 26.3.122
Contêiner	Proxmox VE Container Status	Suporte completo desde o PRTG 26.3.122
Sistema operacional do host	SSH Disk Free v2, SSH Load Average v2, SSH Meminfo v2, SSH INodes Free v2	Estável
Disponibilidade	Ping	Estável
ZFS	Sem sensor nativo	Alerta pelo ZED do próprio Proxmox
Backup	Sem sensor nativo para Proxmox Backup Server	Notificação do próprio Proxmox

Hosts: os sensores SSH que completam a visão

O sensor de desempenho do nó mostra o que o Proxmox informa sobre o host. Os sensores SSH leem direto do sistema operacional e servem de segunda fonte, além de cobrir o que a API não detalha, como o espaço de cada sistema de arquivos e os inodes. Use as versões v2: o manual do PRTG marca os sensores SSH antigos como descontinuados, sem criação nova a partir das versões 26.x mais recentes. Os sensores v2 usam as credenciais de Linux por SSH do dispositivo.

Para quem ainda tem servidores de outras plataformas no mesmo painel, o vídeo antigo de como monitorar servidores Windows, Linux, VMware e XenServer mostra a lógica geral da ferramenta.

ZFS e backup: o que vigiar fora dos sensores nativos

O PRTG não tem sensor nativo de ZFS. Quem usa ZFS nos nós tem um aliado no próprio Proxmox: segundo a documentação, o ZFS traz um serviço de eventos, o ZED, que pode mandar e-mail em eventos como erro no pool, e o pacote já vem instalado por padrão. O endereço de destino fica em /etc/zfs/zed.d/zed.rc, no parâmetro ZED_EMAIL_ADDR, que por padrão aponta para o root. Apontar esse endereço para a caixa de alertas da equipe é a primeira coisa a fazer depois de criar o pool. A API do Proxmox também expõe os pools ZFS de cada nó, e o sensor genérico REST Custom v2 do PRTG consulta endpoints JSON com cabeçalho de autenticação, o que abre espaço para um sensor próprio.

O backup segue a mesma lógica. O PRTG não tem sensor para o Proxmox Backup Server, e o aviso de tarefa de backup que falhou vem do sistema de notificações do próprio Proxmox VE, que desde a versão 8.1 envia por SMTP e para o Gotify e, desde a 8.3, também por webhook. A documentação mostra como filtrar só as falhas de backup, que aparecem como eventos do tipo vzdump com severidade de erro. O Proxmox Backup Server tem o próprio sistema de notificações, com os mesmos tipos de destino. Para quem faz o backup com Acronis, a Acronis registra, nas notas de versão do Cyber Protect Cloud 25.07, o backup sem agente dentro das máquinas para Proxmox VE 8.2 ou superior, com um agente em cada nó do cluster.

Nenhum backup fica provado por notificação de sucesso. A restauração de teste é que confirma, e é o ponto em que o monitoramento termina e a rotina começa.

Alertas e dependências

A primeira semana de monitoramento serve para conhecer o comportamento normal de cada nó, e só depois os limites de aviso e erro de CPU, memória e carga devem ser ajustados. O canal de quórum do cluster é a exceção: perda de quórum é incidente desde o primeiro dia.

As dependências evitam a cascata. Se um nó cair, os sensores das máquinas virtuais dele vão todos para erro ao mesmo tempo. Configurar o ping do nó como dependência dos sensores das VMs e dos contêineres faz chegar um alerta em vez de vinte. A calibragem fina, com atraso, repetição e escalonamento, segue o roteiro de alertas inteligentes no PRTG para evitar falsos positivos, e o mesmo raciocínio de dependência aparece no monitoramento de firewall SonicWall com o PRTG, que costuma ficar no mesmo painel.

Implantação, na ordem:

1. Atualizar o PRTG para a versão 26.3.122 ou posterior, ou habilitar os recursos experimentais numa versão anterior.
2. Criar no Proxmox VE o usuário e o token com o papel PVEAuditor, dando a permissão também ao token.
3. Criar o dispositivo no PRTG e preencher as credenciais de Proxmox no grupo do cluster.
4. Adicionar o Cluster Health ao cluster e o Node Performance a cada nó.
5. Adicionar os sensores de estado das máquinas virtuais e dos contêineres que sustentam sistema de negócio.
6. Completar os hosts com os sensores SSH v2 de disco, carga, memória e inodes.
7. Configurar o e-mail do ZED nos nós com ZFS e as notificações de falha de backup no Proxmox.
8. Definir as dependências de cada VM em relação ao seu nó.
9. Ajustar os limites depois de uma ou duas semanas de coleta.

Quando passar o monitoramento para a Global Data

O monitoramento montado é o começo. Depois dele vêm as VMs novas que precisam entrar no painel, os limites que mudam com a carga, a atualização do PRTG e do Proxmox e o alerta que chega às três da manhã.

No monitoramento de rede com PRTG da Global Data, essa operação fica com a nossa equipe. E quando a pergunta é a própria plataforma, do desenho do cluster à operação dos hosts, a página de virtualização de servidores mostra como trabalhamos.

Perguntas frequentes

O PRTG monitora Proxmox VE?

Sim. O PRTG tem quatro sensores nativos de Proxmox VE: desempenho do nó, estado de máquina virtual, estado de contêiner e saúde do cluster. Segundo a Paessler, eles têm suporte completo desde o PRTG 26.3.122; em versões anteriores, aparecem como beta e dependem dos recursos experimentais.

Que permissão o PRTG precisa no Proxmox?

Um token de API cujo usuário tenha o papel PVEAuditor ou superior, que é somente leitura. Como o token do Proxmox nasce com privilégios separados, a permissão precisa ser dada também ao token, não só ao usuário.

Os sensores de Proxmox ainda estão em beta?

Não a partir do PRTG 26.3.122, quando a Paessler os passou para suporte completo. Quem usa uma versão anterior do PRTG ainda os encontra como beta.

O PRTG monitora ZFS e Proxmox Backup Server?

Não há sensor nativo para nenhum dos dois. O ZFS avisa erros por e-mail pelo ZED, que vem instalado no Proxmox, e as falhas de backup são avisadas pelo sistema de notificações do Proxmox VE e do Proxmox Backup Server.

Que versão do Proxmox VE os sensores exigem?

Proxmox VE 6.2 ou superior, segundo o manual do PRTG.

Se a sua empresa migrou para Proxmox VE e o monitoramento ainda não acompanhou a troca, o primeiro passo é levantar o que precisa ser vigiado. Quero monitorar o nosso ambiente Proxmox VE