grep, sed y awk: tres comandos para encontrar problemas en los logs
Publicado el 2026-10-26 por frfrand
Ejemplos útiles con grep sed awk para investigar errores en servidores
Tu API generó miles de líneas de logs y quieres encontrar solo los errores 500 de esta mañana. No hace falta abrir el archivo y deslizar diez minutos: grep, sed y awk resuelven búsquedas, sustituciones y columnas desde la terminal.
Te muestro dónde está el problema, cómo comprobarlo sin adivinar y qué haría en una aplicación que de verdad tiene usuarios. No necesitas memorizar un manual entero para resolver un fallo concreto.
Qué significa grep, sed y awk en la práctica
grep selecciona líneas por patrón, sed transforma flujos de texto y awk trabaja con campos y reglas. Son herramientas distintas que puedes combinar, pero primero necesitas saber cómo está estructurado el log que vas a leer.
Una aclaración antes de tocar el servidor: si el proyecto ya está en producción, guarda el estado que encontraste y comprueba en qué usuario y máquina vas a ejecutar los comandos. Trabajar como root sin necesidad y cambiar varias cosas a la vez dificulta encontrar la causa de un error.
Comandos útiles para empezar
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'Las rutas, nombres de unidades y dominios son ejemplos. Adáptalos a tu servicio. Si un comando requiere permisos de administrador, revisa qué cambia y por qué. Las consultas de diagnóstico deberían venir antes de las modificaciones.
Paso a paso, con comprobaciones
- Identifica si el origen del log es un archivo de texto o journalctl.
- Busca la palabra clave con
grep -ny verifica el contexto alrededor de cada coincidencia. - Para una línea concreta, usa
sed -n; sin-i,sedno modifica el archivo. - Si necesitas campos, elige un delimitador correcto con
awk -Fy prueba con pocas líneas. - Guarda comandos frecuentes en un documento de incidentes sin incluir secretos de los logs.
Después de cada paso, verifica un resultado observable: un estado, un archivo, una respuesta HTTP o una entrada de log. Si encuentras un mensaje inesperado, guárdalo para investigar en lugar de ocultarlo con reinicios repetidos.
Ejemplo real: una aplicación que hay que mantener
En una plataforma de reservas, buscas todos los 500 de una hora. Después cruzas su timestamp con errores de PostgreSQL. Encontrar la coincidencia entre API y base suele decirte más que reiniciar Nginx.
Al final, prueba el camino completo: entrar por dominio, llamar a la API, escribir un dato de prueba y verificar que la información sigue ahí tras un reinicio controlado. Un servidor que «arranca» no siempre es una aplicación que funciona.
Errores que vale la pena evitar
Un awk '{print $2}' no sirve si el campo contiene espacios o el archivo es JSON. Para logs JSON estructurados, jq suele ser más adecuado. Cuidado con sed -i: sí modifica archivos.
También es importante que las credenciales no terminen en el historial de la terminal, logs, archivos compartidos o capturas. Para usuarios y servicios, usa permisos mínimos y documenta quién puede revocar el acceso.
Cómo entra ArduMaker en este escenario
Cuando una aplicación corre en un VPS de ArduMaker, combina la terminal con registros del servicio para separar errores de backend, proxy y base de datos.
ArduMaker puede ayudarte a administrar los VPS, desplegar repositorios y trabajar con servicios, bases y dominios desde la misma plataforma. No reemplaza lo que acabamos de explicar sobre Linux: precisamente por eso conviene entender el diagnóstico y tener una forma de repetirlo.
Cuándo conviene automatizarlo
Si la tarea se repite, documenta primero el procedimiento manual y sus comprobaciones. Después considera un script o una tarea programada con errores visibles, logs y permisos limitados. No automatices un comando que todavía no sepas recuperar cuando sale mal.
Preguntas habituales
¿Puedo probarlo sin afectar clientes? En muchos casos sí: un VPS de staging o un servicio de prueba separado permite validar la configuración antes de cambiar producción.
¿Cómo sé si quedó bien? Mira logs y una operación funcional, no solamente que el comando terminó con código cero.
¿Cuándo necesito más recursos? Cuando las métricas indiquen saturación de CPU, RAM, disco o conexiones. Un fallo de configuración rara vez se arregla contratando más memoria.
Referencias
En una frase: primero entiende el error, después cambia una cosa concreta y comprueba su efecto. Esa disciplina te ahorra muchas horas de soporte.