---
title: "Como monitorar uma VPS 24 horas: métricas, alertas e uptime"
description: "Monte o monitoramento 24 horas da VPS: uptime externo, CPU, RAM, disco e rede, limites de alerta, heartbeat de backup e ferramentas para cada tamanho."
url: "https://streethosting.com.br/guias/vps/monitorar-vps-24-horas"
category: "vps"
slug: "monitorar-vps-24-horas"
datePublished: "2026-09-28"
dateModified: "2026-09-28"
author: "Equipe StreetHosting"
difficulty: "intermediario"
language: "pt-BR"
keywords:
  - "monitorar vps 24 horas"
  - "monitoramento de servidor linux"
  - "alertas vps cpu ram disco"
  - "ferramentas de monitoramento vps"
  - "monitorar servidor 24 horas"
---

# Estratégia de monitoramento contínuo para VPS: o que medir e quando alertar

Um monitor de uptime sozinho não avisa que o disco está enchendo nem que o backup parou há três semanas. Veja como combinar disponibilidade, recursos, tarefas agendadas e alertas em uma rotina que funciona dia e noite.

> **Resposta rápida**
>
> Para **monitorar uma VPS 24 horas por dia**, combine quatro camadas: um monitor de disponibilidade rodando fora da VPS, métricas internas de CPU, RAM, disco e rede com histórico, heartbeat para tarefas agendadas como backup e cron, e alertas com limites claros enviados a um canal que alguém realmente lê. Uptime Kuma fora da máquina, mais Netdata ou Prometheus com Grafana dentro dela, cobrem a maior parte dos casos.

## As quatro camadas do monitoramento

Monitorar não é instalar uma ferramenta. É responder a quatro perguntas diferentes, e cada uma pede um tipo de checagem. Quem cobre só uma delas descobre as outras falhas pela reclamação do cliente.

- **Disponibilidade:** o serviço responde para quem está do lado de fora? Check HTTP, TCP ou ping executado a partir de outra máquina, em intervalos curtos.
- **Recursos:** a máquina tem folga? CPU, memória, disco, I/O e rede com histórico, para saber se o problema é de agora ou vem crescendo há dias.
- **Serviços:** os processos que importam estão de pé? Unidades do systemd, containers, banco de dados, fila de jobs.
- **Tarefas e prazos:** o que deveria acontecer em horário marcado aconteceu? Backup, rotinas do cron, renovação de certificado.

O furo mais comum é cobrir a primeira camada e parar aí. O site tem monitor de uptime, então ninguém percebe que o disco passou de 85% na semana anterior; ele só aparece quando o banco para de gravar e o site cai. Ou o backup falha toda madrugada por três semanas, em silêncio, até o dia em que alguém precisa dele. As próximas seções tratam cada camada com o que medir, onde medir e a partir de quando avisar.

## Métricas e limites de alerta

Os limites abaixo são pontos de partida razoáveis para uma VPS Linux com aplicação web, bot ou servidor de jogo. Use por duas semanas, compare com o histórico e ajuste: o limite certo é o que teria avisado nos incidentes passados e ficado quieto nos dias normais.

| Métrica | Aviso | Crítico | Por que importa |
| --- | --- | --- | --- |
| Resposta HTTP ou porta TCP | Tempo de resposta três vezes acima do normal | Três falhas seguidas | Confirmar a falha evita alarme por oscilação de um segundo |
| CPU em uso | Acima de 85% por 15 minutos | Acima de 95% por 30 minutos | Pico curto é normal; saturação sustentada não |
| Load average de 5 minutos | Acima do número de vCPU por 15 minutos | Acima do dobro do número de vCPU | Mostra fila de processos esperando CPU ou disco |
| CPU steal | Acima de 5% por 15 minutos | Acima de 10% de forma recorrente | Indica disputa pelo processador físico do host |
| Memória disponível | Abaixo de 15% | Abaixo de 5% ou swap crescendo | Perto do fim, o OOM killer encerra processos |
| Disco, espaço usado | Acima de 80% | Acima de 90% | Banco e logs param de gravar com o disco cheio |
| Disco, inodes usados | Acima de 80% | Acima de 90% | Milhões de arquivos pequenos esgotam inodes antes do espaço |
| Latência de disco | Espera média acima de 20 ms | Acima de 100 ms por vários minutos | Em NVMe, poucos milissegundos é o esperado |
| Rede | Tráfego sustentado acima de 70% do uplink | Perda de pacotes no check externo | Transferência grande ou ataque saturam o link |
| Certificado TLS | Menos de 14 dias para expirar | Menos de 7 dias | Sinal de renovação automática que falhou |
| Backup | Nenhum sucesso em 26 horas | Nenhum sucesso em 48 horas | Rotina diária que parou de rodar |

Duas métricas merecem atenção especial em VPS. A primeira é o load average, que só faz sentido comparado ao número de vCPU: load 4 é tranquilo em 8 vCPU e é gargalo em 2. A segunda é o steal, o tempo em que a máquina virtual quis CPU e esperou o hipervisor. Ele não aparece em máquina física e é o primeiro número a olhar quando a VPS fica lenta sem nenhum processo pesado à vista. O assunto está detalhado em [o que é CPU steal em VPS](https://streethosting.com.br/guias/vps/o-que-e-cpu-steal-vps).

## Disponibilidade vista de fora

A regra mais ignorada do monitoramento: o check de disponibilidade não pode morar na máquina que ele vigia. Se a VPS travar, perder rede ou ficar presa num reboot, o monitor cai junto, e o silêncio parece boa notícia. As opções, da mais simples à mais robusta:

- **Uma VPS pequena só para monitorar:** roda o Uptime Kuma e checa todas as outras máquinas. Custa pouco e fica sob seu controle.
- **Um serviço externo de uptime:** útil como segunda opinião, porque checa a partir de outras redes.
- **Os dois juntos:** o monitor próprio cobre detalhes (portas, palavra chave, push) e o externo confirma que o problema não é de rota entre o datacenter e os usuários.

O tipo de check também importa. Um HTTP que só confere o código 200 pode passar enquanto a aplicação mostra uma página de erro amigável. Prefira checar uma palavra que só aparece quando a página renderizou de verdade, ou um endpoint de saúde que consulta o banco. Para jogos, banco e SSH, use check de porta TCP. A instalação e cada tipo de monitor estão em [monitoramento com Uptime Kuma](https://streethosting.com.br/guias/vps/monitoramento-vps-com-uptime-kuma).

> **Dica**
>
> Crie na aplicação uma rota como /health que testa a conexão com o banco e devolve 200 só quando tudo responde. O Nginx continua de pé quando a aplicação morre, então checar só a página estática esconde a queda que interessa.

## Recursos, serviços e histórico

Para recursos, existem dois caminhos maduros. O Netdata instala em minutos, coleta métricas por segundo e já vem com alertas prontos; atende muito bem de uma a poucas VPS, e o começo está em [monitorar recursos com htop e Netdata](https://streethosting.com.br/guias/vps/monitorar-recursos-vps-htop-netdata). Prometheus com node_exporter e Grafana dá mais trabalho, mas centraliza várias máquinas, aceita consultas próprias e guarda histórico longo; o passo a passo está em [instalar Grafana e Prometheus na VPS](https://streethosting.com.br/guias/vps/instalar-grafana-prometheus-vps).

Qualquer que seja a ferramenta, guarde histórico de pelo menos 15 a 30 dias. A pergunta mais útil num incidente é desde quando. Memória que sobe um pouco por dia é vazamento; memória que saltou às 3h é uma rotina agendada. Sem histórico, os dois parecem iguais.

Para serviços, o primeiro passo é fazer o próprio systemd religar o que cair. Nas unidades das suas aplicações, inclua reinício automático:

```
[Service]
Restart=on-failure
RestartSec=5
```

Reinício automático resolve o sintoma, não a causa. Um serviço que reinicia vinte vezes por dia continua quebrado, só que em silêncio. Por isso, acompanhe as unidades com falha e os erros do journal:

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

Filtros por serviço, data e prioridade, e o que procurar em cada arquivo de /var/log, estão em [como analisar logs de uma VPS Linux](https://streethosting.com.br/guias/vps/analisar-logs-vps-linux). No Prometheus, o coletor de systemd do node_exporter vem desligado por padrão; ative com `--collector.systemd` se quiser alertar sobre unidades paradas pelo Grafana.

## Backup, cron e certificado

As piores falhas não fazem barulho. O script de backup que dá erro toda noite, o certificado que não renova porque a porta 80 foi fechada numa mudança de firewall, a rotina do cron que sumiu depois de uma migração. Nenhuma delas derruba o site hoje. Todas cobram a conta depois.

A solução é inverter a lógica com heartbeat: em vez de o monitor perguntar, a própria tarefa avisa que rodou. No fim do script, uma chamada para a URL de push do monitor; se o sinal não chegar dentro da janela esperada, o alerta dispara. O monitor do tipo Push do Uptime Kuma faz exatamente isso.

```
#!/usr/bin/env bash
set -euo pipefail

/usr/local/sbin/backup-restic.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. Sem sinal, sem heartbeat, com alerta. É mais confiável do que mandar aviso só em caso de falha, porque cobre também o cenário em que o script nem chegou a rodar. A montagem completa do backup com retenção e teste de restauração está em [backup automático da VPS com restic e cron](https://streethosting.com.br/guias/vps/automatizar-backup-vps-restic-cron).

Para certificados, ative o aviso de expiração no monitor HTTP e rode de vez em quando `sudo certbot renew --dry-run` para confirmar que a renovação ainda funciona. Para o domínio, anote o vencimento e deixe a renovação automática ligada no registrador.

## Alertas que só tocam quando precisa

Alerta demais é tão ruim quanto alerta nenhum. Quando o celular toca por qualquer oscilação, a equipe aprende a ignorar, e o alerta real passa despercebido. Algumas regras mantêm o sinal limpo:

- **Dois níveis de severidade:** crítico acorda alguém (serviço fora, disco acima de 90%); aviso vai para um canal lido no horário comercial (CPU alta sustentada, certificado a 14 dias).
- **Confirmação antes de avisar:** duas ou três falhas seguidas, com checagem a cada 30 a 60 segundos nos monitores críticos.
- **Aviso de recuperação:** avise também quando voltar, para ninguém investigar algo que já se resolveu.
- **Janela de manutenção:** pause os alertas durante atualização planejada, em vez de desligar o monitor e esquecer de religar.
- **Canal certo:** Discord ou Telegram da equipe para o dia a dia, email como registro. Nunca o canal público da comunidade. A configuração está em [alertas de queda no Discord ou Telegram](https://streethosting.com.br/guias/infraestrutura/monitoramento-uptime-alertas-discord-telegram).

Por fim, todo alerta precisa de dono e de um primeiro passo escrito. Uma linha basta: disco acima de 90%, rodar du na raiz, conferir logs e imagens Docker. Às 3h da manhã, ninguém raciocina bem sem roteiro.

- [ ] Monitor de disponibilidade rodando fora da VPS
- [ ] Métricas com histórico de pelo menos 15 dias
- [ ] Heartbeat no backup e nas rotinas críticas do cron
- [ ] Aviso de expiração do certificado ligado
- [ ] Alertas críticos separados dos avisos
- [ ] Dono e primeiro passo definidos para cada alerta
- [ ] Teste de alerta feito derrubando um serviço de propósito

## Ferramentas para cada tamanho

Não existe motivo para montar a stack de uma empresa grande para vigiar um bot de Discord. Comece pelo mínimo que cobre as quatro camadas e cresça quando o número de máquinas pedir.

| Cenário | Disponibilidade | Recursos | Tarefas e prazos |
| --- | --- | --- | --- |
| Uma VPS com site, API ou bot | Uptime Kuma em outra máquina | Netdata na própria VPS | Push do backup e aviso de certificado |
| Duas a dez VPS | Uptime Kuma em uma VPS de monitoramento | node_exporter em cada VPS, Prometheus e Grafana centrais | Push de cada backup e de cada rotina crítica |
| Operação com clientes ou equipe de plantão | Uptime Kuma mais um check a partir de outra rede | Prometheus e Grafana com alertas por severidade | Push, certificados e página de status pública |

> **Atenção**
>
> Teste o alerta antes de confiar nele. Pare um serviço de propósito num horário tranquilo e cronometre quanto tempo a notificação leva para chegar. Monitor configurado e nunca testado costuma falhar por um detalhe bobo, como webhook errado ou email caindo no spam.

## Onde rodar o monitoramento

O servidor de monitoramento tem um perfil simples: pouca CPU, memória estável, disco rápido para o histórico e, acima de tudo, precisa ficar de pé quando as outras máquinas caem. Uma VPS pequena e separada das aplicações faz isso bem, e a linha [VPS Xeon](https://streethosting.com.br/vps/xeon) entrega mais vCPU por real, que é o que esse tipo de carga aproveita.

O plano de R$ 23,00 por mês, com 2 vCPU, 2 GB de RAM e 20 GB de NVMe, roda o Uptime Kuma e um Prometheus para poucas máquinas. O de R$ 40,00, com 3 vCPU, 4 GB e 40 GB, acomoda Uptime Kuma, Prometheus e Grafana com 30 dias de retenção para algumas dezenas de servidores. Se a operação crescer, o de R$ 57,00 tem 4 vCPU, 6 GB e 60 GB. Todos ficam em São Paulo, com AntiDDoS Enterprise, uplink de 1 Gbps, latência média de 20 ms no Brasil e ativação em até 60 segundos. Quando o histórico pedir mais espaço, o upgrade pelo painel aumenta memória, vCPU e disco e cobra só a diferença proporcional do ciclo.

Um cuidado honesto: uma VPS de monitoramento no mesmo datacenter das aplicações detecta queda de serviço, travamento e falta de recurso, mas não enxerga um problema de rota entre São Paulo e os seus usuários. Para essa camada, mantenha um check a partir de outra rede. Com as duas coisas, o celular toca antes do primeiro cliente reclamar.

## Perguntas frequentes

### Qual a melhor ferramenta para monitorar uma VPS?

Não existe uma ferramenta que cubra tudo. Para disponibilidade, use um monitor externo como o Uptime Kuma rodando fora da VPS. Para recursos, Netdata atende uma ou poucas máquinas e Prometheus com Grafana escala melhor para várias. O que importa é cobrir disponibilidade, recursos e tarefas agendadas.

### Posso monitorar a VPS de dentro dela mesma?

Métricas de CPU, memória e disco, sim. Disponibilidade, não: se a VPS travar ou perder rede, o monitor cai junto e nada é enviado. O check de uptime precisa rodar em outra máquina, de preferência em outra rede.

### Com quantos por cento de disco devo receber alerta?

Um bom ponto de partida é aviso em 80% e alerta crítico em 90%, olhando também os inodes. Em discos pequenos, como 20 GB, prefira um limite em GB livres, porque 10% são só 2 GB e um log descontrolado consome isso em poucas horas.

### Como saber se o backup rodou sem conferir todo dia?

Use heartbeat. No fim do script de backup, faça uma chamada para a URL de push do monitor; se o sinal não chegar dentro do intervalo esperado, você recebe um alerta. Com set -e no script, a chamada só acontece quando o backup terminou sem erro.

### Monitoramento deixa a VPS mais lenta?

Quando bem configurado, o impacto é pequeno. Um node_exporter usa poucos MB de RAM e o Netdata é leve para o que entrega. O que pesa é guardar histórico longo em uma VPS pequena; nesse caso, leve Prometheus e Grafana para uma máquina separada.

## Guias relacionados

- [Como instalar Uptime Kuma na VPS e monitorar sites e portas](https://streethosting.com.br/guias/vps/monitoramento-vps-com-uptime-kuma.md)
- [Instalar Grafana e Prometheus na VPS com node_exporter](https://streethosting.com.br/guias/vps/instalar-grafana-prometheus-vps.md)
- [Como analisar logs de uma VPS Linux com journalctl e grep](https://streethosting.com.br/guias/vps/analisar-logs-vps-linux.md)
- [Como verificar CPU, RAM, disco e rede no Linux por comando](https://streethosting.com.br/guias/vps/verificar-cpu-ram-disco-rede-linux.md)
- [Como criar status page para incidentes de servidor](https://streethosting.com.br/guias/infraestrutura/criar-status-page-incidentes.md)

## Produtos citados

- https://streethosting.com.br/vps/xeon
- https://streethosting.com.br/vps

## Dados estruturados

```json
[
  {
    "@context": "https://schema.org",
    "@type": [
      "Article",
      "TechArticle"
    ],
    "headline": "Estratégia de monitoramento contínuo para VPS: o que medir e quando alertar",
    "name": "Como monitorar uma VPS 24 horas: métricas, alertas e uptime",
    "abstract": "Um monitor de uptime sozinho não avisa que o disco está enchendo nem que o backup parou há três semanas. Veja como combinar disponibilidade, recursos, tarefas agendadas e alertas em uma rotina que funciona dia e noite.",
    "description": "Monte o monitoramento 24 horas da VPS: uptime externo, CPU, RAM, disco e rede, limites de alerta, heartbeat de backup e ferramentas para cada tamanho.",
    "datePublished": "2026-09-28",
    "dateModified": "2026-09-28",
    "author": {
      "@type": "Organization",
      "name": "Equipe StreetHosting"
    },
    "publisher": {
      "@type": "Organization",
      "name": "StreetHosting",
      "url": "https://streethosting.com.br"
    },
    "inLanguage": "pt-BR",
    "mainEntityOfPage": {
      "@type": "WebPage",
      "@id": "https://streethosting.com.br/guias/vps/monitorar-vps-24-horas"
    }
  },
  {
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
      {
        "@type": "Question",
        "name": "Qual a melhor ferramenta para monitorar uma VPS?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Não existe uma ferramenta que cubra tudo. Para disponibilidade, use um monitor externo como o Uptime Kuma rodando fora da VPS. Para recursos, Netdata atende uma ou poucas máquinas e Prometheus com Grafana escala melhor para várias. O que importa é cobrir disponibilidade, recursos e tarefas agendadas."
        }
      },
      {
        "@type": "Question",
        "name": "Posso monitorar a VPS de dentro dela mesma?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Métricas de CPU, memória e disco, sim. Disponibilidade, não: se a VPS travar ou perder rede, o monitor cai junto e nada é enviado. O check de uptime precisa rodar em outra máquina, de preferência em outra rede."
        }
      },
      {
        "@type": "Question",
        "name": "Com quantos por cento de disco devo receber alerta?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Um bom ponto de partida é aviso em 80% e alerta crítico em 90%, olhando também os inodes. Em discos pequenos, como 20 GB, prefira um limite em GB livres, porque 10% são só 2 GB e um log descontrolado consome isso em poucas horas."
        }
      },
      {
        "@type": "Question",
        "name": "Como saber se o backup rodou sem conferir todo dia?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Use heartbeat. No fim do script de backup, faça uma chamada para a URL de push do monitor; se o sinal não chegar dentro do intervalo esperado, você recebe um alerta. Com set -e no script, a chamada só acontece quando o backup terminou sem erro."
        }
      },
      {
        "@type": "Question",
        "name": "Monitoramento deixa a VPS mais lenta?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Quando bem configurado, o impacto é pequeno. Um node_exporter usa poucos MB de RAM e o Netdata é leve para o que entrega. O que pesa é guardar histórico longo em uma VPS pequena; nesse caso, leve Prometheus e Grafana para uma máquina separada."
        }
      }
    ]
  }
]
```