Como monitorar uma VPS 24 horas: alertas, uptime e métricas

Resposta rápida: para monitorar uma VPS 24 horas por dia, combine quatro camadas: um monitor de disponibilidade rodando fora da VPS (como o Uptime Kuma), métricas de CPU, RAM, disco e rede com histórico (Netdata ou Prometheus com Grafana), heartbeat para tarefas agendadas como backup e alertas com limites claros enviados a um canal que alguém realmente lê, como Discord ou Telegram.

As quatro camadas do monitoramento

• Disponibilidade: o serviço responde para quem está de fora? Checagem HTTP, TCP ou ping feita de outra máquina, em intervalos curtos.
• Recursos: a máquina tem folga? CPU, memória, disco e rede com histórico.
• Serviços: os processos importantes estão de pé? Serviços do systemd, containers, banco, filas.
• Tarefas e prazos: o que deveria rodar em horário marcado rodou? Backup, cron, renovação de certificado.

O erro mais comum é cobrir só a primeira. O site tem monitor de uptime, então ninguém percebe que o disco passou de 85% na semana anterior, até o banco parar de gravar. Ou o backup falha toda madrugada, em silêncio, até o dia em que alguém precisa dele.

Métricas e limites de alerta

Use os limites abaixo como ponto de partida por duas semanas e ajuste: o limite certo é o que teria avisado nos incidentes passados e ficado quieto nos dias normais.

Em discos pequenos, como 20 GB, prefira alertar por GB livres: 10% são só 2 GB, e um log descontrolado consome isso em poucas horas.

Disponibilidade vista de fora

Regra de ouro: o monitor de disponibilidade não pode morar na máquina que ele vigia. Se a VPS travar ou perder a rede, o monitor cai junto, e o silêncio parece boa notícia. As opções:

• Uma VPS pequena só para monitorar, rodando o Uptime Kuma e checando as outras máquinas.
• Um serviço externo de uptime, útil como segunda opinião, porque checa a partir de outras redes.
• Os dois juntos, para cobrir detalhes e problemas de rota.

O Uptime Kuma é gratuito e roda em Docker:

sudo docker run -d --restart=always -p 3001:3001 \
  -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1

O :1 fixa a versão principal 1; confira na página oficial do projeto se já existe uma versão principal mais nova antes de instalar. Acesse http://IP_DA_VPS:3001, crie o administrador e, depois, publique o painel por um domínio com HTTPS. Se ainda não tem Docker, veja como instalar Docker.

Um monitor HTTP que só confere o código 200 pode passar enquanto a aplicação mostra uma página de erro. Prefira checar uma palavra-chave que só aparece quando a página carregou de verdade, ou uma rota /health que testa o banco. Para servidores de jogos, banco e SSH, use checagem de porta TCP.

Recursos, serviços e histórico

Para recursos, o Netdata instala em minutos e já vem com alertas prontos, ótimo para uma ou poucas VPS; veja o guia de htop e Netdata. Para várias máquinas, Prometheus com node_exporter e Grafana centraliza tudo e guarda histórico longo. Guarde pelo menos 15 a 30 dias: a pergunta mais útil em um incidente é "desde quando?".

Para serviços, faça o próprio systemd religar o que cair, adicionando à unidade da sua aplicação:

[Service]
Restart=on-failure
RestartSec=5

Reinício automático resolve o sintoma, não a causa. Acompanhe as falhas:

systemctl --failed
journalctl -u minha-app -p err --since "1 hour ago"

Backup, cron e certificado: heartbeat

As piores falhas não fazem barulho. A solução é inverter a lógica com heartbeat: em vez de o monitor perguntar, a própria tarefa avisa que rodou. Se o sinal não chegar no tempo esperado, o alerta dispara. O monitor do tipo Push do Uptime Kuma faz exatamente isso:

#!/usr/bin/env bash
set -euo pipefail
/usr/local/sbin/meu-backup.sh
# só chega aqui se o backup terminou sem erro
curl -fsS -m 10 --retry 3 "https://status.seu-dominio.com.br/api/push/SEU_TOKEN?status=up&msg=OK" > /dev/null

Com set -e, qualquer erro interrompe o script antes do curl. E, se o script nem rodar, o sinal também não chega e o alerta dispara. Para montar o backup, veja backup automático com rsync. Para certificados, ative o aviso de expiração no monitor HTTP e rode de vez em quando sudo certbot renew --dry-run.

Alertas que só tocam quando precisa

• Dois níveis: crítico acorda alguém (serviço fora, disco acima de 90%); aviso vai para um canal lido no horário comercial.
• Confirmação: 2 ou 3 falhas seguidas antes de avisar, com checagem a cada 30 a 60 segundos.
• Aviso de recuperação: avise quando voltar, para ninguém investigar algo já resolvido.
• Janela de manutenção: pause os alertas em atualizações planejadas, em vez de desligar o monitor e esquecer.
• Canal certo: Discord ou Telegram da equipe no dia a dia, e-mail como registro. Nunca o canal público da comunidade.

Todo alerta precisa de um dono e de um primeiro passo escrito. Exemplo: "disco acima de 90%: rodar du na raiz, conferir logs e imagens do Docker". Às 3h da manhã, ninguém raciocina bem sem roteiro. E teste o alerta: pare um serviço de propósito em um horário tranquilo e cronometre quanto tempo a notificação leva para chegar.

Ferramentas para cada tamanho

Onde rodar o monitoramento na RoxyCloud

O servidor de monitoramento precisa de pouca CPU, memória estável e, acima de tudo, ficar de pé quando as outras máquinas caem. Uma VPS Xeon pequena e separada das aplicações faz isso bem: a de 2 GB roda o Uptime Kuma e um Prometheus para poucas máquinas, e a de 4 GB acomoda também o Grafana com 30 dias de histórico.

Um cuidado honesto: uma VPS de monitoramento no mesmo datacenter detecta queda de serviço, travamento e falta de recurso, mas não enxerga um problema de rota entre o datacenter e os seus usuários. Para essa camada, mantenha também uma checagem a partir de outra rede. A infraestrutura da RoxyCloud, no datacenter próprio em Presidente Prudente (SP), tem monitoramento 24/7 por parte da equipe; o monitoramento descrito aqui cobre a sua aplicação, que é responsabilidade de quem administra a VPS.

Perguntas frequentes