Logs do Apache: access.log e error.log, formatos e interpretação prática

O que são os logs do Apache e por que eles importam

O Apache registra eventos em arquivos de log para que você consiga observar o que está acontecendo no servidor em tempo real e também investigar problemas depois que eles ocorreram. Em geral, você vai trabalhar com dois logs principais:

• access.log: registra cada requisição HTTP atendida (ou negada) pelo servidor, com dados como IP do cliente, método, URL, status HTTP e tamanho da retorno.
• error.log: registra erros e avisos do servidor (problemas de configuração, permissões, falhas de módulos, arquivos inexistentes, erros de aplicação via proxy/CGI etc.).

Os caminhos exatos variam por distribuição e configuração, mas é comum encontrar em /var/log/apache2/ (Debian/Ubuntu) ou /var/log/httpd/ (RHEL/CentOS/Fedora). Em ambientes com Virtual Hosts, pode existir um par de logs por site (por exemplo, site-access.log e site-error.log).

access.log: o que observar e como interpretar

Campos mais comuns (formato “combined”)

Um formato muito usado é o combined. Uma linha típica pode parecer assim:

203.0.113.10 - - [25/Jan/2026:10:15:42 +0000] "GET /produtos/123 HTTP/1.1" 200 5321 "https://exemplo.com/" "Mozilla/5.0 ..."

Leitura prática dos campos:

• IP do cliente (203.0.113.10): origem da requisição. Em ambientes com proxy/CDN, pode não ser o IP real (depende de configuração de cabeçalhos).
• Data/hora: útil para correlacionar com o error.log e com eventos (deploy, reload, mudanças).
• Request line: método (GET/POST), caminho (/produtos/123) e protocolo.
• Status HTTP: resultado (ex.: 200, 404, 500).
• Tamanho: bytes enviados na resposta (pode ser - em alguns casos).
• Referer: de onde o usuário veio (pode ajudar a achar links quebrados).
• User-Agent: navegador/bot; útil para identificar crawlers e tráfego automatizado.

Códigos HTTP comuns (interpretação prática)

error.log: o que observar e como interpretar

O error.log é onde o Apache explica por que algo falhou. Ele costuma incluir nível (error/warn/notice), PID/TID e, às vezes, o cliente:

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

[Wed Jan 25 10:16:01.123456 2026] [core:error] [pid 1234] [client 203.0.113.10:54321] AH00132: file permissions deny server access: /var/www/site/privado

O que observar:

• Timestamp: base para correlacionar com o access.log.
• Módulo/área (ex.: [core:error]): indica a origem do erro (core, authz, rewrite, ssl, proxy etc.).
• Código AH (ex.: AH00132): identificador do Apache; útil para pesquisar e padronizar diagnósticos.
• Client: IP e porta do cliente (quando presente).
• Mensagem: geralmente aponta o caminho do arquivo, diretiva, ou motivo (permissão, arquivo ausente, sintaxe inválida).

Erros típicos que aparecem no error.log

• Permissão negada: mensagens com “permission denied” ou “file permissions deny server access”.
• Arquivo inexistente: “File does not exist” (muito comum junto de 404).
• Problemas de configuração: “Syntax error”, “Invalid command”, “AH00526” (falha ao iniciar/recarregar por config inválida).
• Problemas de rewrite: loops e regras inválidas podem gerar mensagens do módulo rewrite (quando loglevel adequado).

Correlacionando access.log e error.log na prática

A correlação normalmente é feita por tempo e, quando disponível, por IP do cliente e URL. Um fluxo típico:

• Você identifica no access.log uma requisição com status 403, 404 ou 500.
• Anota timestamp aproximado, IP e caminho.
• Procura no error.log no mesmo intervalo de tempo por mensagens relacionadas (muitas vezes o Apache registra o caminho do arquivo e o motivo).

Exemplo de correlação (404):

access.log: 203.0.113.10 - - [25/Jan/2026:10:20:10 +0000] "GET /img/logo.png HTTP/1.1" 404 489 "-" "Mozilla/5.0"

error.log: [Wed Jan 25 10:20:10.010101 2026] [core:info] [pid 2222] [client 203.0.113.10:55555] AH00128: File does not exist: /var/www/site/img/logo.png

A linha do error.log revela o caminho real que o Apache tentou acessar, o que ajuda a confirmar se o arquivo está faltando ou se o mapeamento do site está apontando para o lugar errado.

Leitura ao vivo e filtros: tail, grep e awk

Acompanhar em tempo real com tail

Para “assistir” requisições e erros enquanto você testa no navegador ou com curl:

tail -f /var/log/apache2/access.log

tail -f /var/log/apache2/error.log

Dica: use duas janelas/abas de terminal, uma para cada log, e reproduza o problema.

Filtrar por status HTTP com grep

Encontrar apenas 404 no access.log:

grep ' 404 ' /var/log/apache2/access.log

Encontrar 403:

grep ' 403 ' /var/log/apache2/access.log

Encontrar 500:

grep ' 500 ' /var/log/apache2/access.log

Filtrar por um caminho específico:

grep 'GET /admin' /var/log/apache2/access.log

Filtrar por IP e correlacionar com error.log

Primeiro, pegue o IP do cliente no access.log e filtre:

grep '^203.0.113.10 ' /var/log/apache2/access.log

Depois, procure o mesmo IP no error.log (quando o Apache inclui o campo client):

grep '203.0.113.10' /var/log/apache2/error.log

Extraindo campos com awk (contagens rápidas)

No formato “combined”, o status costuma ser o penúltimo campo antes do tamanho (isso pode variar se o formato de log foi customizado). Uma forma prática de contar status:

awk '{print $(NF-1)}' /var/log/apache2/access.log | sort | uniq -c | sort -nr

Contar os caminhos mais acessados (aproximação simples extraindo o 7º campo, que costuma ser a URL em muitos formatos padrão):

awk '{print $7}' /var/log/apache2/access.log | sort | uniq -c | sort -nr | head

Filtrar apenas 404 e listar URLs mais frequentes (ajuda a achar links quebrados):

awk '$(NF-1)==404 {print $7}' /var/log/apache2/access.log | sort | uniq -c | sort -nr | head

Observação: se o seu LogFormat foi alterado, posições como $7 podem mudar. Se um comando não fizer sentido com seus dados, inspecione uma linha e ajuste o campo.

Passo a passo: investigar 404 (origem e causa)

1) Identificar a URL e o volume de 404

grep ' 404 ' /var/log/apache2/access.log | tail -n 20

Se houver muitos 404, descubra quais URLs mais aparecem:

awk '$(NF-1)==404 {print $7}' /var/log/apache2/access.log | sort | uniq -c | sort -nr | head -n 10

2) Verificar se há pista no error.log

Procure “File does not exist” no mesmo período:

grep -i 'file does not exist' /var/log/apache2/error.log | tail -n 50

Se o erro mostrar um caminho completo no disco, compare com o que você espera que seja servido. Isso ajuda a diferenciar:

• Arquivo realmente ausente (precisa ser publicado/criado).
• URL errada (link quebrado no site).
• Mapeamento incorreto (o Apache está apontando para um diretório diferente do esperado).

3) Correlacionar por IP e minuto

Pegue uma linha do access.log com 404 e use o IP e o horário aproximado para buscar no error.log:

grep '^203.0.113.10 ' /var/log/apache2/access.log | grep ' 404 ' | tail -n 5

grep '203.0.113.10' /var/log/apache2/error.log | tail -n 20

Passo a passo: diagnosticar 403 (permissão e regras)

Um 403 significa que o Apache entendeu a requisição, mas decidiu não entregar o conteúdo. As causas mais comuns são permissão/execução no caminho, regras de acesso, ou listagem de diretório desabilitada sem arquivo índice.

1) Confirmar o 403 no access.log

grep ' 403 ' /var/log/apache2/access.log | tail -n 20

Observe a URL e o IP do cliente.

2) Buscar a explicação no error.log

Filtre por “permission” e “client denied”:

grep -iE 'permission|client denied|access denied|AH00132' /var/log/apache2/error.log | tail -n 50

Mensagens típicas e o que indicam:

• file permissions deny server access: o Apache não conseguiu atravessar diretórios (falta de execução) ou ler o arquivo.
• client denied by server configuration: regra de acesso negou (por exemplo, diretivas de autorização aplicadas a um diretório/localização).
• Directory index forbidden by Options directive: acesso a um diretório sem DirectoryIndex disponível e listagem desabilitada.

3) Validar se é permissão no filesystem (pista pelo caminho)

Quando o error.log mostra um caminho como /var/www/site/privado, verifique permissões e propriedade no sistema:

ls -ld /var/www/site /var/www/site/privado

ls -l /var/www/site/privado

O ponto-chave é: o usuário do processo do Apache precisa conseguir atravessar (permissão de execução) todos os diretórios do caminho e ler o arquivo. Se o erro for “directory index forbidden”, verifique se existe um arquivo de índice esperado (por exemplo, index.html) dentro do diretório requisitado.

Passo a passo: localizar falhas de configuração após reload

Quando você recarrega a configuração, erros de sintaxe ou diretivas inválidas costumam aparecer imediatamente no error.log e/ou no retorno do comando de reload. A ideia aqui é: recarregar, e em seguida olhar o trecho mais recente do error.log.

1) Recarregar e capturar o momento

Em outra janela, deixe o error.log “ao vivo”:

tail -f /var/log/apache2/error.log

Então execute o reload (o comando exato depende do seu sistema):

sudo systemctl reload apache2

ou:

sudo systemctl reload httpd

2) Identificar mensagens de falha

Procure por termos comuns:

grep -iE 'syntax error|invalid command|AH00526|AH' /var/log/apache2/error.log | tail -n 50

Exemplos do que você pode ver:

• Syntax error: aponta arquivo e linha onde a configuração quebrou.
• Invalid command: diretiva desconhecida (módulo não carregado ou diretiva escrita incorretamente).
• AH00526: falha ao ler configuração; normalmente vem acompanhada do detalhe (arquivo/linha).

3) Focar no trecho mais recente

Se o log for grande, veja apenas as últimas linhas após o reload:

tail -n 100 /var/log/apache2/error.log

Em seguida, refine com grep para achar a mensagem principal.

Exercícios práticos (comandos e critérios de verificação)

Exercício 1: identificar a origem de 404

Objetivo: descobrir quais URLs estão gerando 404 e de onde elas vêm.

• Passo 1: liste as 10 URLs com mais 404:

awk '$(NF-1)==404 {print $7}' /var/log/apache2/access.log | sort | uniq -c | sort -nr | head -n 10

• Passo 2: para a URL mais frequente, veja exemplos com referer (quando disponível) para achar a página que aponta para ela:

grep ' 404 ' /var/log/apache2/access.log | grep '/caminho/que-falha' | tail -n 20

• Passo 3: procure no error.log o caminho no disco que o Apache tentou acessar:

grep -i 'file does not exist' /var/log/apache2/error.log | grep '/caminho/que-falha' | tail -n 20

Critério de verificação: você deve conseguir apontar se o 404 é por arquivo ausente, link quebrado (referer) ou mapeamento incorreto (caminho no disco inesperado).

Exercício 2: diagnosticar um 403 por permissão

Objetivo: confirmar que o 403 é causado por permissão no filesystem (e não por regra de acesso).

• Passo 1: encontre uma requisição 403 e anote URL e horário:

grep ' 403 ' /var/log/apache2/access.log | tail -n 10

• Passo 2: encontre a mensagem correspondente no error.log:

grep -iE 'permission|file permissions deny|client denied|directory index forbidden' /var/log/apache2/error.log | tail -n 50

• Passo 3: se houver um caminho de arquivo/diretório na mensagem, verifique permissões:

ls -ld /caminho/do/diretorio

ls -l /caminho/do/arquivo

Critério de verificação: você deve conseguir classificar o 403 em uma das categorias: (a) permissão/execução no caminho, (b) diretiva/regra de acesso negando, (c) falta de arquivo índice com listagem desabilitada.

Exercício 3: localizar falhas de configuração após reload

Objetivo: identificar rapidamente o arquivo e a linha que quebraram o reload.

• Passo 1: deixe o error.log em tempo real:

tail -f /var/log/apache2/error.log

• Passo 2: execute o reload e observe as mensagens novas:

sudo systemctl reload apache2

• Passo 3: se perder a mensagem, filtre por “Syntax error” e “AH00526”:

grep -iE 'syntax error|AH00526|invalid command' /var/log/apache2/error.log | tail -n 30

Critério de verificação: você deve conseguir apontar exatamente qual arquivo e linha precisam ser corrigidos.

Boas práticas básicas: rotação e tamanho de logs (visão geral)

Logs crescem continuamente. Se não houver rotação, eles podem ocupar muito disco e dificultar buscas. Boas práticas básicas:

• Rotacionar periodicamente (por tempo e/ou tamanho): cria arquivos “antigos” (ex.: access.log.1) e inicia um novo access.log.
• Manter retenção: guardar apenas uma quantidade razoável de históricos (por exemplo, alguns dias/semanas), conforme necessidade.
• Comprimir logs antigos: reduz uso de disco (ex.: arquivos .gz).
• Separar por site quando houver múltiplos Virtual Hosts: facilita análise e reduz ruído.
• Monitorar espaço em disco: falta de espaço pode causar falhas indiretas e perda de evidências.

Mesmo sem entrar em ferramentas específicas, o importante é entender o objetivo: manter logs utilizáveis, pesquisáveis e com histórico suficiente para investigações.