Logs e Monitoração de Servidor: Ler os Sinais Antes da Queda

Quando um site cai, quase nunca é uma surpresa total para a máquina. O servidor costuma dar sinais antes — o uso de memória subindo aos poucos, erros que começam a pipocar no log, o disco enchendo devagar, as consultas ao banco ficando mais lentas. O problema é que esses sinais ficam escritos em arquivos que quase ninguém abre, até o dia em que o site sai do ar e o dono corre atrás de entender o que aconteceu, já tarde demais.

Este guia é sobre aprender a ler esses sinais. Não estamos falando de monitorar o site de fora, checando se ele responde — isso é uma peça importante e complementar. Estamos falando de olhar o servidor por dentro: os logs que registram cada acesso e cada erro, e as métricas que mostram a saúde da máquina. Entender esse painel interno é o que permite agir antes da queda, e também é o que faz você chegar ao suporte com um diagnóstico em vez de um "meu site está estranho".

O que são logs, afinal#

Um log é um registro cronológico do que aconteceu. Cada componente do servidor mantém o seu, anotando eventos linha a linha, com data e hora. Ler um log é como reconstruir a história recente da máquina — quem acessou o quê, o que deu certo, o que deu errado.

Num servidor web típico, os logs mais importantes são:

• Log de acesso. Registra cada requisição que o servidor recebeu — quem pediu qual página, quando e com qual resultado.
• Log de erro do servidor web. Anota problemas que o servidor encontrou ao atender os pedidos.
• Log da aplicação/PHP. Registra erros e avisos gerados pelo código do site, como o PHP do WordPress.
• Log do banco de dados. Guarda problemas e, se configurado, consultas lentas do banco.
• Logs de segurança e do sistema. Registram tentativas de acesso, ações administrativas e eventos do sistema operacional.

Cada um conta uma parte da história. Saber qual olhar depende do sintoma que você está investigando.

Lendo um log de acesso#

O log de acesso é onde você vê o tráfego real do site. Cada linha representa uma requisição e traz, entre outras coisas, o endereço de quem acessou, a data e hora, qual recurso foi pedido, o código de resposta e o tamanho da resposta. Uma linha, de forma simplificada, se parece com:

• 198.51.100.10 - - [data:hora] "GET /pagina HTTP/1.1" 200 5120

Aqui, alguém pediu a página /pagina, e o servidor respondeu com o código 200 (sucesso) e enviou cerca de 5 KB. Lendo muitas dessas linhas, você enxerga padrões valiosos:

• O que é mais acessado. Quais páginas concentram o tráfego.
• De onde vêm os acessos. Concentrações de acessos de uma mesma origem podem indicar um robô ou um ataque.
• O que está sendo procurado e não existe. Uma enxurrada de pedidos a endereços inexistentes pode ser alguém sondando o site em busca de brechas.

O log de acesso é a base para entender o comportamento real do tráfego, muito além do que um contador de visitas mostra.

Os códigos de status como sinal#

Toda resposta do servidor traz um código de três dígitos, e aprender a reconhecer os principais transforma o log de acesso num sistema de alerta.

• 2xx — sucesso. O pedido foi atendido. O 200 é o normal do dia a dia.
• 3xx — redirecionamento. O recurso está em outro lugar. Útil, mas um excesso pode indicar cadeias de redirecionamento mal configuradas.
• 4xx — erro do lado de quem pediu. O 404 (não encontrado) em pequena quantidade é normal; em massa, sugere links quebrados ou alguém sondando o site. O 403 indica acesso negado.
• 5xx — erro do lado do servidor. Aqui mora o perigo. O 500 é um erro interno; o 502 e o 503 indicam que o servidor não conseguiu responder ou está sobrecarregado. Uma onda de 5xx é o sinal mais claro de que algo está quebrado ou no limite.

Uma regra prática: se os códigos 5xx começam a aparecer, pare o que estiver fazendo e investigue. Eles são o servidor dizendo, em voz alta, que não está dando conta.

O log de erro: onde o problema se explica#

Enquanto o log de acesso diz que algo deu errado (pelo código de status), o log de erro costuma dizer por quê. É nele que o servidor e a aplicação registram a mensagem detalhada do problema.

• Erros do servidor web. Falhas ao processar uma requisição, arquivos de configuração com problema, limites atingidos.
• Erros de PHP. No caso do WordPress e sites semelhantes, o log registra erros do código — um plugin que falhou, uma função que quebrou, um limite de memória estourado.
• Avisos que precedem falhas. Muitas vezes, antes de um erro fatal, aparecem avisos que sinalizam o problema se formando. Prestar atenção neles é antecipar a falha.

Quando o site apresenta a temida página em branco ou um erro genérico, é o log de erro que revela a causa concreta — quase sempre uma linha que aponta o arquivo e o motivo exatos.

Métricas de saúde da máquina#

Além dos logs, que registram eventos, existem as métricas, que medem o estado dos recursos da máquina ao longo do tempo. Elas são o sinal vital do servidor.

• CPU. O quanto o processador está ocupado. Picos ocasionais são normais; uso alto e constante indica sobrecarga ou algum processo consumindo demais.
• Memória. A memória disponível. Quando ela se esgota, o servidor recorre à swap (uso do disco como memória), que é muito mais lento e derruba o desempenho. Memória subindo sem parar pode indicar um vazamento.
• Disco. O espaço livre e a velocidade de leitura e escrita. Um disco quase cheio causa falhas inesperadas; um disco lento arrasta tudo.
• Conexões e processos. Quantas requisições e processos estão ativos. Uma fila que cresce sem escoar é sinal de que a demanda superou a capacidade.

Acompanhar essas métricas é o que permite ver o problema se formando — a memória que sobe dia após dia, o disco que enche devagar — em vez de ser pego de surpresa quando o limite é atingido.

Sinais precoces de que algo vai dar errado#

Juntando logs e métricas, alguns padrões funcionam como aviso antecipado. Reconhecê-los dá tempo de agir.

• Uso de memória crescente. Se a memória usada sobe de forma consistente e não volta, algo está acumulando. É questão de tempo até esgotar.
• Aumento de erros 5xx. Um crescimento gradual de erros de servidor no log de acesso costuma preceder uma queda maior.
• Consultas ao banco ficando lentas. Quando o banco começa a demorar para responder, o site inteiro desacelera. O log de consultas lentas, quando ativo, aponta exatamente onde.
• Disco enchendo. Muitas vezes causado justamente por logs sem controle, que crescem até ocupar todo o espaço — um problema que se alimenta.
• Fila de processos. Requisições esperando para serem atendidas indicam que a capacidade está no limite.

Nenhum desses sinais garante uma queda imediata, mas todos merecem investigação antes de virarem incidente.

Rotação de logs: o cuidado que evita o tiro pela culatra#

Há uma ironia importante: os próprios logs, que ajudam a evitar problemas, podem causar um. Logs crescem continuamente, e um log que nunca é limpo acaba enchendo o disco — e um disco cheio derruba o servidor.

A solução é a rotação de logs: um mecanismo que periodicamente arquiva os logs antigos, comprime-os e apaga os mais velhos, mantendo o tamanho sob controle. Bem configurada, a rotação garante que você tenha histórico suficiente para investigar sem que os arquivos consumam todo o espaço. Um log sem rotação é uma das causas mais bobas — e mais comuns — de disco cheio e site fora do ar.

Alertas: não depender de olhar o tempo todo#

Ninguém consegue ficar lendo logs e métricas o dia inteiro, e nem precisa. O caminho sustentável é configurar alertas que avisem quando algo sai do normal.

• Limiares de recurso. Ser avisado quando a memória, o disco ou a CPU ultrapassam um patamar dá tempo de agir antes do esgotamento.
• Picos de erro. Um alerta quando os erros 5xx disparam avisa do problema no momento em que ele começa, não horas depois.
• Eventos de segurança. Ser notificado de padrões suspeitos de acesso permite reagir a um ataque em andamento.

A ideia é inverter a lógica: em vez de você ir atrás dos sinais, os sinais vêm até você quando importam. Muitos painéis de hospedagem oferecem gráficos de recursos e algum tipo de alerta — vale conhecer o que o seu host disponibiliza.

Uma nota sobre logs e dados pessoais#

Logs de acesso registram endereços de quem visita e outros dados que, dependendo do contexto, são considerados informação pessoal. Isso traz uma responsabilidade: guardar logs por tempo indefinido, sem critério, pode conflitar com boas práticas de proteção de dados. O equilíbrio é manter os logs pelo período necessário para operação e segurança, e não além disso, considerando anonimizar ou reduzir dados sensíveis quando possível. Log é ferramenta de operação, não um arquivo eterno de tudo sobre todos os visitantes.

Como começar a monitorar#

Não é preciso virar administrador de sistemas para tirar proveito disso. Um caminho realista para começar:

• Descubra onde estão os seus logs. No painel da sua hospedagem, localize os logs de acesso e de erro. Só saber abri-los já muda o jogo quando um problema aparece.
• Aprenda a reconhecer os códigos de status, com atenção especial à família 5xx.
• Acompanhe os gráficos de recursos que o host oferece — CPU, memória e disco — para conhecer o comportamento normal do seu site e notar quando ele foge do padrão.
• Garanta que a rotação de logs está ativa, para não acordar com o disco cheio.
• Configure os alertas disponíveis, para ser avisado antes de o problema virar queda.

Ler os sinais do servidor transforma a relação com o site: em vez de reagir a quedas depois que os visitantes reclamam, você percebe o problema se formando e age com antecedência. E, quando precisar do suporte, chega com a informação na mão — qual erro, quando começou, o que a máquina estava fazendo — o que encurta qualquer resolução. Um servidor bem observado raramente surpreende.