Grep en Linux: encontrar un error en los registros

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

Este método funciona en un archivo bajo /var/log así como en la salida de journalctl. No reemplaza el registro completo: sirve para encontrar un punto de partida confiable, 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 extracto 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 contiene ., [ o ?.
• -E activa 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. Muestra 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 a cada lado. -A muestra solo las líneas siguientes, -B solo las anteriores. Si hay varios errores distantes, grep separa los grupos con --. Este separador no forma parte del registro.

Cuando conoce varios síntomas, ensamélelos con -E:

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

Este comando también devuelve mensajes que no necesariamente concernen a 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 limitando el registro a la unidad y al período del incidente. Evita mezclar mensajes de otros servicios:

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'

Reemplace nginx con el nombre real de la unidad, por ejemplo postgresql, docker o su servicio de aplicación. Si el incidente sigue a un reinicio, agregue -b para permanecer en el arranque 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 arranque detalla este filtro.

No realice 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 observe 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 registro en vivo. tail -F también continúa después de una rotación de archivo, lo cual es más seguro que tail -f en muchos registros de aplicaciones. La opción --line-buffered mantiene el flujo legible después de la tubería 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 realiza varias pruebas a la vez, no sabrá qué línea pertenece a qué intento. 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 en cuestión, y luego las líneas alrededor del mensaje. Es más útil que un copiar y pegar de mil líneas de registros, y evita modificar una configuración antes de haber identificado el servicio responsable.

n

sudo apt update && sudo apt upgrade