Servidores y VPS

Análisis de logs en VPS: detecta problemas antes de que Crezcan

Aprende dónde están los logs de tu servidor VPS, qué información contiene cada uno y cómo analizarlos para detectar errores, intrusos y cuellos de botella antes de que afecten a tus usuarios.

Detailed view of a server rack with a focus on technology and data storage.

Los logs de un servidor VPS son su caja negra: registran cada petición web, cada intento de acceso SSH, cada error de base de datos y cada servicio que falla silenciosamente. Analizarlos de forma regular te permite detectar problemas antes de que se conviertan en caídas o brechas de seguridad.

Esta guía te muestra dónde viven los logs más importantes en un VPS Linux, qué información contiene cada uno y cómo leerlos con comandos concretos.

Dónde están los logs principales de tu VPS

En la mayoría de distribuciones Linux (Ubuntu, Debian, CentOS, AlmaLinux), los logs del sistema se almacenan en /var/log/. Estos son los más relevantes para un administrador web:

Archivo de log Qué registra Cuándo revisarlo
/var/log/auth.log (Debian/Ubuntu)
/var/log/secure (CentOS/RHEL)
Autenticaciones SSH, sudo, intentos fallidos A diario; obligatorio ante sospechas de intrusión
/var/log/syslog / /var/log/messages Actividad general del sistema, kernel, servicios Cuando un servicio cae o el sistema se comporta raro
/var/log/apache2/access.log
/var/log/nginx/access.log
Cada petición HTTP al servidor web Para análisis de tráfico, rastreo de errores 4xx/5xx
/var/log/apache2/error.log
/var/log/nginx/error.log
Errores del servidor web (PHP, permisos, timeouts) Ante cualquier error 500 o página en blanco
/var/log/mysql/error.log Errores de MySQL/MariaDB, arranque, consultas lentas Cuando la base de datos es lenta o no arranca
/var/log/fail2ban.log IPs bloqueadas por Fail2ban Para revisar ataques de fuerza bruta activos

Comandos esenciales para leer logs

No necesitas herramientas complejas para empezar. Con estos comandos básicos cubres el 80% de los casos.

Ver las últimas líneas en tiempo real

# Últimas 50 líneas del log de errores de Apache
tail -n 50 /var/log/apache2/error.log

# Seguimiento en tiempo real (Ctrl+C para salir)
tail -f /var/log/apache2/access.log

Buscar patrones específicos con grep

# Todos los errores 500 de hoy en el log de acceso de Nginx
grep " 500 " /var/log/nginx/access.log | grep "$(date +%d/%b/%Y)"

# Intentos de login SSH fallidos
grep "Failed password" /var/log/auth.log | tail -30

# IPs que más intentos fallidos acumulan
grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -10

Analizar logs comprimidos (rotados)

# Los logs rotan y se comprimen; usa zgrep para buscar en .gz
zgrep "500" /var/log/nginx/access.log.1.gz

Qué buscar en cada tipo de log

Logs de acceso web (access.log)

Cada línea tiene el formato: IP - - [fecha] "MÉTODO /ruta HTTP/versión" código bytes.

Patrones de alerta que debes buscar:

  • Muchos errores 404 seguidos desde la misma IP: posible escaneo de vulnerabilidades.
  • Errores 403 en archivos sensibles (.env, wp-config.php, /etc/passwd): intento de explotación.
  • Picos de tráfico repentinos: DDoS, ataque de bots o un contenido que se volvió viral.
  • Peticiones con payloads sospechosos en la URL (../, UNION SELECT, <script>): intentos de LFI, SQLi o XSS.
# Top 10 IPs por número de peticiones
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10

# Todas las rutas que devolvieron 403
grep " 403 " /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

Logs de error web (error.log)

Aquí aparecen los problemas reales: errores de PHP, permisos denegados, timeouts de FastCGI, módulos que fallan.

# Errores PHP en el log de Apache
grep "PHP" /var/log/apache2/error.log | tail -20

# Timeouts de PHP-FPM
grep "upstream timed out" /var/log/nginx/error.log | tail -20

Log de autenticación (auth.log)

Es el primero que debes revisar ante cualquier sospecha de acceso no autorizado.

# Logins SSH exitosos (quién entró y desde dónde)
grep "Accepted" /var/log/auth.log | tail -20

# Sesiones abiertas con sudo
grep "sudo" /var/log/auth.log | grep "COMMAND" | tail -20

Si ves logins exitosos desde IPs que no reconoces, tu servidor ha sido comprometido. Consulta los recursos disponibles en nuestra guía de seguridad para VPS para actuar de inmediato.

Herramientas para análisis más avanzado

Cuando los logs crecen y leerlos manualmente se vuelve inmanejable, estas herramientas gratuitas ayudan.

  • GoAccess: analizador visual de logs web en tiempo real, directamente en el terminal o en HTML. apt install goaccess
  • Logwatch: genera resúmenes diarios de actividad del sistema y los envía por correo. apt install logwatch
  • Fail2ban: no solo bloquea IPs, también genera logs útiles sobre ataques activos.
  • Journalctl: para distribuciones con systemd, centraliza todos los logs de servicios.
# Ver logs de un servicio específico con journalctl
journalctl -u nginx --since "1 hour ago"

# Resumen visual de logs de acceso con GoAccess
goaccess /var/log/nginx/access.log --log-format=COMBINED

Para proyectos que necesitan retención larga y análisis histórico, herramientas como Elasticsearch + Kibana (stack ELK) o Grafana Loki permiten buscar meses de logs en segundos. Son más complejas de configurar, pero indispensables en entornos de producción serios.

Buenas prácticas de gestión de logs

Analizar logs solo cuando hay un problema ya es tarde. Estas prácticas convierten los logs en un activo preventivo:

  • Configura la rotación de logs. logrotate ya viene preconfigurado en la mayoría de distribuciones; asegúrate de que los logs no ocupen todo tu disco.
  • Centraliza los logs si tienes varios servidores. Envíalos a un servidor de logs dedicado o a un servicio en la nube para no perder visibilidad.
  • Activa alertas automáticas. Configura Logwatch para enviarte un resumen diario, o usa herramientas de monitoreo que te notifiquen cuando detecten anomalías.
  • Conserva logs al menos 30 días. Muchos incidentes de seguridad no se detectan hasta días después del ataque. Si tus logs rotan cada 7 días, pierdes evidencia clave.
  • Protege los logs de escritura. Un atacante con acceso al servidor lo primero que hace es borrar o modificar los logs para cubrir su rastro.

Si prefieres delegar la gestión y análisis de logs de tu VPS a expertos, el equipo de elenlace.com ofrece servicios de administración de servidores que incluyen monitoreo continuo y alertas en tiempo real.

Conclusiones clave

  • Los logs más importantes para un VPS web están en /var/log/: auth.log, syslog, access.log y error.log.
  • tail -f y grep son tus herramientas de diagnóstico inmediato; GoAccess y Logwatch dan análisis más completos.
  • En auth.log busca logins exitosos desde IPs desconocidas; en access.log, picos de errores 4xx/5xx y patrones de escaneo.
  • Configura rotación automática para que los logs no llenen el disco, y guarda al menos 30 días de historia.
  • Los logs son evidencia forense: protégelos de escritura y centralízalos si puedes.

Revisar tus logs regularmente es la diferencia entre detectar un problema en minutos y descubrirlo cuando tus usuarios ya se quejaron. Si quieres un sistema de monitoreo profesional sin gestionar la infraestructura tú mismo, contáctanos en elenlace.com.

Preguntas frecuentes

¿Con qué frecuencia debo revisar los logs de mi VPS?

Como mínimo, configura Logwatch para recibir un resumen diario por correo. Ante cualquier incidencia (caída, lentitud, comportamiento raro), revisa los logs en tiempo real con tail -f antes de hacer cualquier otro cambio.

¿Qué hago si los logs están llenos y el disco está al 100%?

Primero libera espacio borrando logs muy antiguos (find /var/log -name "*.gz" -mtime +60 -delete). Luego ajusta la configuración de logrotate para rotar con más frecuencia o comprimir antes. Revisa también si algún servicio está generando logs de error en bucle.

¿Puedo ver los logs de PHP desde el log de Nginx?

Nginx delega la ejecución de PHP a PHP-FPM. Los errores de PHP se registran según la configuración de php.ini (error_log) o en el error.log de Nginx si PHP-FPM está configurado para redirigirlos ahí. Revisa ambos lugares.

¿Los logs de mi VPS incluyen los logs de mi sitio WordPress?

WordPress puede tener su propio log de debug (wp-content/debug.log) si está activado en wp-config.php. Los errores PHP de WordPress también aparecen en el error.log del servidor web. Para activar el log de WordPress agrega: define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); en wp-config.php.

Recursos útiles

Otros proveedores y guías que vale la pena comparar:

← Todos