Monitoramento leve de servidores para um VPS: Beszel vs Netdata vs Uptime Kuma vs Nezha (e quando você não precisa de nenhum)

15 de out. de 2026 · Termalin Team vpslinuxcomparisontoolshomelab

Para um monitoramento leve de servidores em um único VPS ou em alguns poucos, a lista honesta de candidatos é curta, e a escolha certa depende da pergunta que você está fazendo. Se você quer saber se as suas máquinas estão saudáveis, use o Beszel. Se você quer saber se os usuários conseguem abrir o seu site, use o Uptime Kuma. Para um painel de uma frota de VPS espalhada por regiões, use o Nezha; para uma única máquina agora mesmo, o Glances; e para detalhe por segundo durante um incidente, o Netdata. A maioria das pessoas precisa de uma dessas ferramentas, às vezes de duas, raramente de uma stack completa de observabilidade.

Transparência: nós desenvolvemos o Termalin, que é uma das opções abaixo. As ferramentas open source são descritas a partir da documentação pública delas, verificada em 15 de outubro de 2026, e várias delas vencem categorias inteiras.

Este post cobre o que cada ferramenta observa, quanto o “leve” realmente custa e as partes que os primeiros resultados pulam: quem monitora o monitor quando o próprio VPS morre, como evitar que os alertas virem ruído, um pequeno script de reserva, e como monitorar uma máquina sem nenhuma porta aberta.

A resposta curta: qual ferramenta para qual pergunta

Beszel — “as minhas máquinas estão bem?” Um hub mais um agente minúsculo por servidor. Métricas de host e estatísticas do Docker, com alertas para o Telegram e mais. O padrão leve.
Netdata — “o que aconteceu naquele segundo exato?” Métricas por segundo e detalhe profundo por processo. O mais faminto por dados aqui, o que é justamente o ponto.
Uptime Kuma — “o mundo lá fora consegue alcançar o meu serviço?” Verificações de HTTP, TCP, ping e DNS, com páginas de status. Ele não observa CPU, memória nem disco.
Nezha — “como está a minha frota de VPS, entre provedores e regiões?” Um painel no estilo sonda com um terminal web, popular para configurações multirregião.
Glances — “o que esta máquina está fazendo agora mesmo?” Uma visão ao vivo, como o htop ou o btop, com mais coisas na tela. Não é uma ferramenta de alertas.
Termalin — “monitore os meus servidores e me avise, sem nada a mais para instalar.” O monitoramento pega carona em um Connector de acesso SSH que você já tem. Pago, e com limites reais (abaixo).

O que “leve” realmente significa no monitoramento de servidores

“Leve” costuma ser citado como a memória do agente, que é o número errado. Conte o conjunto inteiro:

O agente em cada máquina — em geral um único binário compilado, pequeno por design.
O hub ou painel — é aqui que mora o peso: um app web, muitas vezes com um banco de dados, rodando em algum lugar que fica no ar.
Portas abertas — cada porta à escuta é superfície de ataque que agora é sua.
Contêineres e serviços a corrigir — mais uma coisa para manter atualizada, para sempre.

Por essa medida, o Beszel (um agente + um contêiner de hub) e o Uptime Kuma (um contêiner) são genuinamente leves. A coleta por segundo do Netdata é a mais faminta por recursos deste grupo, tanto em CPU quanto em armazenamento — é o preço da resolução dele. E a clássica “stack grande” — Prometheus mais node_exporter mais Grafana mais Alertmanager — são quatro peças móveis para implantar, proteger e manter atualizadas. Ela é excelente, mas não é leve, e para um a vinte servidores costuma ser mais do que o trabalho pede.

Os candidatos

Beszel

Um hub (construído sobre o PocketBase) mais um pequeno agente em Go em cada servidor. O agente pode funcionar de dois jeitos: o hub se conecta a ele por SSH na porta 45876, ou o agente disca para fora, até o hub, por um WebSocket com um token — o segundo modo não precisa de porta de entrada e funciona atrás de NAT. Ele lê métricas de host e estatísticas de contêineres Docker, e alerta sobre CPU, memória, disco, largura de banda, temperatura e status no ar/fora do ar, para mais de 25 canais, incluindo Telegram e ntfy. Licença MIT; a documentação está na v0.21 no momento em que isto é escrito. É a referência a bater para o simples “as minhas máquinas estão saudáveis”.

Netdata

Métricas por segundo, com um painel ao vivo denso e muito detalhe automático por processo e por serviço. O agente é grátis e roda sem limite nos seus próprios hosts, servindo o próprio painel localmente. O Netdata Cloud, que amarra os agentes e encaminha as notificações, é grátis no nível Community até 5 nós conectados; acima disso, é o Homelab a US$ 90/ano (sem limite, uso razoável) ou o Business a US$ 4,50/nó/mês cobrado anualmente. Recorra a ele quando estiver depurando um pico e uma média de um minuto for grossa demais.

Uptime Kuma

O monitor de disponibilidade self-hosted: verificações de HTTP(s), TCP, palavra-chave, ping, DNS, push e contêineres Docker, mais de 90 serviços de notificação e páginas de status públicas. Cerca de 92 mil estrelas no GitHub, licença MIT. A única coisa a deixar clara: o Uptime Kuma não coleta CPU, RAM nem disco do host — ele observa se os serviços respondem, de fora. Isso faz dele o parceiro natural de uma ferramenta de métricas de host, não um substituto, e a resposta de sempre para “uma alternativa self-hosted ao Uptime Kuma” é, na verdade, “junte o Kuma ao Beszel”.

Nezha

Um painel mais um agente que reporta o status do sistema, roda verificações de HTTP/TCP/ping e de expiração de certificado, dispara alertas, executa tarefas agendadas e dá a você um terminal web para cada host. O agente disca para fora, até o painel. É o painel de “sonda” (probe) de VPS de fato nas comunidades de língua chinesa e coreana, e brilha quando você tem muitos VPS pequenos entre provedores e regiões diferentes e quer uma única página para todos eles.

Glances (e htop/btop)

O Glances é uma visão ao vivo de uma única máquina: CPU, memória, disco, rede, processos e mais em uma só tela, por SSH ou em uma página web local opcional. Como o htop e o btop, ele responde “o que esta máquina está fazendo agora mesmo” e nada mais — não há histórico nem alertas de verdade. Mantenha-o na caixa de ferramentas para depuração na unha; não conte com ele para te avisar.

A tabela comparativa

Ferramenta	O que observa	Alertas e canais	Precisa de porta de entrada?	Custo	Melhor em
Beszel	Métricas de host + estatísticas do Docker	CPU/mem/disco/largura de banda/temp/status; mais de 25 canais (Telegram, ntfy)	Não no modo WebSocket; sim (`45876`) no modo SSH	Grátis, MIT (self-hosted)	Saúde de frota de forma leve
Netdata	Métricas de host, por segundo	Alarmes integrados; notificações via agente ou Cloud	Painel local na `19999`; o elo com o Cloud é de saída	Agente grátis; Cloud grátis até 5 nós, depois US$ 90/ano ou US$ 4,50/nó/mês	Detalhe de incidente em alta resolução
Uptime Kuma	Disponibilidade: HTTP/TCP/ping/DNS/push/contêineres (sem métricas de host)	Mais de 90 serviços; páginas de status	Alcança os alvos; você hospeda o painel dele	Grátis, MIT (self-hosted)	Disponibilidade externa + páginas de status
Nezha	Status do sistema + HTTP/TCP/ping + expiração de certificado	Alertas, tarefas agendadas; terminal web	Os agentes discam para fora, até o painel	Grátis (self-hosted)	Painel de VPS multirregião
Glances	Uma máquina, ao vivo	Não é uma ferramenta de alertas	Local; visão web opcional	Grátis (self-hosted)	Uma única máquina, agora mesmo
Termalin	Métricas de host pelo Connector (sem um segundo agente)	Alertas com limiares padrão; e-mail, push no iOS, Telegram, webhook	Não — o Connector é só de saída	Pro US$ 10/mês ou US$ 8/mês no plano anual; Team US$ 15/usuário	Saúde + alertas sem nada a instalar

Quem monitora o monitor quando o VPS morre?

Aqui está a lacuna que a maioria das comparações pula. Se o seu hub ou painel roda no mesmo VPS que ele está observando, ele morre junto com esse VPS — e um servidor morto não consegue avisar que está morto. “Servidor fora do ar” é exatamente o alerta que você mais quer, e ele só funciona a partir de um segundo ponto de observação.

Três formas de cobrir isso:

Um segundo VPS barato em outro local, rodando a verificação externa. É o que nós fazemos: rodamos o Uptime Kuma em um VPS de baixo custo à parte, cuja única função é notar quando as máquinas principais param de responder.
Um verificador externo grátis que pinga os seus endpoints públicos de fora da sua rede.
Um serviço hospedado cuja lógica de “está no ar?” roda em uma infraestrutura que não é sua e, assim, sobrevive à sua máquina cair.

Seja qual for a sua escolha, a regra é simples: a coisa que detecta o “fora do ar” não pode morar na máquina que sai do ar.

Alertas que não te ensinam a ignorá-los

Um monitor que te aciona dez vezes por hora acaba silenciado em uma semana — e aí é pior que nada. As ferramentas prontas tendem a ser ou silenciosas até você escrever regras, ou tagarelas até você ajustá-las. De um jeito ou de outro, o trabalho é o mesmo:

Uma mensagem quando um problema abre, uma quando ele se resolve — não um lembrete a cada cinco minutos.
Agrupamento — vários problemas no mesmo minuto chegam como uma só mensagem; um que seja de fato crítico ainda passa direto.
Sem repetições no mesmo dia para o mesmo problema, a menos que ele seja crítico e persista.
Um primeiro dia tranquilo, para que uma máquina recém-monitorada não despeje de uma vez todas as unidades já falhas e os certificados já expirados em cima de você.
Silenciar por alerta e por servidor, para que uma verificação barulhenta não te obrigue a silenciar tudo.

E escolha limiares que signifiquem algo: disco a 90% de aviso e 95% crítico, ou com previsão de encher em um dia; inodes se esgotando; uma morte por falta de memória (OOM kill); uma unidade do systemd que falhou; um certificado TLS a 14 dias da expiração (crítico a 3); e “fora do ar” só depois de alguns minutos, para que um reboot não seja um alarme. Seja qual for a ferramenta que você escolher, esse ajuste é o verdadeiro trabalho do monitoramento — mais do que escolher a ferramenta.

O último recurso em dez linhas: um alerta de espaço em disco para o Telegram

Antes de implantar qualquer coisa, você pode cobrir a falha de VPS mais comum de todas — um disco cheio — com cron, df e curl. Esta é a resposta para “script de alerta de disco cheio no Linux” e “bot do Telegram para monitorar servidor” quando você ainda não quer um painel.

Mantenha os segredos fora do script. Leia-os do ambiente:

#!/usr/bin/env bash
# disk-alert.sh — warn via Telegram when a filesystem is too full.
set -euo pipefail

: "${TELEGRAM_BOT_TOKEN:?set TELEGRAM_BOT_TOKEN}"
: "${TELEGRAM_CHAT_ID:?set TELEGRAM_CHAT_ID}"
threshold="${DISK_THRESHOLD:-90}"

df -x tmpfs -x devtmpfs --output=pcent,target | tail -n +2 | while read -r pct mount; do
  used="${pct%\%}"
  [ "$used" -ge "$threshold" ] || continue
  curl -fsS --max-time 15 \
    --data-urlencode "chat_id=${TELEGRAM_CHAT_ID}" \
    --data-urlencode "text=$(hostname): ${mount} is ${used}% full" \
    "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/sendMessage" >/dev/null
done

Coloque os valores reais em um arquivo acessível só pelo root, nunca no script nem no crontab:

# /etc/disk-alert.env  — chmod 600, owned by root
export TELEGRAM_BOT_TOKEN=123456789:replace-with-your-bot-token
export TELEGRAM_CHAT_ID=987654321
export DISK_THRESHOLD=90

Depois, rode-o a cada quinze minutos com o cron. Salve esta linha como /etc/cron.d/disk-alert (este formato, com um nome de usuário, é para arquivos em /etc/cron.d/):

*/15 * * * * root . /etc/disk-alert.env && /usr/local/bin/disk-alert.sh

Ele se repete a cada quinze minutos enquanto o disco continua cheio. Para um alerta de último recurso, isso é de propósito; se ficar barulhento demais, rode-o de hora em hora.

Crie um bot com o @BotFather, envie uma mensagem a ele para que ele possa te responder, e leia o seu chat_id uma vez em getUpdates. É isso tudo: sem agente, sem porta, sem painel. Não vai escalar além de algumas máquinas, mas vai pegar a falha que derruba a maioria dos VPS.

Monitorar atrás de NAT, CGNAT ou sem portas abertas

Uma máquina atrás de NAT ou CGNAT não consegue aceitar uma conexão de entrada, então qualquer monitor que funcione conectando-se à máquina está fora. Os que funcionam compartilham todos um mesmo formato — a máquina alcança para fora:

Beszel no modo WebSocket: o agente disca para fora, até o hub, sem porta de entrada. (O modo SSH precisa da 45876 de entrada, então evite-o aqui.)
Netdata: o elo do agente com o Netdata Cloud é de saída.
Uptime Kuma: use um monitor push — a máquina chama uma URL do Kuma em um cronograma, e o Kuma alerta quando as chamadas param.
Termalin: o Connector é só de saída e nunca fica à escuta em uma porta.

A técnica geral — e por que “deixe a máquina alcançar para fora” é a única resposta segura para uma máquina privada — está em SSH atrás de NAT sem encaminhamento de portas (em inglês), e a versão para home lab está em SSH em um NAS ou servidor doméstico.

Onde o Termalin se encaixa — e onde não

A abordagem do Termalin é diferente das ferramentas acima: ele não adiciona nenhum agente de monitoramento. Se um servidor já tem um Connector do Termalin — o mesmo agente de saída, sem porta de entrada, que você usa para o acesso SSH sem chave —, então ele já está monitorado. Não há um segundo agente: uma vez por minuto o Termalin roda alguns comandos somente leitura (/proc, df, ps e afins) pela conexão que o Connector já mantém. O custo para a máquina é de alguns milissegundos de CPU e cerca de um kilobyte por minuto.

O que ele lê é o retrato de saúde de sempre: CPU (incluindo iowait e steal), carga e pressão, memória e swap, espaço em disco e inodes, I/O de disco e de rede, sockets e arquivos abertos, processos, contêineres, serviços com falha, logins SSH malsucedidos, atualizações de segurança pendentes, portas à escuta e certificados TLS com os dias até a expiração. Os alertas funcionam com limiares padrão e sem regras a escrever, e são feitos para ficar quietos: uma vez ao entrar, uma vez ao sair, agrupados, sem repetições no mesmo dia, um primeiro dia tranquilo e silenciar por alerta. Eles vão para e-mail, push no iOS, Telegram (um toque para conectar o bot) e um webhook que o Slack e o Discord aceitam, assinado com HMAC-SHA256. O histórico é de 90 dias no Pro e de dois anos no Team.

Como um assistente de IA pode ler os mesmos dados pelo endpoint MCP hospedado do Termalin (server_metrics e alerts_list), você também pode simplesmente perguntar “como estão os meus servidores?” no Claude ou no ChatGPT e obter a resposta a partir dos dados coletados. No terminal web, selecione um erro na saída e escolha Explicar a seleção: o assistente escreve um diagnóstico curto em linguagem simples e termina com alguns comandos de verificação somente leitura que um botão digita na sessão por você. O quadro completo está na página de monitoramento de servidores.

Agora os limites, sem rodeios, porque as ferramentas open source o superam em vários deles:

Sem verificações de disponibilidade externas e sem páginas de status. Esta é uma ferramenta de métricas de host e alertas, não um monitor de disponibilidade — o Uptime Kuma ainda o complementa.
Sem coleta de logs e sem métricas personalizadas. Não é um substituto para Grafana/Prometheus.
Os painéis ficam só no painel web por enquanto, não no app de desktop — embora o app de desktop mostre ao vivo a CPU, a memória e o disco de um host conectado na barra de status dele e na grade de monitoramento (em inglês).
Sem criptografia de ponta a ponta — esses números ficam guardados de uma forma que o serviço consegue ler, porque ele precisa lê-los para desenhar os gráficos e disparar os alertas.
Não está no plano Free. Ele precisa de um Connector, que faz parte do Pro (US$ 10/mês, ou US$ 8/mês no plano anual — US$ 96/ano) e do Team (US$ 15 por usuário), com 14 dias de teste do Pro que não pedem cartão.

Se “grátis e self-hosted” for um requisito inegociável, o Beszel ou o Uptime Kuma é a sua resposta, e essa é uma escolha justa. O caso do Termalin é mais estreito: você já o usa para acesso SSH e prefere não subir e ficar cuidando de uma stack de monitoramento separada só para ter gráficos de saúde e alertas sensatos.

Escolhas por situação

Um VPS de hobby. Beszel para a saúde, ou só o script de cron acima se tudo o que você teme é um disco cheio. Adicione o Uptime Kuma mais tarde se você tiver um site público.
De 5 a 20 VPS entre provedores (Hetzner, Contabo, Hostinger, um droplet ou dois). Beszel para métricas mais Uptime Kuma para disponibilidade, com a instância do Kuma em uma máquina separada. Se você prefere um painel único com um terminal web, o Nezha. Se você já usa o Termalin para SSH, ligue o monitoramento dele e dispense a stack extra.
Um home lab atrás de CGNAT. Qualquer coisa só de saída: Beszel no modo WebSocket, Netdata para o Cloud, ou um monitor push do Kuma — veja o guia de SSH atrás de NAT (em inglês).
“Quero que o meu assistente de IA responda ‘como estão os meus servidores’.” Esse é o caso do Termalin: os mesmos dados que um humano vê, lidos pelo agente por MCP.

Perguntas frequentes

O Netdata é grátis? O agente é grátis e roda sem limite nos seus próprios hosts, com o próprio painel local. O nível Community do Netdata Cloud é grátis até 5 nós conectados; além disso, é o Homelab a US$ 90/ano ou o Business a US$ 4,50/nó/mês cobrado anualmente.

O Uptime Kuma monitora CPU, memória ou disco? Não. O Uptime Kuma verifica se os serviços respondem — HTTP, TCP, ping, DNS, contêineres e push — de fora. Para CPU, RAM e disco do host, combine-o com o Beszel, o Netdata ou o Termalin.

Beszel vs Netdata — qual é mais leve? O Beszel. É um pequeno agente por máquina mais um único hub. O Netdata coleta por segundo e é o mais faminto por recursos deste grupo; você o escolhe pela resolução, não por ser leve.

Qual é o melhor monitoramento de VPS grátis com alertas no Telegram? Para a saúde do host, o Beszel envia para o Telegram e é grátis para auto-hospedar. Para disponibilidade, o Uptime Kuma também. Para um paliativo sem instalação, o script de cron + curl acima envia direto para o Telegram, sem nada rodando em segundo plano.

Como eu monitoro um VPS atrás de NAT ou sem portas abertas? Use uma ferramenta em que a máquina alcança para fora: o Beszel no modo WebSocket, o agente do Netdata para o Cloud, um monitor push do Kuma, ou um Connector do Termalin. Nenhum deles precisa de porta de entrada. Veja SSH atrás de NAT sem encaminhamento de portas (em inglês).

O Termalin é um cliente SSH multiplataforma; no Pro e no Team, todo servidor que tem um Connector é monitorado com gráficos e alertas de limiar padrão, e nada a mais é instalado na máquina — veja monitoramento de servidores ou baixe o app.