grep, sed e awk: três comandos para encontrar problemas nos logs

Publicado em 2026-10-26 por frfrand

Exemplos úteis com grep, sed e awk para investigar erros em servidores

grep, sed e awk: três comandos para encontrar problemas nos logs

Sua API gerou milhares de linhas de logs e você quer encontrar apenas os erros 500 de hoje de manhã. Não é preciso abrir o arquivo e rolar por dez minutos: grep, sed e awk resolvem buscas, substituições e colunas direto do terminal.

Te mostro onde está o problema, como verificá-lo sem chutar e o que faria em um aplicativo que realmente tem usuários. Não é preciso decorar um manual inteiro para resolver uma falha específica.

O que significam grep, sed e awk na prática

grep seleciona linhas por padrão, sed transforma fluxos de texto e awk trabalha com campos e regras. São ferramentas distintas que você pode combinar, mas primeiro precisa saber como está estruturado o log que vai ler.

Uma observação antes de acessar o servidor: se o projeto já está em produção, salve o estado que encontrou e verifique em qual usuário e máquina você vai executar os comandos. Trabalhar como root sem necessidade e mudar várias coisas ao mesmo tempo dificulta encontrar a causa de um erro.

Comandos úteis para começar

grep -n 'ERROR' /var/log/miapp/app.log | tail -20
# Ver un rango sin modificar el archivo
sed -n '100,120p' /var/log/miapp/app.log
# Ejemplo con un archivo de tres columnas separado por espacios
awk '{print $1, $3}' accesos.txt
# Para logs de systemd
journalctl -u miapp --since '1 hour ago'

Os caminhos, nomes de unidades e domínios são exemplos. Adapte-os ao seu serviço. Se um comando exigir permissões de administrador, revise o que muda e por que. As consultas de diagnóstico devem vir antes das modificações.

Passo a passo, com verificações

Identifique se a origem do log é um arquivo de texto ou o journalctl.
Busque a palavra-chave com grep -n e verifique o contexto ao redor de cada coincidência.
Para uma linha concreta, use sed -n; sem -i, o sed não modifica o arquivo.
Se precisar de campos, escolha um delimitador correto com awk -F e teste com poucas linhas.
Guarde comandos frequentes em um documento de incidentes sem incluir segredos dos logs.

Após cada passo, verifique um resultado observável: um estado, um arquivo, uma resposta HTTP ou uma entrada de log. Se encontrar uma mensagem inesperada, salve-a para investigar em vez de ocultá-la com reinícios repetidos.

Exemplo real: uma aplicação que precisa ser mantida

Em uma plataforma de reservas, você busca todos os 500 de uma hora. Depois cruza o timestamp com erros do PostgreSQL. Encontrar a coincidência entre API e banco de dados costuma dizer mais do que reiniciar o Nginx.

Ao final, teste o caminho completo: entrar pelo domínio, chamar a API, gravar um dado de teste e verificar que a informação continua lá após um reinício controlado. Um servidor que «arranca» nem sempre é uma aplicação que funciona.

Erros que vale a pena evitar

Um awk '{print $2}' não serve se o campo contiver espaços ou o arquivo for JSON. Para logs JSON estruturados, o jq costuma ser mais adequado. Cuidado com o sed -i: ele modifica arquivos.

Também é importante que as credenciais não terminem no histórico do terminal, logs, arquivos compartidos ou capturas. Para usuários e serviços, use permissões mínimas e documente quem pode revogar o acesso.

Como o ArduMaker entra neste cenário

Quando uma aplicação roda em um VPS da ArduMaker, combine o terminal com registros do serviço para separar erros de backend, proxy e banco de dados.

A ArduMaker pode ajudar você a administrar os VPS, implantar repositórios e trabalhar com serviços, bancos e domínios a partir da mesma plataforma. Não substitui o que acabamos de explicar sobre Linux: precisamente por isso convém entender o diagnóstico e ter uma forma de repeti-lo.

Quando convém automatizá-lo

Se a tarefa se repete, documente primeiro o procedimento manual e suas verificações. Depois considere um script ou uma tarefa agendada com erros visíveis, logs e permissões limitadas. Não automatize um comando que você ainda não sabe recuperar quando dá errado.

Perguntas frequentes

Posso testar sem afetar clientes? Em muitos casos, sim: um VPS de staging ou um serviço de teste separado permite validar a configuração antes de alterar a produção.

Como saber se ficou certo? Veja logs e uma operação funcional, não apenas se o comando terminou com código zero.

Quando preciso de mais recursos? Quando as métricas indicarem saturação de CPU, RAM, disco ou conexões. Uma falha de configuração raramente se resolve contratando mais memória.

Referências

Em uma frase: primeiro entenda o erro, depois mude uma coisa concreta e verifique seu efeito. Essa disciplina te economiza muitas horas de suporte.