Revisado em 12/11/2026: diferenciados os sinais internos e externos e os limites de previsão.
Monitoramento de VPS combina métricas do servidor, logs e testes externos da aplicação. O histórico ajuda a reconhecer desvios de recursos, latência e erros; alertas bem definidos podem antecipar alguns incidentes, mas não garantem prever toda queda.
Todo termo técnico abaixo vem explicado na primeira aparição.
Como eu descubro que a loja saiu do ar antes de um cliente me avisar
Quase sempre a descoberta vem de fora: um print no WhatsApp de cliente, ou a venda que simplesmente parou e ninguém sabe por quê. Quando você olha, o site já estava fora havia um tempo.
Uma checagem que avalia apenas sucesso ou falha da URL pode perder sinais de degradação. Testes externos também podem acompanhar latência e conteúdo esperado antes de uma indisponibilidade total; métricas internas ajudam a explicar o que está acontecendo.
Para investigar a degradação, compare esses sinais com o que acontece dentro da máquina enquanto a aplicação ainda responde.
As três partes da definição importam: coletar, guardar histórico e avisar. Sem histórico não existe padrão, e sem padrão não existe "fora do padrão".
Daí saem duas camadas complementares: a checagem externa, que observa o serviço a partir de outro ponto da rede, e o monitoramento de métricas no servidor, que acompanha recursos e processos. Ambas dependem do que foi configurado para medir e alertar.
E um recado de expectativa, sem promessa: monitorar encurta o tempo entre o problema começar e você ficar sabendo. Não impede a queda por si só.
Testar se o site está no ar não é a mesma coisa que monitorar a máquina
Checagem externa de disponibilidade é um robô fora da sua rede que abre uma URL de tempos em tempos e avisa se voltou erro ou não voltou nada. O teste pode verificar disponibilidade, tempo de resposta e conteúdo, conforme a ferramenta e a configuração.
Ela enxerga bem queda total, certificado vencido, DNS quebrado e servidor sem resposta — inclusive problemas que só existem de fora e que a máquina não teria como reportar sobre si mesma. Se o servidor travou por completo, nenhum programa instalado nele vai conseguir contar isso a você.
Uma checagem externa não identifica sozinha fila do PHP, espaço em disco ou memória disponível. Ela pode mostrar lentidão ou erro; a causa exige comparação com logs e métricas internas.
Monitoramento de métricas dentro da máquina é a outra camada: um programa pequeno instalado no servidor — o agente — lê o uso de recursos em intervalos curtos e envia para um painel que guarda o histórico. O que ele mostra é a rampa de subida que precede o estouro. É ali que mora a chance de agir.
As duas camadas são complementares. Uma URL responder a uma sonda externa não comprova todos os caminhos de compra nem todas as redes dos clientes. Da mesma forma, recursos livres no servidor não comprovam que o site esteja funcionando de ponta a ponta.
Monitoramento de VPS: o que olhar e o que cada sinal significa
| Métrica | O que é | O que significa quando sobe |
|---|---|---|
| Uso de processador (CPU) | Quanto do cálculo disponível está ocupado | Sozinha diz pouco: CPU alta com resposta rápida é máquina produzindo, não sofrendo |
| Memória RAM | Onde a aplicação guarda o que está usando agora | O alerta não é "memória cheia" (o cache do sistema ocupa de propósito), é memória disponível caindo de forma sustentada |
| Memória de troca (swap) | Pedaço do disco usado como memória emprestada quando a RAM acaba | Disco é muito mais lento que memória: swap em uso ativo e crescente costuma anteceder o engasgo |
| Load average | Média de processos rodando ou esperando a vez — por processador ou por disco | Só significa algo comparado ao número de núcleos da sua VPS, e esse número você precisa saber antes de interpretar o valor |
| Espera de disco (I/O wait) | Tempo em que o processador fica parado esperando leitura ou gravação | Sugere investigar espera por I/O junto de latência e utilização do armazenamento; o valor isolado não identifica a causa |
| Espaço em disco | Quanto ainda sobra no volume | Log que cresce, backup que não é apagado, banco inchado. Disco cheio derruba banco de dados e site, e costuma encher durante backups e rotinas agendadas |
| Tempo de resposta da página | Quanto o servidor leva para entregar a página pronta | É o que o cliente sente; leia em p95 — o valor abaixo do qual ficam 95% das requisições —, não em média |
| Taxa de erro 5xx | Proporção de respostas de erro do servidor web | 502: a camada da frente não obteve resposta válida da aplicação. 503: serviço temporariamente indisponível, por exemplo por manutenção ou sobrecarga. 504: a aplicação não respondeu dentro do tempo limite |
Falta a métrica mais próxima da queda: a fila do PHP-FPM. O PHP-FPM é o programa que executa o código da loja, e a configuração dele define um número máximo de processos simultâneos.
Quando todos estão ocupados, os pedidos novos ficam numa fila de espera. Fila com gente esperando é um dos sinais mais adiantados que existem: ela costuma encher antes de o site cair de fato, e é exatamente o intervalo em que ainda dá para fazer alguma coisa.
A regra de leitura: nenhuma métrica isolada conta a história. O que mais importa é recurso em alta junto com tempo de resposta e fila subindo. CPU alta com resposta rápida e fila vazia é máquina produzindo; CPU alta com resposta piorando e fila crescendo é máquina no limite.
Linha de base: descobrir o que é normal antes de configurar qualquer alerta
Linha de base é o retrato dos seus números em dias comuns: dia útil de manhã, de tarde e à noite, fim de semana, e a janela em que rodam backup e tarefas agendadas. Coletar isso por um período que contenha as variações reais da loja vem antes de ligar qualquer alerta.
Por métrica, anote três coisas: faixa típica, pico de um dia normal e o que estava acontecendo nesse pico — campanha, importação de produto, robô de busca varrendo o catálogo ou uma das datas de pico do e-commerce brasileiro. O pico sem contexto vira alarme falso semanas depois, quando ninguém lembra mais o motivo.
Não existe limiar universal, e não vamos recomendar percentual como se valesse para todo mundo. Duas lojas no mesmo plano, uma com cache de página ligado e outra sem, têm normais diferentes — e um número copiado de fora dispara cedo demais numa e tarde demais na outra.
O limiar sai da sua linha de base: valor acima do seu normal, sustentado por tempo suficiente para não ser pico de segundos. E ele tem validade — precisa ser revisto depois de qualquer mudança relevante na loja, de troca de tema a plugin novo.
A linha de base diz onde você anda no dia normal; o teste de carga diz onde está o teto. Uma coisa sem a outra deixa a decisão de capacidade no chute.
Por que seus alertas disparam toda hora e você já parou de olhar
O mecanismo é sempre o mesmo: alerta configurado em valor absoluto e instantâneo dispara em toda oscilação normal. Pico de trinta segundos durante o backup, robô de busca passando, importação de produto — tudo vira aviso.
Em pouco tempo o aviso vira barulho ignorado, e aí o alerta real chega no meio de vários falsos. Isso não é falta de atenção do dono; é defeito de projeto do alerta.
O que reduz ruído sem perder o aviso:
- Exigir persistência: a condição precisa se manter por um intervalo, não por um instante.
- Alertar por tendência, e não só por valor: subindo de forma sustentada importa mais que um número atingido uma vez.
- Agrupar avisos repetidos do mesmo incidente, para não receber uma mensagem a cada checagem enquanto o problema dura.
- Separar dois níveis: o que exige acordar alguém (loja fora do ar, disco quase cheio, fila do PHP-FPM cheia) e o que é para olhar no dia seguinte.
O critério honesto de corte: se um alerta disparou e você não fez nada com ele, ou está mal configurado ou não deveria existir. E cada alerta precisa de dono e de ação escrita — quem recebe, em que canal, e o que faz ao receber.
O mínimo viável de monitoramento com ferramenta gratuita
São quatro peças, e dá para montar todas sem pagar licença.
- Checagem externa de disponibilidade. Serviço que abre a URL de fora em intervalo curto e avisa por e-mail ou aplicativo. Configure a URL certa — uma página que exercita a aplicação, não só a home cacheada — e um canal de aviso que você realmente vê no celular.
- Painel de métricas do provedor da VPS. Já vem no painel de controle e mostra CPU, memória, disco e rede sem instalar nada. Limitação a declarar: costuma ter granularidade e histórico curtos, e não enxerga nada do que roda dentro da aplicação.
- Agente de métricas no servidor. Programa leve instalado na VPS que coleta com detalhe e guarda histórico, incluindo swap, espera de disco e processos. É o que dá linha de base de verdade.
- Leitura dos logs do servidor web. O access log registra cada pedido recebido, com código de resposta e tempo; o error log registra o que falhou. Contagem de 5xx por minuto e ranking das URLs mais lentas saem dali com comandos simples de filtro e contagem de linha.
Quando a aplicação usa PHP-FPM, configure sua página de status com acesso interno ou restrito a IPs autorizados, sem exposição pública. Processos ativos e fila ajudam a investigar o limite pm.max_children. Para conferir quem está gerando tráfego, complemente com a análise de logs por visitantes e robôs.
A ordem de implantação importa: disponibilidade externa primeiro, porque é a mais rápida de ligar; depois métricas com histórico; depois logs; e só então alertas. Nessa ordem porque alerta sem histórico é chute. O custo aqui é tempo de configuração, não licença.
Onde o monitoramento não resolve nada
Monitorar é medir, não aumentar. Nenhum painel adiciona processador à sua VPS.
O caso desconfortável é este: se a linha de base já mostra a máquina perto do teto no dia normal, o alerta vai apenas avisar mais cedo que a loja está caindo. O desfecho continua o mesmo.
Mesmo aí a medição faz duas coisas bem: encurta o tempo de descoberta e, principalmente, diz qual recurso acaba primeiro. É o que evita comprar o recurso errado — trocar de plano por mais CPU quando o que estourava era espera de disco.
Quando o gargalo é configuração e não tamanho — cache desligado, número de processos do PHP-FPM mal dimensionado, consulta sem índice, tarefa agendada rodando em horário de pico —, o caminho é diagnóstico, não mais máquina. O roteiro está em como achar o gargalo na sua VPS.
E se o alerta dispara no meio da Black Friday, a expectativa realista é que a janela é curta. Dá para aliviar o que é opcional, ligar cache mais agressivo e cortar tarefa pesada agendada — o checklist de preparo tem o resto.
O que não dá é tomar decisão de capacidade sob pressão: sai cara e mal feita. Capacidade é outra decisão, tomada antes da data, e o cálculo entre servidor maior e reforço por hora só fecha com número medido.
Do alerta ao gatilho: onde o SwarmBurst entra
O diagnóstico combina recursos, tempo de resposta e filas. Isso não significa que o agente aceite todas essas métricas como gatilhos configuráveis: a implantação precisa verificar os sinais efetivamente suportados pela versão do SwarmBurst e definir uma política adequada ao serviço.
Em uma frase para quem não é de infraestrutura: a loja segue na VPS fixa no dia normal e, quando a métrica passa do ponto que você definiu, sobem servidores extras por hora na nuvem pública, que entram no cluster e atendem junto; quando o movimento cai, os nós são retirados e as instâncias são encerradas. Recursos associados precisam ser conferidos porque podem continuar gerando cobrança. O conceito por trás está em o que é cloud bursting, e a parte prática de ligar o gatilho aparece em como configurar cloud bursting no Docker Swarm.
É aqui que a linha de base deixa de ser exercício e vira pré-requisito: ela é o que permite escolher o limiar de disparo sem chutar. Limiar baixo demais sobe máquina à toa e gasta; alto demais sobe tarde, e o cliente já sentiu.
A diferença de propósito, sem rodeio: alerta avisa você; gatilho age sozinho. Quem não tem a medição não tem base para nenhum dos dois.
Pré-requisito honesto: só funciona com a loja em contêineres dentro de um cluster. VPS com nginx, PHP e MySQL instalados direto no sistema tem um passo anterior de containerização, que é trabalho de verdade e entra no diagnóstico antes de qualquer proposta.
Se você já tem linha de base medida e teto abaixo do pico, a conversa começa por aí — pelos seus números, não por um exemplo nosso.
Perguntas frequentes
A partir de quantos por cento de CPU eu devo me preocupar?
Não existe limiar universal, e percentual copiado de fora dispara cedo demais numa loja e tarde demais na outra: duas lojas no mesmo plano, uma com cache de página ligado e outra sem, têm normais diferentes.
CPU sozinha também diz pouco. CPU alta com resposta rápida e fila vazia é máquina produzindo; CPU alta com tempo de resposta piorando e fila crescendo é máquina no limite. O limiar sai da sua linha de base: valor acima do seu normal, sustentado por tempo suficiente para não ser pico de segundos — e revisto depois de qualquer mudança relevante na loja.
Swap em uso é sempre ruim? E espera de disco (I/O wait) alta?
Swap é o pedaço do disco usado como memória emprestada quando a RAM acaba. Como disco é muito mais lento que memória, swap em uso ativo e crescente costuma anteceder o engasgo. Vale a mesma lógica da memória: o alerta não é "memória cheia" (o cache do sistema ocupa de propósito), é memória disponível caindo de forma sustentada.
Espera de disco é o tempo em que o processador fica parado esperando leitura ou gravação. Quando está alta, o gargalo é o disco e não a CPU — comprar mais processador não resolveria. É justamente por isso que medir evita trocar de plano pelo recurso errado.
O que é a fila do PHP-FPM e por que ela enche antes do site cair?
O PHP-FPM é o programa que executa o código da loja, e a configuração dele define um número máximo de processos simultâneos. Quando todos estão ocupados, os pedidos novos ficam numa fila de espera.
Fila com gente esperando é um dos sinais mais adiantados que existem: ela costuma encher antes de o site cair de fato, e é exatamente o intervalo em que ainda dá para fazer alguma coisa. Expor as métricas do PHP-FPM (processos ativos e tamanho da fila) é um extra barato e de alto retorno.
Dá para montar monitoramento só com ferramenta gratuita ou preciso pagar?
Dá para montar as quatro peças sem pagar licença: checagem externa de disponibilidade, o painel de métricas do próprio provedor da VPS, um agente de métricas instalado no servidor e a leitura dos logs do servidor web. O painel do provedor tem limitação a declarar — costuma ter granularidade e histórico curtos e não enxerga nada do que roda dentro da aplicação.
A ordem de implantação importa: disponibilidade externa primeiro, porque é a mais rápida de ligar; depois métricas com histórico; depois logs; e só então alertas — porque alerta sem histórico é chute. O custo aqui é tempo de configuração, não licença.
Se o alerta disparar no meio da Black Friday, o que eu faço na hora?
A expectativa realista é que a janela é curta. Dá para aliviar o que é opcional, ligar cache mais agressivo e cortar tarefa pesada agendada.
O que não dá é tomar decisão de capacidade sob pressão: sai cara e mal feita. Capacidade é outra decisão, tomada antes da data e apoiada em número medido — linha de base para saber onde você anda no dia normal e teste de carga para saber onde está o teto.