Como monitorar recursos de VPS com Netdata

Tempo estimado: 15 a 25 minutos. Dificuldade: iniciante.

Neste guia, você vai instalar o Netdata em uma VPS Linux e abrir um dashboard de monitoramento em tempo real. O Netdata coleta métricas de CPU, memória, disco, rede, processos, systemd, containers e vários serviços sem exigir uma pilha complexa de observabilidade. Para uma primeira camada de visibilidade em uma VPS, ele costuma ser rápido de instalar e simples de interpretar.

O tutorial usa Ubuntu 22.04 ou 24.04 como base, mas os comandos principais também funcionam em Debian recente. Quando houver diferença relevante, ela será explicada. Se você ainda está avaliando o tamanho da máquina, leia também o guia sobre como escolher CPU, RAM e NVMe para VPS, porque monitoramento fica muito mais útil quando você sabe quais limites observar.

O que você vai aprender

Ao final do guia, você terá um painel funcional do Netdata e saberá validar se ele está coletando métricas corretamente. Você vai aprender a:

• Confirmar a distribuição Linux, o IP público e os recursos básicos da VPS.
• Atualizar pacotes com segurança antes da instalação.
• Instalar o Netdata usando o instalador oficial recomendado pelo projeto.
• Verificar o serviço com systemd, portas abertas e chamadas HTTP locais.
• Liberar a porta 19999 no UFW sem perder acesso SSH.
• Ajustar configurações básicas para reduzir exposição desnecessária.
• Testar CPU, RAM, disco e rede para ver métricas mudando no dashboard.

O Netdata não substitui planejamento de capacidade, logs de aplicação ou backups. Ele ajuda você a enxergar sintomas rapidamente. Por exemplo, se uma API começa a responder devagar, o painel mostra se há saturação de CPU, falta de memória, espera de disco ou tráfego anormal. Se sua VPS hospeda endpoints públicos, veja também as práticas descritas em VPS para API, pois monitoramento e disponibilidade caminham juntos.

Pré-requisitos

Você precisa de uma VPS com Ubuntu 22.04, Ubuntu 24.04 ou Debian 12, acesso SSH com um usuário que tenha sudo e pelo menos 1 GB de RAM. O Netdata é leve, mas ainda consome memória e CPU para coletar, armazenar e renderizar métricas. Em servidores muito pequenos, como máquinas com 512 MB, ele pode funcionar, mas você deve acompanhar o consumo depois da instalação.

Também tenha em mãos o IP público da VPS. Neste guia, usaremos 203.0.113.10 como IP de documentação. Na sua máquina, substitua pelo IP real do servidor. Esse endereço é reservado para exemplos e não deve ser copiado literalmente em regras de produção. Para descobrir o IP público a partir da VPS, você vai executar um comando no Passo 1.

Antes de alterar firewall ou serviços, mantenha uma sessão SSH aberta. Se possível, abra uma segunda sessão em outro terminal. Assim, se uma regra bloquear uma conexão nova, você ainda consegue corrigir pela sessão existente. Nenhum comando deste guia apaga dados de aplicação, mas alterações de firewall podem impedir acesso remoto quando aplicadas sem cuidado.

No seu computador local, você precisa de um navegador atualizado. O dashboard padrão fica em http://IP_DA_VPS:19999. Se a VPS estiver atrás de painel com firewall externo do provedor, você precisará liberar a porta 19999 também nesse painel. A diferença entre firewall local e regras do provedor aparece bastante em ambientes cloud. Se você quer entender essa camada, consulte Cloud Server vs VPS.

Passo 1: Preparar a VPS e confirmar o ambiente

Comece conectando na VPS por SSH. Use o usuário administrativo que você recebeu do provedor ou um usuário criado por você. O comando abaixo usa ubuntu, comum em imagens oficiais do Ubuntu. Troque pelo usuário correto se sua imagem usa root, debian ou outro nome.

ssh [email protected]

Na primeira conexão, o SSH pode pedir confirmação da chave do servidor. Digite yes somente se o IP estiver correto. Depois de entrar, confirme a distribuição e a versão do kernel:

cat /etc/os-release
uname -r

Você deve ver algo parecido com isto:

PRETTY_NAME="Ubuntu 24.04.1 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
6.8.0-41-generic

Agora verifique CPU, memória e disco. Esses dados ajudam você a comparar o que foi contratado com o que o sistema enxerga.

nproc
free -h
df -h /

Saída esperada em uma VPS pequena:

2
               total        used        free      shared  buff/cache   available
Mem:           1.9Gi       310Mi       1.2Gi        12Mi       420Mi       1.4Gi
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        39G  3.1G   36G   8% /

Atualize a lista de pacotes antes de instalar dependências. Esse comando não remove pacotes. Ele apenas atualiza índices e aplica correções disponíveis.

sudo apt update
sudo apt upgrade -y

Saída comum:

Reading package lists... Done
Building dependency tree... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Se o upgrade atualizar kernel ou bibliotecas críticas, o sistema pode sugerir reinicialização. Verifique com:

[ -f /var/run/reboot-required ] && cat /var/run/reboot-required || echo "Reboot não solicitado"

Se aparecer *** System restart required ***, planeje um reboot em janela segura. Para este guia, você pode continuar, mas reiniciar depois evita leituras inconsistentes de módulos antigos.

Passo 2: Instalar o Netdata com o instalador oficial

O método mais direto é usar o instalador oficial do Netdata. Ele detecta a distribuição, instala dependências e configura o serviço no systemd. Antes de executar scripts baixados da internet, confira a URL e use a documentação oficial como referência. Aqui você vai baixar com wget e executar com a opção --stable-channel, que prioriza versões estáveis.

Instale ferramentas básicas caso a imagem seja mínima:

sudo apt install -y curl wget ca-certificates gnupg

Saída esperada:

Reading package lists... Done
Building dependency tree... Done
ca-certificates is already the newest version
wget is already the newest version

Agora execute o instalador oficial:

wget -O /tmp/netdata-kickstart.sh https://my-netdata.io/kickstart.sh
sh /tmp/netdata-kickstart.sh --stable-channel --disable-telemetry

Durante a instalação, o script mostra as etapas e pode pedir confirmação. Leia a mensagem antes de aceitar. Em uma instalação normal, você verá algo similar a:

 --- Using /tmp/netdata-kickstart.sh temporary directory ---
 --- Checking for existing installations of Netdata ---
 --- Installing netdata ---
Successfully installed the Netdata Agent.
Netdata is running now!

A opção --disable-telemetry desativa telemetria anônima do instalador e do agente. Isso não impede o monitoramento local. Se você pretende conectar o agente ao Netdata Cloud no futuro, poderá revisar essa decisão depois.

Quando o instalador terminar, confirme o caminho do binário e a versão instalada:

command -v netdata
netdata -v

Você deve receber algo como:

/usr/sbin/netdata
netdata v2.1.0

A versão exata pode ser diferente, e isso é normal. O ponto principal é que o comando exista e retorne versão sem erro. Se aparecer command not found, volte ao log do instalador e procure mensagens de falha de dependência, DNS ou permissão.

Passo 3: Verificar o serviço e acessar localmente

Depois da instalação, o Netdata deve iniciar automaticamente como serviço do systemd. Antes de abrir firewall para a internet, valide localmente. Isso separa dois problemas diferentes: serviço parado e acesso bloqueado pela rede.

Confira o status:

sudo systemctl status netdata --no-pager

Saída saudável:

● netdata.service - Real time performance monitoring
     Loaded: loaded (/lib/systemd/system/netdata.service; enabled; preset: enabled)
     Active: active (running) since Sat 2026-08-31 12:20:10 UTC; 1min ago

Se Active estiver como active (running), o serviço está no ar. Agora veja se a porta padrão 19999 está escutando:

sudo ss -ltnp | grep 19999

Você deve ver uma linha semelhante:

LISTEN 0 4096 0.0.0.0:19999 0.0.0.0:* users:(("netdata",pid=1842,fd=6))

Em algumas instalações, o Netdata pode escutar apenas em 127.0.0.1:19999, principalmente após ajustes de segurança. Para o primeiro teste local, isso também funciona. Faça uma requisição HTTP dentro da própria VPS:

curl -I http://127.0.0.1:19999/

Resposta esperada:

HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: text/html; charset=utf-8

Se esse teste retornar 200 OK, o dashboard responde. Você também pode confirmar a API de métricas com:

curl -s http://127.0.0.1:19999/api/v1/info | head

Exemplo de saída:

{
   "version": "v2.1.0",
   "uid": "...",
   "mirrored_hosts": []
}

Não avance para a liberação pública se o teste local falhar. Corrigir o serviço primeiro economiza tempo e evita abrir porta sem necessidade.

Passo 4: Liberar acesso ao dashboard com firewall

Agora você vai permitir acesso ao dashboard pelo navegador. O Netdata usa a porta TCP 19999. Antes de adicionar regras, confirme o estado do UFW. Algumas imagens de VPS vêm com UFW desativado, enquanto outras já trazem regras básicas.

sudo ufw status verbose

Possíveis saídas:

Status: inactive

ou:

Status: active
Logging: on (low)
22/tcp                     ALLOW IN    Anywhere

Se o UFW estiver inativo e você quiser ativá-lo, libere SSH antes. Esse passo evita travar seu acesso remoto. Execute:

sudo ufw allow OpenSSH
sudo ufw allow 19999/tcp
sudo ufw enable

O UFW pedirá confirmação:

Command may disrupt existing ssh connections. Proceed with operation (y|n)?

Digite y somente depois de confirmar que OpenSSH foi liberado. Se o UFW já estiver ativo, basta adicionar a regra da porta 19999:

sudo ufw allow 19999/tcp
sudo ufw status numbered

Saída esperada:

Status: active

     To                         Action      From
[ 1] OpenSSH                    ALLOW IN    Anywhere
[ 2] 19999/tcp                  ALLOW IN    Anywhere

No navegador do seu computador, acesse:

http://203.0.113.10:19999

Troque 203.0.113.10 pelo IP real da VPS. Se o painel não abrir, teste a partir do seu computador local:

curl -I http://203.0.113.10:19999/

Resposta esperada:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8

Se sua VPS usa firewall do provedor, libere TCP 19999 também no painel externo. Para reduzir exposição, prefira liberar essa porta apenas para o seu IP residencial ou corporativo quando o provedor permitir regras por origem.

Passo 5: Ajustar segurança básica e retenção de métricas

O dashboard do Netdata mostra dados sensíveis sobre sua máquina, como nomes de processos, uso de disco, interfaces de rede e serviços ativos. Em ambiente de laboratório, abrir a porta para qualquer origem pode ser aceitável por poucos minutos. Em produção, restrinja o acesso. O ajuste mais simples no UFW é permitir a porta 19999 apenas a partir do seu IP público.

Descubra seu IP público no computador local acessando um serviço de consulta, ou rode este comando na própria VPS para ver o IP de saída dela:

curl -4 ifconfig.me; echo

Saída esperada:

203.0.113.10

No seu computador local, obtenha seu IP em um navegador ou terminal. Supondo que seu IP seja 198.51.100.25, remova a regra aberta e crie uma regra restrita. Atenção: confirme seu IP antes de remover a regra ampla. Uma regra errada pode bloquear seu acesso ao dashboard, embora não deva afetar SSH.

sudo ufw status numbered

Exemplo:

[ 1] OpenSSH                    ALLOW IN    Anywhere
[ 2] 19999/tcp                  ALLOW IN    Anywhere

Remova a regra ampla da porta 19999 pelo número mostrado. Este comando altera firewall, então confira a numeração antes de confirmar:

sudo ufw delete 2
sudo ufw allow from 198.51.100.25 to any port 19999 proto tcp
sudo ufw status numbered

Saída esperada:

[ 1] OpenSSH                    ALLOW IN    Anywhere
[ 2] 19999/tcp                  ALLOW IN    198.51.100.25

Agora faça um backup do arquivo principal de configuração antes de editar retenção e bind. Backup é simples e evita retrabalho:

sudo cp /etc/netdata/netdata.conf /etc/netdata/netdata.conf.bak.$(date +%F-%H%M)
ls -lh /etc/netdata/netdata.conf.bak.*

Saída esperada:

-rw-r--r-- 1 root root 58K Aug 31 12:45 /etc/netdata/netdata.conf.bak.2026-08-31-1245

Para editar configurações, use:

sudo nano /etc/netdata/netdata.conf

Procure a seção [db]. Em VPS pequena, uma retenção moderada reduz uso de RAM e disco. Configure, por exemplo:

[db]
    mode = dbengine
    retention = 3600

Depois reinicie e valide:

sudo systemctl restart netdata
sudo systemctl is-active netdata

Saída esperada:

active

Passo 6: Ler métricas principais no dashboard

Com o dashboard aberto, comece pelo gráfico de CPU. O Netdata separa uso por sistema, usuário, iowait, softirq e steal. Em VPS, steal merece atenção especial, porque indica tempo em que sua máquina virtual queria CPU, mas o hypervisor estava ocupado. Picos curtos podem acontecer. Valores sustentados altos sugerem contenção no nó físico ou carga acima do plano contratado.

Gere uma carga leve por alguns segundos para ver o gráfico reagir. Instale stress-ng:

sudo apt install -y stress-ng
stress-ng --cpu 1 --timeout 20s --metrics-brief

Saída esperada:

stress-ng: info:  [2401] setting to a 20 second run per stressor
stress-ng: info:  [2401] dispatching hogs: 1 cpu
stress-ng: metrc: [2401] stressor       bogo ops real time  usr time  sys time

No dashboard, observe CPU subindo durante cerca de 20 segundos. Em seguida, olhe memória. O Linux usa cache agressivamente, então used alto nem sempre significa problema. Foque em available, swap usada e eventos de OOM. Compare com free -h:

free -h

Saída esperada:

Mem: 1.9Gi 520Mi 920Mi 18Mi 620Mi 1.2Gi
Swap: 0B 0B 0B

Depois veja disco. Métricas de disk utilization, await e iowait ajudam a identificar gargalos. Faça um teste simples de escrita sem usar comandos destrutivos:

dd if=/dev/zero of=/tmp/netdata-test.img bs=64M count=4 oflag=direct status=progress
rm -f /tmp/netdata-test.img

Saída esperada:

268435456 bytes copied, 1.2 s, 224 MB/s

O arquivo criado fica em /tmp e é removido logo depois. Por fim, veja rede. Se sua VPS serve API, site ou painel administrativo, quedas de throughput e erros em interfaces podem apontar saturação, ataques ou limitação do provedor.

Verificação e testes

Agora faça uma validação completa, juntando serviço, porta, firewall e dashboard. Primeiro, confirme que o systemd mantém o Netdata ativo após reinício do serviço:

sudo systemctl is-enabled netdata
sudo systemctl is-active netdata

Saída esperada:

enabled
active

Valide a porta local:

curl -I http://127.0.0.1:19999/

Resultado esperado:

HTTP/1.1 200 OK

Valide a regra do firewall:

sudo ufw status verbose

Você deve ver SSH liberado e a porta 19999 conforme sua decisão de segurança. Em produção, a saída ideal restringe origem:

19999/tcp                  ALLOW IN    198.51.100.25
22/tcp                     ALLOW IN    Anywhere

Teste o endpoint externo a partir do seu computador local:

curl -I http://203.0.113.10:19999/

Se o IP de origem estiver autorizado, o retorno será 200 OK. Se você restringiu a porta a outro IP, o comando deve falhar por timeout, o que confirma que a restrição funciona.

Faça também um teste de coleta. Rode:

curl -s "http://127.0.0.1:19999/api/v1/data?chart=system.cpu&after=-10&points=2&format=json" | head

Saída esperada:

{
  "labels": ["time", "guest_nice", "guest", "steal", "softirq"]
}

Se você recebe JSON, o agente está entregando métricas. Abra o dashboard e confirme que os gráficos atualizam a cada segundo. Esse é o comportamento esperado para monitoramento em tempo real.

Troubleshooting

Problema 1: o dashboard não abre no navegador. Primeiro, descubra se o Netdata responde localmente. Execute curl -I http://127.0.0.1:19999/. Se retornar 200 OK, o serviço está saudável e o problema está em firewall local, firewall do provedor ou IP incorreto. Verifique sudo ufw status numbered e confirme se TCP 19999 está liberada para sua origem. Se a VPS tiver security group externo, libere a mesma porta no painel do provedor. Teste também curl -I http://IP_DA_VPS:19999/ a partir do seu computador.

Problema 2: o serviço aparece como failed. Veja os logs recentes:

sudo journalctl -u netdata -n 80 --no-pager

Procure mensagens como erro de permissão, arquivo de configuração inválido ou porta em uso. Se você editou netdata.conf, restaure o backup criado no Passo 5:

sudo cp /etc/netdata/netdata.conf.bak.2026-08-31-1245 /etc/netdata/netdata.conf
sudo systemctl restart netdata

Troque o nome do backup pelo arquivo real listado no seu servidor. Depois valide com sudo systemctl is-active netdata.

Problema 3: a porta 19999 não aparece no ss. Confirme se o processo está rodando:

ps aux | grep '[n]etdata'
sudo ss -ltnp | grep netdata

Se não houver processo, reinicie o serviço. Se houver processo, mas a porta for diferente ou estiver ligada apenas em 127.0.0.1, revise a configuração de bind no netdata.conf. Para acesso público controlado, o serviço precisa escutar em endereço acessível, e o firewall deve restringir a origem.

Problema 4: a VPS ficou mais lenta depois da instalação. Abra o próprio dashboard e observe CPU do processo netdata, uso de RAM e I/O. Em máquinas pequenas, reduza retenção em [db], desative coletores que você não usa e evite deixar muitas abas do dashboard abertas. Valide com free -h, top e sudo systemctl restart netdata após cada ajuste.

Próximos passos

Com o Netdata funcionando, defina uma rotina simples de acompanhamento. Durante alguns dias, observe horários de pico, consumo médio de memória, uso de disco e tráfego de rede. Essa linha de base ajuda você a diferenciar comportamento normal de incidente real. Se a VPS roda WordPress, API, banco de dados ou filas, compare métricas do sistema com logs da aplicação.

Depois, avalie alertas. O Netdata já inclui alarmes prontos para CPU, disco, memória e serviços comuns. Você pode integrar notificações com e-mail, Discord, Slack, Telegram ou outros canais suportados, dependendo da sua operação. Comece com poucos alertas. Alertas demais viram ruído e acabam ignorados.

Também pense em segurança de acesso. Para produção, o ideal é colocar o dashboard atrás de VPN, túnel SSH, proxy reverso com autenticação ou regra de firewall limitada ao seu IP. A porta 19999 aberta para toda a internet facilita testes, mas não é uma boa configuração permanente.

Por fim, use as métricas para tomar decisões. Se CPU vive em 90 por cento, talvez você precise otimizar processos ou subir de plano. Se memória disponível cai sempre antes de travamentos, revise workers, cache e swap. Se o disco mostra latência alta, investigue banco de dados e armazenamento. Monitorar não resolve sozinho, mas mostra onde agir primeiro.