Monitoramento de VPS para dono de loja: como saber que o site vai cair antes do cliente avisar

Serviço que testa se o site está no ar avisa depois que a loja já caiu. Quem avisa antes é a métrica de dentro da máquina — e ela só vira alerta útil depois que você mede o que é normal no seu dia comum.

Monitoramento de VPS é coletar números de dentro do servidor, guardar o histórico e avisar quando o número sai do padrão. É isso que dá aviso antes da queda: serviço que só testa se o site responde avisa depois que a loja já caiu.

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.

A resposta direta é desconfortável: não dá para descobrir antes olhando só se o site responde. Enquanto a página abre, qualquer teste externo diz que está tudo bem.

Descobrir antes exige olhar o que acontece dentro da máquina no período em que ela ainda responde — e já está ficando sem fôlego.

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 que o mercado costuma misturar: a checagem externa de disponibilidade, que avisa depois, e o monitoramento de métricas no servidor, que avisa antes.

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. A resposta é binária: no ar ou fora do ar.

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ê.

O que ela não enxerga é o que antecede a queda: a loja lenta porém no ar, a fila da aplicação enchendo, o disco acabando, a memória no fim. Tudo isso passa no teste até o segundo em que não passa mais.

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 e nenhuma substitui a outra. A externa é a única que confirma que o cliente consegue abrir a loja; a interna é a única que avisa antes.

Monitoramento de VPS: o que olhar e o que cada sinal significa

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.

1. 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.
2. 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.
3. 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.
4. 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.

Extra barato e de alto retorno: expor as métricas do PHP-FPM (processos ativos e tamanho da fila) e checar espaço em disco com aviso antecipado, bem antes de encher.

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

As mesmas métricas que você passou este artigo aprendendo a ler — uso de recurso, tempo de resposta, fila de espera — são as que o agente usa como gatilho de burst, o momento em que a carga passa a não caber mais na sua máquina fixa.

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, esses nós saem e a cobrança deles termina ali. 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.