Grep no Linux: encontrar um erro nos logs

Um cat /var/log/syslog em um servidor ativo oferece principalmente uma coisa: muitas linhas. Quando um serviço falha ou um erro aparece, procure 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 do journalctl. Ele não substitui o log completo: serve para encontrar um ponto de partida confiável, e então expandir ao redor desse ponto.

Começar com uma busca legível

Adicione números de linha e ignore a caixa se o programa misturar Error, ERROR ou error:

grep -n -i 'error' /var/log/meu-servico.log

-n exibe o número da linha. Isso se torna útil quando você precisa retomar o arquivo no less, comparar duas pesquisas 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 pesquisa 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 que contém ., [ 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-servico.log

Manter as linhas que explicam o erro

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

grep -n -i -C 3 'error' /var/log/meu-servico.log

grep -n -i -A 5 'failed' /var/log/meu-servico.log

grep -n -i -B 5 'panic' /var/log/meu-servico.log

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

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

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

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

Filtrar journalctl antes de passar grep

Com systemd, comece limitando o log à unidade e ao período do incidente. Você evita misturar 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 ocorrer após uma reinicialização, adicione -b para permanecer na inicialização atual. O manual do journalctl também descreve os filtros por unidade e período. Nosso guia sobre journalctl e os logs da última inicialização detalha esse filtro.

Não faça uma busca em anos de logs antes de ter delimitado o horário do problema. Um erro visto às 14h12 merece uma janela curta ao redor das 14h12, e então uma leitura mais ampla se nenhuma causa aparecer.

Acompanhar 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 em tempo real. tail -F continua também após uma rotação de arquivo, o que é mais seguro que tail -f em muitos logs aplicativos. A opção --line-buffered mantém o fluxo legível após o pipe para grep.

Desencadeie então uma única vez a ação que falha: uma requisição HTTP, uma reinicialização controlada ou uma conexão de teste. Se você lançar vários testes simultaneamente, não saberá mais qual linha pertence a qual tentativa. Para seguir um arquivo clássico, você também pode consultar nosso método com tail.

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

n