Grep no Linux: encontrar um erro nos logs

Um cat /var/log/syslog em um servidor ativo mostra principalmente uma coisa: muitas linhas. Quando um serviço falha ou um erro aparece, busque primeiro o nome do serviço, a hora e a mensagem exata. O grep permite reduzir o ruído sem perder as linhas que explicam o que aconteceu logo antes.

Esse método funciona em um arquivo sob /var/log assim como na saída de journalctl. Ele não substitui o log completo: serve para encontrar um ponto de partida confiável, e depois expandir em torno desse ponto.

Tux procura um erro específico em logs Linux com uma lupa — Busque um erro específico e depois revise as linhas ao seu redor.

Começar com uma busca legível

Adicione os números das linhas e ignore a case se o programa misturar Error, ERROR ou error:

grep -n -i 'error' /var/log/meu-serviço.log

-n exibe o número da linha. Ele se torna útil quando você precisa retomar o arquivo no less, comparar duas buscas ou copiar o trecho para um ticket. As aspas evitam que o shell interprete caracteres especiais no padrão. O manual do grep detalha as opções de busca e contexto.

-i busca sem distinguir maiúsculas de minúsculas.
-n adiciona o número da linha.
-F trata o texto como uma string literal, útil para um erro contendo ., [ ou ?.
-E ativa expressões regulares estendidas.
-C 3 exibe três linhas antes e depois de cada correspondência.

Para um erro exato, prefira -F. Um endereço IP, um caminho ou uma mensagem com colchetes pode ser interpretado como uma expressão regular:

grep -n -F 'connection refused [127.0.0.1:5432]' /var/log/meu-serviço.log

Manter as linhas que explicam o erro

Uma linha marcada como ERROR raramente indica a causa sozinha. Mostre o contexto antes de concluir:

grep -n -i -C 3 'error' /var/log/meu-serviço.log

grep -n -i -A 5 'failed' /var/log/meu-serviço.log

grep -n -i -B 5 'panic' /var/log/meu-serviço.log

-C 3 mantém três linhas de cada lado. -A exibe apenas as linhas seguintes, -B apenas as anteriores. Se várias falhas estão distantes, grep separa os grupos com --. Esse separador não faz parte do log.

Quando você conhece vários sintomas, junte-os com -E:

grep -n -i -E 'error|failed|timeout|refused' /var/log/meu-serviço.log

Esse comando também retorna mensagens que não dizem respeito necessariamente ao seu incidente. Adicione depois o nome do processo, a porta ou o identificador da requisição ao invés de alongar a lista de palavras-chave aleatoriamente.

Filtrar journalctl antes de passar grep

Com systemd, comece limitando o log à unidade e ao período do incidente. Você evita misturar as mensagens de outros serviços:

journalctl -u nginx --since '30 minutos atrás' --no-pager
journalctl -u nginx --since '30 minutos atrás' --no-pager | grep -n -i -C 2 'error'

Substitua nginx pelo nome real da unidade, por exemplo postgresql, docker ou seu serviço aplicativo. Se o incidente ocorreu após um reinício, adicione -b para permanecer na inicialização atual. O manual do journalctl também descreve filtros por unidade e por período. Nosso guia sobre journalctl e os logs do último início detalha esse filtro.

Não inicie uma pesquisa em anos de logs antes de definir a hora do problema. Um erro visto às 14h12 merece uma janela curta em torno das 14h12, e depois uma leitura mais ampla se nenhuma causa aparecer.

Monitorar o serviço durante a reprodução

Para um problema reproduzível, abra um segundo terminal e veja apenas as novas linhas:

journalctl -fu nginx

tail -F /var/log/nginx/error.log | grep --line-buffered -i -E 'error|warn|failed'

journalctl -f acompanha o log ao vivo. tail -F continua também após uma rotação de arquivo, o que é mais seguro do que tail -f na maioria dos logs aplicativos. A opção --line-buffered mantém o fluxo legível após o pipe para grep.

Em seguida, desencadeie apenas uma vez a ação que falha: uma requisição HTTP, uma reinicialização controlada ou uma conexão de teste. Se você executar vários testes ao mesmo tempo, não saberá mais qual linha pertence a qual teste. Para acompanhar um arquivo clássico, você também pode consultar nossa metodologia com tail.

Quando você encontrar um erro, anote a hora, a unidade ou o processo afetado, e depois as linhas ao redor da mensagem. Isso é mais útil do que um copiar-colar de mil linhas de logs, e evita modificar uma configuração antes de ter identificado o serviço responsável.