Monitoramento de hospedagem: métricas, ferramentas e alertas

Sabe aquele momento em que sua loja virtual começa a ficar lenta? Nada crítico, só alguns segundos. Você pensa: “Deve ter sido um pico de tráfego”. No dia seguinte, acontece de novo. Uma semana depois, já é um padrão. E o seu provedor responde: “Está tudo bem, você só tem a carga normal”. É aí que começa a história de como resolver o problema em poucos minutos, se você souber para onde olhar.

Monitorar a hospedagem não é privilégio de grandes corporações com muito dinheiro e infraestrutura cara. É o seu seguro contra surpresas desagradáveis na pior hora possível: quando os pedidos somem no ar e você fica com o telefone no ouvido, esperando o suporte dizer “já vamos reiniciar o servidor”.

O que realmente se esconde por trás dos números nos gráficos

Quando você entra no painel de controle da hospedagem, vê gráficos. Contadores comuns de CPU, memória e tráfego. Mas esses números aparentemente inocentes contam uma verdadeira história de detetive sobre o que realmente acontece com o seu site.

A CPU não é só uma porcentagem de um 100% abstrato. É literalmente o tempo que o processador dedica ao seu site. Se, de madrugada, quando quase não há visitantes, a carga da CPU salta de repente do nível habitual para perto do limite, isso não é uma oscilação natural. É um pedido de socorro. Talvez bots estejam atacando você, tentando quebrar a sua senha. Ou algum plugin do WordPress começou a fazer backup de hora em hora bem no pico de tráfego. Ou alguém rodou um scraper no seu catálogo.

A memória é um tesouro. O limite do plano parece suficiente no papel. Na prática, tudo depende de como o seu site a consome. Um WordPress com dezenas de plugins e código personalizado escrito sem cuidado por um desenvolvedor pode devorar toda a memória em poucos minutos de pico.

O tráfego também faz parte da equação. Se o seu plano tem um limite de tráfego incluído no preço, acompanhe o quanto você está perto dele (nos planos de hospedagem da RichHost o tráfego é ilimitado). E se em um único dia você consumir mais do que o seu volume mensal habitual, vale descobrir por quê: não dá para supor que foi uma campanha de anúncios planejada.

Sete sinais de alerta que gritam “Socorro!” na sua cara

• Tempo de resposta do servidor (TTFB) constantemente acima de 1,8 segundo: o guia web.dev do Google classifica isso como ruim, enquanto um bom TTFB é de 0,8 segundo ou menos (verificado em 30/10/2026).
• CPU ou memória batem com frequência no limite do plano: o sistema está no fio da navalha. De que qualidade de serviço podemos falar se o servidor está à beira do colapso? É como dirigir todo dia com o tanque na reserva.
• Mudanças no número de erros 404, 500 e 502: se os erros 500 de repente ficam muitas vezes mais frequentes do que o normal, não é coincidência, é tendência. Algo deu errado.
• Picos repentinos de tráfego sem motivo aparente: você não lançou nenhuma promoção, mas o tráfego se multiplicou. Boa notícia? Ou começou um ataque DDoS? Uma invasão? Um scraper?
• O tempo de carregamento das páginas aumenta dia após dia: isso significa que algo em torno do seu site está se degradando.
• Consultas ao banco de dados travam: se uma consulta MySQL leva segundos em vez dos milissegundos de sempre, aí está a causa da lentidão. O índice precisa de otimização, ou a tabela cresceu demais.
• O espaço em disco enche rápido demais: se o espaço usado cresceu bastante durante a noite e você não enviou nada, para onde estão indo os dados? Logs? Backups não apagados? O cache de algum plugin?

Ferramentas que merecem mais atenção do que uma xícara de café

Sejamos sinceros: os gráficos embutidos no painel da hospedagem são como olhar a estrada por uma fresta. Você vê alguma coisa, mas não o quadro completo. Por isso quem administra sites com experiência usa há muito tempo monitoramento externo.

Cada uma dessas ferramentas conta a sua parte da história. O UptimeRobot vai dizer quando e por quantos minutos o seu site ficou fora do ar. O New Relic vai mostrar o que acontecia naquele momento com as consultas ao banco de dados. O Sentry vai mostrar a linha exata de código que causou o erro.

O segredo não é uma única ferramenta de monitoramento. É uma combinação de ferramentas que dá a você clareza total. Como montar um quebra-cabeça em que cada peça é uma informação.

Alertas: como escapar da matrix de notificações

Você recebe dezenas de e-mails por dia sobre picos curtos de CPU e outros tantos dizendo que está tudo bem. E o próximo, quando o site cai de verdade, você nem lê: apagou junto com todos os outros.

Isso se chama fadiga de alertas, e ela mata a segurança. Por isso, configure os alertas com critério. Abaixo estão exemplos de limites iniciais, que você depois ajusta ao comportamento normal do seu próprio site:

1. CPU acima de 85% por pelo menos 5 minutos: isso é um sinal. Um pico isolado de um minuto, não.
2. Tempo de resposta do servidor (TTFB) acima de 1,8 segundo, o limite “ruim” do web.dev: só se acontecer de forma constante, não em oscilações aleatórias.
3. O site está fora do ar: isso é SEMPRE crítico. Imediatamente. Sem filtros.
4. Os erros 5xx viram problema quando aparecem bem mais do que você costuma ver por hora.

E o mais importante: os alertas precisam chegar onde você com certeza vai vê-los. Não por e-mail. E-mail é como mandar cartas pelo correio nos anos 1990. Use mensagens no Slack, SMS, notificações push no Telegram, dor de barriga: algo que acorde você às 3 da manhã e diga: “Ei, olha aqui”.

Logs como dossiê de investigação: o que a hospedagem está dizendo

A hospedagem guarda logs: erros do servidor web, logs de acesso, erros de PHP, erros do banco de dados. Esses logs são como o diário da hospedagem, com tudo o que ela fez ao longo do dia.

Cenário típico: um problema que você não consegue reproduzir é mais fácil de investigar pelos logs. Mesmo que a falha não se repita, os logs costumam guardar os detalhes que levam à causa.

Por exemplo, você vê que o site ficou lento às 14:32. Você não estava fazendo nada de especial naquela hora. Mas se mergulhar nos logs, vai encontrar milhares de erros de PHP de um plugin que tentava se conectar a uma API que tinha caído às 14:30. O sistema sofria, e cada requisição ficava bloqueada por vários segundos esperando resposta.

Sem olhar os logs, isso continuaria sendo um mistério. Com eles, vira um diagnóstico.

Como automatizar o que atormenta você todos os dias

Sejamos realistas: você não vai entrar todo dia no painel da hospedagem para olhar gráficos. É chato. Cansa a vista. É perda de tempo.

Por isso quem tem experiência escreve scripts. Em bash, Python ou PHP, tanto faz. Um script que faz isto a cada hora:

• Busca dados na API da hospedagem (se houver)
• Compara com os valores-limite
• Se algo passar do normal, recebemos um alerta
• Guarda os dados em um banco de dados para histórico e análise

Não é nada complicado. Sério. Um script Python de 50 linhas e você já tem um sistema que coleta dados a cada hora.

Mas para isso você precisa de uma coisa: o provedor tem de oferecer uma API ou, pelo menos, acesso SSH. Se o seu provedor de hospedagem nunca ouviu falar de API aberta, isso é um sinal. Significa que ele não pensa em clientes exigentes, e talvez valha a pena procurar outro.

Você está mesmo disposto a depender de um servidor que funciona no escuro, sem nenhuma visibilidade do que acontece lá dentro? É como dirigir de olhos vendados. Vai dar tudo certo até alguém atravessar a rua.