Guia de Logs do Nginx/Apache - Localizacao e Analise de access/error Log

2025-12-16 Tempo de leitura: Cerca de 12 min Dificuldade: Intermediario

O que voce vai aprender

• Onde ficam os arquivos de log do Nginx/Apache no Ubuntu
• Como isolar as causas de "500/502/503/504", "403", "404" a partir dos logs
• Uma abordagem sistematica para investigacao de logs (ordem, filtragem, reproducao, verificacao)
• Entender que o crescimento dos logs pode causar problemas de disco

1. Verifique qual servidor esta rodando (Nginx? Apache?)

Conclusao: Confirme qual servidor esta ativo com systemctl antes de abrir qualquer arquivo de log.

Pule se voce ja sabe.

1-1. Verificar pelo status do servico

$ sudo systemctl status nginx
$ sudo systemctl status apache2

• nginx esta ativo -> Verifique os logs do Nginx
• apache2 esta ativo -> Verifique os logs do Apache
• Ambos ativos -> Provavelmente configuracao de proxy reverso (verifique os logs do front-end primeiro)

1-2. Verificar pela porta (complementar)

$ sudo ss -lntp | grep ':80 '
$ sudo ss -lntp | grep ':443 '

2. Localizacao dos logs (caminhos tipicos no Ubuntu)

Conclusao: Logs do Nginx: /var/log/nginx/; Apache: /var/log/apache2/ por padrao no Ubuntu.

Geralmente ficam aqui no Ubuntu:

2-1. Nginx

• error log: /var/log/nginx/error.log
• access log: /var/log/nginx/access.log

$ ls -la /var/log/nginx

2-2. Apache (apache2)

• error log: /var/log/apache2/error.log
• access log: /var/log/apache2/access.log

$ ls -la /var/log/apache2

3. Primeiro verifique o "error log" (caminho mais rapido)

Conclusao: Sempre leia o error.log primeiro — a causa raiz aparece la, nao no access.log.

O access log mostra "o que aconteceu", mas a causa raiz (stack trace/erro de configuracao/upstream morto) aparece no error.log.

3-1. Ver as ultimas 200 linhas (primeiro passo)

# Nginx
$ sudo tail -n 200 /var/log/nginx/error.log

# Apache
$ sudo tail -n 200 /var/log/apache2/error.log

3-2. Acompanhamento em tempo real enquanto reproduz (mais eficaz)

# Nginx
$ sudo tail -f /var/log/nginx/error.log

# Apache
$ sudo tail -f /var/log/apache2/error.log

4. Encontre a requisicao com falha no access log

Conclusao: grep " 500 " access.log isola as falhas para cruzar com o error.log.

4-1. Encontrar apenas erros 500

$ sudo grep " 500 " /var/log/nginx/access.log | tail -n 50

4-2. Encontrar apenas erros 404

$ sudo grep " 404 " /var/log/nginx/access.log | tail -n 50

4-3. Encontrar apenas um caminho especifico (ex.: /api/)

$ sudo grep " /api/" /var/log/nginx/access.log | tail -n 50

5. Guia de isolamento por codigo de status

Conclusao: O codigo mapeia para a camada: 500=app, 502/503=upstream, 403=permissoes, 404=roteamento.

5-1. 500 (Internal Server Error)

• Erro interno da aplicacao (PHP/Node/Ruby, etc.)
• Erro de configuracao (configuracoes FastCGI, etc.)
• Possivel problema de permissao/caminho (Permission denied)

Proximo: error.log (prioridade), logs da aplicacao, journalctl -u

5-2. 502 / 503 / 504 (Bad Gateway / Service Unavailable / Gateway Timeout)

• Nginx/Apache nao consegue conectar ao upstream / resposta lenta / inativo

Proximo passo:

$ nc -vz 127.0.0.1 3000
$ curl -I http://127.0.0.1:3000

5-3. 403 (Forbidden)

• Autenticacao basica, restricao de IP, WAF, permissao de diretorio, permissao de arquivo

Proximo: error.log mostrara "permission denied" ou "client denied"

5-4. 404 (Not Found)

• Roteamento / arquivo nao existe
• Configuracao de rewrite para SPA ausente

6. Encontrando localizacoes de log nao padrao

Conclusao: nginx -T | grep error_log ou apache2ctl -S encontra caminhos de log nao padrao.

6-1. Nginx: Exibir toda a configuracao

$ sudo nginx -T 2>&1 | grep -E "access_log|error_log" | head -n 50

6-2. Apache: Verificar configuracao

$ sudo apache2ctl -S

7. Dicas de filtragem para investigacao mais rapida

Conclusao: Reproduza o erro com tail -f error.log aberto — esse e o caminho mais rapido.

7-1. Quer ver apenas o que esta acontecendo agora

Melhor: "reproduzir -> tail -f"

7-2. Filtrar por palavra-chave (ex.: upstream)

$ sudo grep -i "upstream" /var/log/nginx/error.log | tail -n 50

8. Mensagens comuns no error.log

Conclusao: "refused" e upstream inativo; "timed out" e lento; "denied" e acesso a arquivo.

8-1. connect() failed (111: Connection refused) while connecting to upstream

Significado: Upstream nao esta escutando / inativo

$ nc -vz 127.0.0.1 <upstream-port>
$ sudo systemctl status <app-service>

8-2. upstream timed out (110: Connection timed out)

Significado: Upstream esta lento/congestionado (carga, banco de dados, I/O, etc.)

8-3. permission denied

Significado: Problema de permissao de arquivo/diretorio, possivelmente SELinux/AppArmor

8-4. client intended to send too large body

Significado: Limite de tamanho de upload (nginx client_max_body_size, etc.)

9. O que evitar

Conclusao: Nunca reinicie antes de ler o error.log — o uso de disco pelos logs tambem precisa de monitoramento.

Nao faca: Reiniciar repetidamente sem verificar os logs

Reiniciar sem verificar os logs apenas esconde a causa e perde tempo. Verifique error.log / journalctl primeiro.

Nao faca: Verificar apenas o access.log e parar por ai

A causa raiz geralmente esta no error.log. O access log serve para "qual requisicao falhou".

Nao faca: Ignorar o crescimento dos logs

Mais trafego = mais logs. Pode levar a disco cheio (No space left). Monitore o disco e configure a rotacao de logs (logrotate).

# Status do servico
sudo systemctl status nginx

# Erro (verifique primeiro)
sudo tail -n 200 /var/log/nginx/error.log

# Acompanhamento em tempo real enquanto reproduz (mais eficaz)
sudo tail -f /var/log/nginx/error.log

# Encontrar requisicoes com falha
sudo grep " 500 " /var/log/nginx/access.log | tail -n 50
sudo grep " 502 " /var/log/nginx/access.log | tail -n 50
sudo grep " 403 " /var/log/nginx/access.log | tail -n 50
sudo grep " 404 " /var/log/nginx/access.log | tail -n 50