Grep en Linux: encontrar un error en los logs

Un cat /var/log/syslog en un servidor activo da principalmente una cosa: demasiadas líneas. Cuando un servicio falla o un error se repite, busque primero el nombre del servicio, la hora y el mensaje preciso. grep permite reducir el ruido sin perder las líneas que explican lo que ha ocurrido justo antes.

Este método funciona en un archivo en /var/log así como en la salida de journalctl. No reemplaza el diario completo: sirve para encontrar un punto de partida fiable, y luego ampliar alrededor de ese punto.

Comenzar con una búsqueda legible

Agregue los números de línea e ignore el caso si el programa mezcla Error, ERROR o error:

grep -n -i 'error' /var/log/mi-servicio.log

-n muestra el número de línea. Se vuelve útil cuando necesita retomar el archivo en less, comparar dos búsquedas o copiar el fragmento en un ticket. Las comillas evitan que el shell interprete caracteres especiales en el patrón. El manual de grep detalla las opciones de búsqueda y contexto.

• -i busca sin distinguir mayúsculas y minúsculas.
• -n agrega el número de línea.
• -F trata el texto como una cadena literal, útil para un error que contenga ., [ o ?.
• -E activa las expresiones regulares extendidas.
• -C 3 muestra tres líneas antes y después de cada coincidencia.

Para un error exacto, prefiera -F. Una dirección IP, una ruta o un mensaje con corchetes pueden ser interpretados como una expresión regular:

grep -n -F 'connection refused [127.0.0.1:5432]' /var/log/mi-servicio.log

Mantener las líneas que explican el error

Una línea marcada ERROR rara vez indica la causa por sí sola. Muestre el contexto antes de concluir:

grep -n -i -C 3 'error' /var/log/mi-servicio.log

grep -n -i -A 5 'failed' /var/log/mi-servicio.log

grep -n -i -B 5 'panic' /var/log/mi-servicio.log

-C 3 mantiene tres líneas de cada lado. -A muestra solo las líneas siguientes, -B solo las anteriores. Si hay múltiples errores distantes, grep separa los grupos con --. Este separador no forma parte del diario.

Cuando conoce varios síntomas, ensambléelos con -E:

grep -n -i -E 'error|failed|timeout|refused' /var/log/mi-servicio.log

Este comando también devuelve mensajes que no necesariamente se relacionan con su incidente. Luego agregue el nombre del proceso, el puerto o el identificador de solicitud en lugar de alargar la lista de palabras clave al azar.

Filtrar journalctl antes de pasar a grep

Con systemd, comience por limitar el diario a la unidad y al período del incidente. Evita mezclar los mensajes de otros servicios:

journalctl -u nginx --since '30 minutes ago' --no-pager
journalctl -u nginx --since '30 minutes ago' --no-pager | grep -n -i -C 2 'error'

Reemplace nginx por el nombre real de la unidad, como postgresql, docker o su servicio aplicativo. Si el incidente sigue un reinicio, agregue -b para permanecer en el inicio actual. El manual de journalctl también describe los filtros por unidad y período. Nuestra guía sobre journalctl y los registros del último inicio detalla este filtro.

No inicie una búsqueda en años de registros antes de haber delimitado la hora del problema. Un error visto a las 14:12 merece una ventana corta alrededor de las 14:12, luego una lectura más amplia si no aparece ninguna causa.

Seguir el servicio durante la reproducción

Para un problema reproducible, abra un segundo terminal y mire solo las nuevas líneas:

journalctl -fu nginx

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

journalctl -f sigue el diario en vivo. tail -F continúa también después de una rotación de archivo, lo que es más seguro que tail -f en muchos registros aplicativos. La opción --line-buffered mantiene el flujo legible después del pipe hacia grep.

Luego desencadene una sola vez la acción que falla: una solicitud HTTP, un reinicio controlado o una conexión de prueba. Si ejecuta múltiples pruebas a la vez, no sabrá cuál línea pertenece a qué prueba. Para seguir un archivo clásico, también puede consultar nuestro método con tail.

Cuando haya encontrado un error, anote la hora, la unidad o el proceso involucrado, y luego las líneas alrededor del mensaje. Es más útil que un copia y pega de mil líneas de registros, y evita modificar una configuración antes de haber identificado el servicio responsable.

n