En un sistema Linux, lo importante casi nunca avisa con un cartel luminoso. Un disco empieza a llenarse poco a poco, un servicio entra en un bucle de reinicios tras una actualización, una aplicación se queda sin memoria en horas punta o un atacante prueba contraseñas durante semanas sin hacer ruido. Y, cuando por fin se nota, suele ser tarde: caída, lentitud, pérdida de datos o una noche entera de incidencias.
Por eso, en administración de sistemas hay una regla que no pasa de moda: quien entiende los logs, entiende el estado real del servidor. Los registros (logs) son el “parte médico” del sistema: dejan constancia de arranques, errores, avisos, autenticaciones, servicios, fallos de hardware y eventos de seguridad. No sustituyen a la monitorización de métricas, pero sí ofrecen algo que ninguna gráfica da por sí sola: contexto.
Este artículo explica, de forma genérica para cualquier distribución Linux, qué logs conviene vigilar para mantener la salud del sistema, cómo consultarlos sin complicarse y qué prácticas ayudan a no perderse en el ruido.
Qué son los logs y por qué importan más de lo que parece
Los logs son archivos (o registros centralizados) donde el sistema y las aplicaciones escriben eventos: mensajes informativos, advertencias y errores. Cada línea suele incluir:
- Fecha y hora del evento.
- Origen (kernel, servicio, demonio, aplicación).
- Mensaje (lo que pasó y, a veces, por qué).
Revisarlos con regularidad sirve para:
- Detectar problemas antes de que escalen (errores repetidos, timeouts, reintentos).
- Identificar incidentes de seguridad (intentos de login fallidos, escaladas de privilegios).
- Acelerar la resolución de incidencias (causa raíz y secuencia de eventos).
- Verificar cambios (reinicios, despliegues, actualizaciones, fallos tras modificar configuración).
En entornos con varios servicios, los logs son, literalmente, el hilo narrativo del servidor.
Dónde están los logs en Linux: /var/log y el “journal” de systemd
En la mayoría de distribuciones clásicas, los logs se guardan en /var/log. Allí aparecen archivos como:
syslogomessages(mensajes generales del sistema)auth.logosecure(autenticación y seguridad)kern.log(kernel)- directorios de aplicaciones (por ejemplo, web, base de datos, etc.)
En sistemas modernos basados en systemd, además, existe el journal, un registro central consultable con journalctl. No siempre reemplaza a los archivos de texto: depende de la configuración de rsyslog/syslog-ng y de cómo esté configurado journald. La idea práctica es sencilla: hoy conviene saber moverse en ambos mundos.
Los logs esenciales que conviene revisar (y qué buscar en cada uno)
1) Logs del sistema: la primera radiografía
Según distribución, suelen ser:
- Debian/Ubuntu:
/var/log/syslog - RHEL/CentOS/Fedora:
/var/log/messages
Qué suele aparecer aquí:
- Arranques y apagados.
- Servicios que cambian de estado.
- Errores generales de fondo (cron, redes, demonios).
Qué señales de alarma buscar:
- Mensajes repetidos cada pocos segundos (síntoma de bucle o fallo persistente).
- “Out of memory”, “killed process”, “segfault”.
- Timeouts de red, DNS, caídas de interfaz.
Comandos típicos:
tail -n 100 /var/log/syslog
tail -n 100 /var/log/messages
grep -i "error\|failed\|panic\|oom" /var/log/syslog | tail -n 50
Lenguaje del código: JavaScript (javascript)2) Logs de autenticación: el termómetro de seguridad
Habituales:
- Debian/Ubuntu:
/var/log/auth.log - RHEL/CentOS/Fedora:
/var/log/secure
Aquí se registran:
- Logins correctos e intentos fallidos.
- Accesos SSH.
- Uso de
sudoy eventos PAM.
Qué vigilar:
- Muchos “Failed password” desde la misma IP.
- Intentos con usuarios inexistentes.
- Elevaciones de privilegios inusuales.
Ejemplos:
tail -n 200 /var/log/auth.log
grep -i "failed password" /var/log/auth.log | tail -n 50
grep -i "sudo" /var/log/auth.log | tail -n 50
Lenguaje del código: JavaScript (javascript)3) Logs del kernel: hardware, drivers y fallos “serios”
Suelen estar en:
/var/log/kern.log(en algunas distros)- salida de
dmesg journalctl -k(kernel en systemd)
Qué aporta:
- Detección de hardware.
- Errores de disco, I/O, controladoras.
- Problemas de drivers, memoria, red.
Qué buscar:
- Errores de I/O del disco.
- Mensajes de filesystem (ext4, xfs, btrfs) indicando corrupción o fallos.
- Resets de dispositivos, enlaces de red que suben y bajan.
Ejemplos:
dmesg -T | tail -n 100
journalctl -k -p warning..alert --no-pager | tail -n 100
4) Logs de servicios: cuando algo “se cae” sin avisar
Con systemd, es habitual consultar por unidad:
systemctl status nginx
journalctl -u nginx --since "today"
journalctl -u ssh --since "1 hour ago"
Lenguaje del código: JavaScript (javascript)Qué buscar:
- “Start request repeated too quickly” (bucle de reinicios).
- Fallos de configuración tras cambios.
- Dependencias que no arrancan.
5) Logs de aplicaciones: donde se explica el “por qué”
Cada aplicación suele dejar su rastro. Ejemplos comunes:
- Servidor web:
- Nginx:
/var/log/nginx/access.logy/var/log/nginx/error.log - Apache:
/var/log/apache2/access.logy/var/log/apache2/error.log(puede variar)
- Nginx:
- Bases de datos: ubicación variable según motor y configuración.
- Apps propias (Node, Python, etc.): a menudo bajo
/var/log/tuapp/o dentro del propio directorio del servicio si no se ha estandarizado.
Qué buscar:
- Picos de errores 5xx.
- Errores de conexión a base de datos.
- Timeouts de upstream.
- Trazas repetidas (indican bug persistente o tráfico malicioso).
Cómo consultar logs sin volverse loco: comandos útiles y filtros
Los clásicos funcionan en casi cualquier Linux:
tail -npara ver lo último.tail -fpara seguir en tiempo real.lesspara navegar sin cargar todo el archivo.greppara filtrar por patrón.awk/sedsi se necesita afinar.
Ejemplos prácticos:
# Ver en tiempo real el log del sistema
tail -f /var/log/syslog
# Ver solo errores recientes en un log de aplicación
grep -i "error\|warn\|critical" /var/log/nginx/error.log | tail -n 200
# Buscar eventos en una franja temporal (journal)
journalctl --since "2026-01-03 08:00" --until "2026-01-03 10:00" -p warning..alert
Lenguaje del código: PHP (php)Una costumbre que ahorra horas: buscar por patrón y por repetición. Un error aislado puede ser anecdótico; un error cada 5 segundos es una incidencia en curso.
journalctl: la navaja suiza en sistemas con systemd
Para muchos administradores, journalctl se ha vuelto imprescindible por dos razones: centraliza eventos y permite filtrar con precisión.
Comandos que suelen “salvar el día”:
# Últimos errores del sistema
journalctl -p err..alert --no-pager | tail -n 200
# Logs del arranque actual
journalctl -b --no-pager | tail -n 200
# Logs del arranque anterior (si hubo reinicio)
journalctl -b -1 --no-pager | tail -n 200
# Logs de un servicio concreto
journalctl -u docker --since "today" --no-pager
Lenguaje del código: PHP (php)Si un servidor “se reinició solo” o un servicio se cae sin explicación, mirar journalctl -b -1 suele ser lo más rápido para reconstruir el relato.
Buenas prácticas para monitorizar logs sin ahogarse en ruido
1) Rotación y retención: que el disco no muera por los logs
Los logs crecen. Y cuando crecen sin control, el problema termina siendo el mismo: /var lleno y servicios que fallan por falta de espacio. logrotate suele encargarse de rotación en sistemas clásicos; journald también permite configurar límites de almacenamiento.
La idea práctica:
- Rotación diaria o semanal según volumen.
- Compresión de históricos.
- Retención razonable según necesidades de auditoría.
2) Estándar de severidades y alertas
No hace falta leerlo todo a mano. Lo inteligente es definir:
- Qué se considera crítico (kernel, auth, discos, caídas de servicio).
- Qué se revisa a diario.
- Qué se revisa cuando hay incidentes.
3) Centralizar cuando el entorno crece
En un servidor único, leer /var/log puede bastar. En varios servidores, lo habitual es centralizar: enviar logs a una plataforma (por ejemplo, syslog remoto o soluciones tipo “stack de logs”). Esto permite:
- Búsqueda unificada.
- Correlación entre máquinas.
- Retención y auditoría más sólida.
Sin entrar en marcas concretas, el concepto clave es no depender de entrar por SSH a cinco servidores cada día.
4) Separar “seguridad” de “operación”
Para salud del sistema, los logs de sistema/servicios son el núcleo. Para seguridad, los de autenticación y los de red (y, si aplica, el firewall) deberían tener tratamiento propio: revisión más frecuente y, si es posible, alertas.
El truco final: observar tendencias, no solo incidentes
La monitorización útil no es la que te dice “se ha roto”, sino la que te enseña “esto se está rompiendo”. Un servidor suele avisar antes:
- Más reintentos de conexión.
- Más timeouts.
- Errores de disco esporádicos.
- Aumentos de “permission denied” por cambios de permisos.
- Servicios que empiezan a reiniciarse tras despliegues.
Los logs, revisados con rutina, convierten esos síntomas en señales.
Preguntas frecuentes
¿Qué logs son imprescindibles para comprobar la salud de un servidor Linux en producción?
Los más útiles suelen ser los logs del sistema (syslog o messages), autenticación (auth.log o secure), kernel (dmesg/kern.log/journalctl -k), y los logs del servicio crítico (por ejemplo, web o base de datos) que sostenga el negocio.
¿Cómo ver errores recientes de un servicio en Linux con systemd?
Con journalctl -u nombre_del_servicio -p err..alert --since "today". Es una forma rápida de filtrar solo errores y alertas del servicio desde un momento concreto.
¿Dónde se guardan los intentos fallidos de SSH en Ubuntu y en CentOS/RHEL?
En Ubuntu/Debian suelen registrarse en /var/log/auth.log. En CentOS/RHEL/Fedora es habitual encontrarlos en /var/log/secure.
¿Qué es mejor: revisar logs manualmente o usar alertas y centralización?
En un servidor pequeño, una revisión manual diaria puede funcionar. En entornos con varios servidores o aplicaciones críticas, lo más fiable es combinar rotación y retención con alertas y centralización para no perder errores importantes entre ruido.
Si quieres, puedo convertir este contenido en una guía “checklist” para sysadmins (con comandos y patrones de búsqueda listos para copiar) orientada a Debian/Ubuntu y RHEL/CentOS por separado.
