Cómo leer los logs del servidor: 404, bots y lentitud
Qué muestra cada parte de una línea de log del servidor, cómo detectar errores 404 y peticiones lentas, y cómo distinguir visitantes reales de bots.
Equipo de rabbitclipPublicación: 6 min. de lectura
En breve
Una línea de log del servidor contiene la dirección de origen de la petición, la fecha, la página solicitada, el código de estado devuelto y la información del navegador, todo en una sola línea. Leerlas con regularidad responde a tres preguntas: qué páginas devuelven un error 404, qué parte del tráfico son visitantes reales frente a bots, y qué peticiones tardan más de lo normal en responder. Las tres son señales visibles mucho antes de convertirse en una queja real.
Cuando el sitio de una empresa de gestión de instalaciones recibe solo unos cientos de visitas al mes pero el servidor registra decenas de miles de peticiones al día, esa diferencia casi siempre viene del tráfico de bots. Sin mirar los logs, es difícil entender de dónde sale esa brecha.
¿Cómo se lee una línea de log?
Un log del servidor es el registro que el servidor guarda de cada petición recibida; el formato «combined» que usan por defecto Nginx y Apache lista la IP de origen, la fecha, la dirección solicitada, el método HTTP, el código de estado, la cantidad de bytes enviados, la página de referencia y el user-agent, en ese orden.
En una línea típica aparece primero la IP del visitante, luego la fecha y hora entre corchetes, después la dirección solicitada entre comillas empezando por GET o POST, seguida inmediatamente del código de estado de tres dígitos, 200 para éxito, 404 para no encontrado, 500 para error del servidor, la cantidad de datos enviados y finalmente el user-agent entre comillas al final. Aprender este orden una sola vez basta para leer cualquier archivo de log después.
¿Qué muestran realmente los errores 404?
Un 404 significa que la página solicitada no se encontró en el servidor. Eso viene de un enlace roto, de otra página que apunta a una dirección que ya no existe, de una migración en la que las direcciones antiguas nunca se redirigieron, o de un bot probando una dirección al azar.
Revisar los 404 en los logs con regularidad muestra qué enlace roto está afectando realmente a visitantes reales; un 404 que se repite a menudo y viene de un navegador genuino merece corregirse primero, un intento aislado de bot suele poder ignorarse.
¿Cómo distinguir visitantes reales de tráfico de bots?
El primer sitio donde mirar es el campo user-agent; los bots conocidos de buscadores se identifican abiertamente. Pero un bot malicioso suele presentar un user-agent que parece un navegador real, así que ese campo por sí solo no basta.
- Más de una petición por segundo desde la misma IP, algo que no encaja con el comportamiento humano
- Peticiones repetidas concentradas solo en ciertas páginas, un formulario de acceso, un buscador
- Peticiones que van directas a páginas profundas sin haber consultado antes robots.txt
- Un user-agent realista combinado con cabeceras ausentes que un navegador real suele enviar, idioma, cookies
Cómo encontrar peticiones lentas en los logs
El tiempo de respuesta no aparece en la mayoría de los formatos de log por defecto, pero tanto Nginx como Apache ofrecen una variable aparte para añadirlo; una vez incluida, cada petición muestra cuánto tardó en responder, en milisegundos.
Con ese campo en su sitio, filtrar las peticiones por encima de un umbral, por ejemplo un segundo, permite encontrar qué página, qué consulta o qué integración está causando la lentitud. Es una señal que se puede detectar antes de que un cliente se queje de que el sitio va lento.
¿Cuánto tiempo guardar los logs, y quién debe revisarlos?
Los archivos de log no se guardan para siempre; el espacio en disco es limitado y la mayoría de los hostings aplican una rotación por defecto de unas semanas a unos meses. Como una revisión de seguridad tras un incidente puede necesitar logs más antiguos, conviene fijar ese periodo de forma deliberada en vez de dejarlo en el valor por defecto del proveedor.
Revisar los logs con regularidad puede ser un hábito semanal de diez minutos para una sola persona; el objetivo no es leer cada línea, sino echar un vistazo a la distribución de códigos de estado y a los errores que más se repiten.
Obtener un resumen rápido con un solo comando
Se puede obtener un resumen rápido de un archivo de log sin necesidad de un equipo técnico. Un comando sencillo que cuenta y ordena las líneas por código de estado muestra en segundos cuántas veces se repite cada error; los 404 o 500 más frecuentes aparecen al principio de la lista.
La misma idea, ordenando por número total de peticiones por dirección IP, delata de inmediato una fuente de tráfico de bots inusualmente intensa. Ambos filtros dan un resultado mucho más rápido que leer el archivo entero línea por línea.
Errores frecuentes
Los logs suelen quedar como un archivo que solo se abre cuando algo ya ha fallado; sin una mirada regular, se pierde el aviso temprano.
- Revisar los logs solo después de que el sitio ya haya caído, perdiendo las señales de alerta previas
- No revisar nunca los errores 404, dejando enlaces rotos sin detectar durante meses
- Leer la analítica como si cada visita fuera humana, sin tener nunca en cuenta la parte de tráfico de bots
- No añadir nunca un campo de tiempo de respuesta a los logs, dejando sin conocer el origen de la lentitud
Los logs del servidor muestran un sitio de forma más honesta que cualquier panel de analítica; cada petición, real o de bot, queda registrada ahí. Un hábito semanal de diez minutos permite detectar muchos problemas antes de que se conviertan en una queja de un cliente. Una primera llamada con rabbitclip es un buen momento para leer juntos los logs de su propio servidor.
Preguntas frecuentes
¿Se necesita una herramienta especial para leer los archivos de log?
Para un sitio pequeño basta con filtrar un archivo de texto plano desde la línea de comandos. A medida que crece el tráfico, una herramienta de análisis de logs facilita el trabajo.
¿Un error 404 es siempre un problema?
No. Que un bot pruebe una dirección aleatoria que nunca existió es normal; el problema real es un enlace roto que visitantes reales encuentran a menudo.
¿Se puede bloquear por completo el tráfico de bots?
No por completo, pero los patrones de comportamiento malicioso conocidos pueden bloquearse en gran medida a nivel de servidor o de CDN.
¿La lentitud de una petición siempre viene del servidor?
No. Puede venir de una consulta a la base de datos, de una integración externa o de una imagen pesada; el log solo muestra dónde se ralentiza, la causa hay que investigarla aparte.
¿Se puede obtener un resumen rápido en lugar de leer línea por línea?
Sí. Un comando sencillo que cuenta y ordena por código de estado o dirección IP muestra el error más frecuente o una fuente de bots inusual sin leer cada línea.
