Tail en Linux: monitorización de un registro en tiempo real sin volver a ejecutar el comando cada diez segundos.

Cuando un servicio de Linux deja de responder o una aplicación comienza a generar errores, ejecutar el mismo comando cada diez segundos se vuelve rápidamente tedioso. Este es exactamente el tipo de situación en la que cola Ofrece un servicio: se muestran las últimas líneas de un archivo y, a continuación, se puede seguir lo que sucede en tiempo real.

Lo uso principalmente para revisar los registros durante el reinicio de un servicio, una conexión SSH, un error de Nginx o cuando un script escribe en un archivo. No es una herramienta de diagnóstico milagrosa, pero suele ser la forma más rápida de comprobar si algo está sucediendo realmente.

¿Cuál es la finalidad del comando tail en Linux?

el orden cola Muestra el final de un archivo. Sin ninguna opción, muestra las últimas diez líneas:

tail /var/log/syslog

En Debian o Ubuntu, dependiendo de su configuración, también puede encontrar archivos como /var/log/auth.log, /var/log/nginx/error.log o registros de aplicaciones colocados en /var/log/nombre-del-servicio/.

Lo primero que hay que hacer antes de continuar es comprobar que el archivo existe y que tienes permiso para leerlo.

ls -lh /var/log/syslog
sudo tail /var/log/syslog

Si el comando no devuelve nada, no necesariamente significa que haya fallado. El archivo puede estar vacío, no existir en tu distribución o haber sido reemplazado por el registro de systemd.

Mostrar más o menos líneas con tail -n

Por defecto, diez líneas rara vez son suficientes cuando intentas comprender un error. Con -norteUsted elige el número de líneas que desea mostrar:

tail -n 50 /var/log/syslog
sudo tail -n 100 /var/log/nginx/error.log

Te aconsejo que empieces con 50 o 100 líneas. Si solicitas 5000 líneas, pierdes el beneficio de `tail` y a veces sería mejor abrir el archivo con menos o para filtrar directamente.

Para un archivo muy detallado, también puede combinar tail con grep :

sudo tail -n 200 /var/log/syslog | grep -i "error"

Sin embargo, ten cuidado: filtrar demasiado pronto puede hacer que te pierdas el mensaje justo antes del error. Cuando aún no sé qué estoy buscando, leo primero las líneas sin formato.

Sigue un registro en vivo con tail -f

La opción más útil es -FMantiene el comando abierto y muestra las nuevas líneas tan pronto como se escriben en el archivo:

sudo tail -f /var/log/syslog

A continuación, puede abrir una segunda terminal, reiniciar el servicio, restablecer la conexión problemática o reproducir el error en la aplicación. Se añadirán nuevas líneas a medida que se procesen.

sudo systemctl restart nginx
sudo tail -f /var/log/nginx/error.log

Para salir del seguimiento, simplemente utilice Ctrl + CNo cierre bruscamente su sesión SSH si está conectado a un servidor remoto, especialmente si está en el proceso de solucionar un problema con un servicio importante.

También hay cola -Fcon una F mayúscula. Esta opción sigue al nombre del archivo y es más resistente a la rotación de registros. Esto es útil cuando el archivo se puede recrear mediante logrotate durante su diagnóstico.

sudo tail -F /var/log/nginx/error.log

Filtra mientras ves la transmisión en vivo sin perder la transmisión en directo.

Puedes rastrear un archivo y filtrarlo simultáneamente. Para buscar un error específico:

sudo tail -f /var/log/syslog | grep --line-buffered -i "failed"

la opción --línea-almacenada previene grep Mantiene las líneas en espera durante demasiado tiempo. Sin él, podrías pensar que no está pasando nada cuando en realidad el filtro está bloqueando la visualización.

Para diagnósticos sencillos, suelo preferir abrir dos terminales: una con el registro completo y otra con el filtro. Así evito pasar por alto alguna advertencia que no contenga la palabra exacta que busco.

¿Cuándo es preferible usar journalctl en lugar de tail?

En las distribuciones recientes con systemd, pasa mucha información a través de diarioctlSi busca registros de un servicio systemd, journalctl suele ser más limpio que tail en un archivo. /var/registro.

sudo journalctl -u ssh -n 50
sudo journalctl -u ssh -f

Con -tú, estás apuntando a una unidad systemd. Con -n 50Estás mostrando las últimas 50 líneas. Con -FPuedes seguir las noticias en directo, igual que con Tails.

Si va a reiniciar un servicio, puede combinar ambos enfoques:

sudo systemctl restart ssh
sudo systemctl status ssh --no-pager
sudo journalctl -u ssh -f

Suelo usar tail cuando sé exactamente qué archivo de aplicación monitorizar. Para un servicio systemd, un proceso de arranque o un error de inicio, suelo usar journalctl. Si quieres profundizar en esto, consulta el artículo sobre journalctl y los registros del último inicio Este pedido se ha completado a la perfección.

Errores comunes con la cola

El primer error es seguir el archivo incorrecto. Antes de quedarse atascado mirando un registro silencioso, revise el servicio y los archivos abiertos:

systemctl status nginx --no-pager
sudo journalctl -u nginx -n 50
sudo ls -lh /var/log/nginx/

Segundo error: olvidar los permisos. En un servidor, muchos registros requieren sudoSi tienes un mensaje Permiso denegadoNo modifique los permisos de archivo al azar. En su lugar, reinicie la operación de lectura usando sudo.

Tercer error: confundir la ausencia de registros con la ausencia de un problema. Una aplicación puede escribir en otro lugar, enviar sus registros a systemd o registrar solo ciertos niveles de error.

Para comprobar el estado del servidor de forma más general, también puede examinar los servicios que fallan utilizando systemd:

systemctl --failed
systemctl listar trabajos

Si el problema afecta a un puerto de red o a un servicio que ya no está escuchando, el artículo sobre netstat, ss y puertos abiertos en Linux También puede ayudarte a verificar lo que realmente se muestra en pantalla.

Un método sencillo para el diagnóstico sin desviarse del tema principal.

Cuando necesito comprobar un servicio que acaba de fallar, utilizo un método breve:

• Identifique el servicio o el archivo de registro en cuestión;
• mostrar las últimas líneas con cola -n 50 O journalctl -n 50 ;
• comenzar a rastrear con cola -f, cola -F O journalctl -f ;
• reproducir la acción problemática;
• Anote la hora exacta y el mensaje antes de cambiar la configuración.

Este último punto evita trastear a ciegas. Es mejor leer el registro en el momento adecuado que reiniciar el sistema tres veces sin entender qué ha ocurrido.

Para obtener documentación de referencia, puede consultar la página de GNU Coreutils en cola y la página de systemd en diarioctl.

sudo apt update && sudo apt upgrade