Contenido
- 1 Hurgando en el historial del VPS: qué hace cada comando — y por qué el técnico los lanzó
- 1.1 1. Filtro milimétrico por minuto y sin «notices»
- 1.2 2. El mismo minuto, pero sin filtrar avisos
- 1.3 3 y 4. Afinando por segundos
- 1.4 5. Volver a la vista global del minuto
- 1.5 6. Siguiendo la pista a una IP sospechosa
- 1.6 7. Rastreo por identificador interno
- 1.7 8. Otra franja horaria bajo la lupa
- 1.8 9. Asomarse a lo más reciente
- 2 Conclusión
Hurgando en el historial del VPS: qué hace cada comando — y por qué el técnico los lanzó
Cuando un sysadmin deja huellas en tu servidor, su historial de comandos puede convertirse en una clase magistral de diagnóstico. A continuación repaso, en clave de “entrada de blog”, los diez comandos que encontraste: qué hacen exactamente y la lógica que hay detrás de cada uno.
1. Filtro milimétrico por minuto y sin «notices»
cat /var/log/httpd/domains/tiendaonline.com.error.log \
| fgrep "Wed Jan 29 13:40:" \
| fgrep -v "PHP message: PHP Notice:"
catvuelca todo el archivo de error del vHost.- Primer
fgrepconserva sólo las líneas cuyo prefijo de fecha-hora seaWed Jan 29 13:40:(es decir, cualquier segundo dentro de las 13:40). - Segundo
fgrep -vdescarta las líneas que contienen el literalPHP Notice, limpiando avisos poco críticos para quedarse con errores “de verdad”.
Uso típico: centrar la lupa en el minuto exacto del fallo y eliminar la paja de los avisos de PHP.
2. El mismo minuto, pero sin filtrar avisos
cat /var/log/httpd/domains/tiendaonline.com.error.log | fgrep "Wed Jan 29 13:40:"
Aquí se repite el filtrado por minuto, pero sin la exclusión de notices. Suele hacerse antes (o después) del paso anterior para tener la foto completa y luego decidir qué descartar.
3 y 4. Afinando por segundos
# segundos del 20 al 29
cat ...error.log | fgrep "Wed Jan 29 13:40:2"
# segundo exacto 13:40:20
cat ...error.log | fgrep "Wed Jan 29 13:40:20"
La misma técnica llevada al detalle:
- Añadir
2después de13:40:acota a los segundos 20-29. - Especificar
13:40:20clava un único segundo.
¿Por qué tanto zoom? Para averiguar qué petición (o atacante) detonó el problema en un instante concreto.
5. Volver a la vista global del minuto
cat ...error.log | fgrep "Wed Jan 29 13:40:"
Una segunda pasada idéntica a la del punto 2. Tras jugar con segundos concretos, el técnico suele regresar a la panorámica para comprobar que nada se le escapó.
6. Siguiendo la pista a una IP sospechosa
cat ...error.log | fgrep "148.56.129.205"
Busca todas las entradas donde aparezca la IP 148.56.129.205—quizás un bot, un atacante o el mismo cliente detrás de la incidencia.
7. Rastreo por identificador interno
fgrep "seidivid" tiendaonline.com.error.log
Sin cat: fgrep lee el archivo directo. El literal seidivid podría ser:
- un nombre de usuario,
- una cookie de sesión,
- un parámetro GET/POST…
Sea lo que sea, el comando lista cada línea en la que salga para seguir el hilo del bug.
8. Otra franja horaria bajo la lupa
fgrep "Jan 29 08:4" tiendaonline.com.error.log
08:4 significa “cualquier segundo entre 08:40 y 08:49”. Probablemente el técnico quiso comparar la franja de la mañana frente a la de la tarde para descartar patrones.
9. Asomarse a lo más reciente
tail -100 tiendaonline.com.error.log
Tail muestra las últimas 100 líneas del log. Es la forma más rápida de ver qué pasó justo ahora, sin tener que abrir un archivo enorme con less.
Añadir
-f(“follow”) convertiría el comando en un visor en tiempo real.
Conclusión
Revisar el historial de la terminal no es cotilleo: es un método excelente para aprender prácticas de depuración. Ahora ya sabes por qué tu proveedor lanzó cada línea y cómo aplicar tú mismo estos filtros la próxima vez que tu servidor se ponga rebelde. ¡Feliz logging!
Deja una respuesta