Registro y diagnóstico en Apache: access log, error log y trazabilidad

¿Qué registran los logs de Apache y por qué son clave para diagnosticar?

Apache genera principalmente dos tipos de registros: access log (tráfico y solicitudes atendidas) y error log (problemas del servidor, del Virtual Host o de módulos). Aprender a leerlos te permite responder preguntas típicas de soporte: “¿por qué devuelve 404?”, “¿por qué da 403 si el archivo existe?”, “¿es un fallo de la app o del servidor?”, “¿cuándo empezó el error y a quién afecta?”.

En diagnóstico, la idea es combinar: qué pidió el cliente (access log), qué falló internamente (error log) y cuándo y desde dónde (fecha/IP), para reconstruir una línea temporal del incidente.

Access log: formatos comunes y cómo interpretarlos

Formato “combined” (el más habitual)

Muchos sistemas registran en formato combined, que incluye IP, fecha, petición, código de estado, tamaño, referer y user-agent. Un ejemplo típico:

203.0.113.10 - - [03/Feb/2026:10:15:22 +0000] "GET /img/logo.png HTTP/1.1" 200 5321 "https://example.com/" "Mozilla/5.0"

Cómo leerlo:

• 203.0.113.10: IP del cliente (útil para correlación y bloqueos).
• [03/Feb/2026:10:15:22 +0000]: fecha/hora (base para correlación con error log).
• "GET /img/logo.png HTTP/1.1": método y recurso solicitado.
• 200: código HTTP (éxito, redirección, error).
• 5321: bytes enviados.
• Referer: desde dónde llegó (si aplica).
• User-Agent: navegador/bot.

Códigos HTTP frecuentes y su significado práctico

Personalizar el formato para trazabilidad (request id, tiempos)

Para mejorar la trazabilidad, es común incluir tiempo de respuesta y un identificador de petición. En Apache 2.4 puedes usar %D (microsegundos) o %T (segundos). Para un ID, suele usarse un módulo (por ejemplo, mod_unique_id) o cabeceras de proxy. Un ejemplo de formato con tiempo:

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

LogFormat "%h %l %u %t \"%r\" %>s %b %D" timed_combined

Esto ayuda a detectar endpoints lentos y correlacionar picos de latencia con errores.

Error log: niveles, mensajes frecuentes y códigos AHxxxx

Niveles de log (LogLevel)

El error log incluye severidad. Los niveles más usados:

• emerg, alert, crit: problemas graves (Apache puede no iniciar o quedar inestable).
• error: fallos que afectan solicitudes.
• warn: advertencias (configuración subóptima, condiciones anómalas).
• notice: eventos relevantes (arranque, recarga, cambios).
• info, debug, trace1-8: diagnóstico detallado (útil temporalmente).

Recomendación práctica: en producción, mantener warn o error y elevar a info/debug solo durante una ventana de diagnóstico, para evitar ruido y consumo de disco.

Mensajes típicos y cómo actuar

Ejemplos frecuentes:

• Archivo inexistente (relacionado con 404):

[core:error] [pid 1234] [client 203.0.113.10:54321] AH00128: File does not exist: /var/www/site/robots.txt

• Permisos/denegación (relacionado con 403):

[authz_core:error] [pid 1234] [client 203.0.113.10:54321] AH01630: client denied by server configuration: /var/www/site/private/

• Problema de configuración (puede causar 500 o impedir arranque):

[core:alert] AH00016: Configuration Failed

• Errores de proxy/backend (a menudo 502/503 vistos por el cliente, pero se explican en error log):

[proxy:error] [pid 1234] (111)Connection refused: AH00957: HTTP: attempt to connect to 127.0.0.1:8080 (localhost) failed

Los códigos AHxxxx son identificadores de mensajes de Apache. Son muy útiles para buscar el significado exacto del error y encontrar documentación o casos similares. En diagnóstico, anota el AHxxxx, el módulo (por ejemplo authz_core, proxy, core) y la ruta afectada.

Configurar rutas de logs por Virtual Host (separación por sitio)

Para diagnosticar varios sitios en el mismo servidor, es esencial separar logs por Virtual Host. La idea es que cada sitio escriba en sus propios archivos de acceso y error, evitando mezclar tráfico.

Ejemplo de configuración por sitio

Dentro del bloque del Virtual Host (HTTP o HTTPS), define:

ErrorLog  /var/log/apache2/site1_error.log
CustomLog /var/log/apache2/site1_access.log combined

Buenas prácticas:

• Usa nombres consistentes: sitio_access.log y sitio_error.log.
• Si tienes un balanceador/proxy delante, considera registrar cabeceras como X-Forwarded-For (según tu arquitectura) para no perder la IP real.
• Si necesitas más detalle temporalmente, puedes ajustar LogLevel por Virtual Host (por ejemplo, subir a info solo en un sitio afectado).

Rotación de logs y control de crecimiento

Los logs crecen rápido. La rotación evita que un archivo enorme sea difícil de manejar y reduce el riesgo de llenar el disco.

Rotación con logrotate (enfoque común)

En muchos Linux, logrotate gestiona la rotación de /var/log/apache2/*.log o /var/log/httpd/*.log. Conceptos clave:

• Frecuencia: diaria/semanal.
• Retención: cuántos archivos antiguos conservar.
• Compresión: .gz para ahorrar espacio.
• Recarga: tras rotar, Apache debe reabrir archivos (normalmente con recarga del servicio).

Verificación práctica: tras una rotación, confirma que Apache sigue escribiendo en el archivo nuevo y que no se quedó apuntando al descriptor antiguo.

Rotación con piped logs (opcional)

Apache permite enviar logs a un programa (por ejemplo, rotación por fecha). Es útil en escenarios donde quieres rotación más granular o integración con herramientas externas, pero añade complejidad operativa.

Permisos de lectura seguros (sin exponer datos sensibles)

Los logs pueden contener URLs con parámetros, rutas internas, IPs y user-agents. Por seguridad:

• Los archivos de log deben ser legibles solo por administradores y por el usuario/grupo del servicio cuando aplique.
• Evita permisos “world-readable”.
• Si necesitas que un equipo de soporte lea logs, usa grupos específicos y permisos mínimos.

Comprobación rápida de permisos

ls -l /var/log/apache2/

Busca que los logs pertenezcan a root y a un grupo controlado (por ejemplo adm), y que los permisos no permitan lectura global. Ajusta según tu distribución y política interna.

Técnicas de diagnóstico en terminal: tail, grep y correlación

Seguir eventos en tiempo real con tail -f

Cuando reproduces un problema, lo más eficaz es observar el log mientras ocurre:

tail -f /var/log/apache2/site1_access.log

tail -f /var/log/apache2/site1_error.log

Consejo: abre dos terminales (access y error) y reproduce la petición desde el navegador o con curl. Verás la entrada en access log y, si hay fallo, el detalle en error log.

Filtrado con grep (por código, ruta, IP)

Ejemplos útiles:

• Encontrar todos los 404:

grep '" 404 ' /var/log/apache2/site1_access.log

• Buscar una ruta concreta:

grep 'GET /admin' /var/log/apache2/site1_access.log

• Filtrar por IP:

grep '^203\.0\.113\.10 ' /var/log/apache2/site1_access.log

• Buscar un AHxxxx en el error log:

grep 'AH01630' /var/log/apache2/site1_error.log

Correlación por fecha/hora e IP (trazabilidad básica)

Flujo recomendado para correlacionar:

• 1) Identifica en access log la petición problemática (ruta + código + hora + IP).
• 2) Con esa hora/IP, busca en error log entradas cercanas.
• 3) Si hay múltiples eventos, acota por minuto/segundo y por IP.

Ejemplo: si ves en access log un 403 a las 10:20:31 desde 203.0.113.10, busca en error log alrededor de ese instante y con esa IP para encontrar la causa (denegación por configuración, permisos, etc.).

Diferenciar errores de aplicación vs errores del servidor

Señales de “problema del servidor Apache/configuración”

• Errores en error log con módulos de Apache: core, authz_core, ssl, proxy.
• Códigos AHxxxx indicando denegaciones, archivos inexistentes, fallos de configuración.
• Patrones repetidos para muchas rutas o muchos clientes (impacto amplio).

Señales de “problema de aplicación”

• Access log muestra 500 en endpoints concretos, mientras otros funcionan.
• Error log menciona intérpretes/handlers (por ejemplo, CGI/FastCGI/PHP-FPM vía proxy) o timeouts hacia un backend.
• El error depende de parámetros o de un flujo específico.

Regla práctica: Apache suele registrar el síntoma (500/502/503) y a veces la causa (timeout, conexión rechazada). La aplicación suele tener su propio log (por ejemplo, del runtime o framework) con el stacktrace. Tu objetivo es usar Apache para acotar “dónde” y “cuándo” y luego saltar al log de la app si corresponde.

Pruebas controladas: provocar 404 y 403 para reconocer patrones

Estas pruebas te entrenan para identificar rápidamente qué verás en access/error log y cómo correlacionarlo.

Preparación

• 1) Abre dos terminales y ejecuta:

tail -f /var/log/apache2/site1_access.log

tail -f /var/log/apache2/site1_error.log

• 2) En una tercera terminal, usa curl para generar solicitudes controladas.

Prueba A: provocar un 404 (recurso inexistente)

Paso a paso:

• 1) Solicita una ruta que no exista:

curl -i http://tu-dominio-o-ip/esto-no-existe-404

• 2) Observa en access log una línea con 404 y la ruta solicitada.
• 3) Observa en error log si aparece algo como “File does not exist” (depende de la configuración y del mapeo de rutas).

Qué aprender: un 404 suele ser “ruta no encontrada”. Si la app maneja rutas dinámicas, puede que el 404 venga de la app y no de Apache; en ese caso, el error log puede estar vacío y el access log será tu principal pista.

Prueba B: provocar un 403 (denegación)

Hay varias formas; el objetivo es generar un acceso denegado sin romper el servidor.

Opción 1 (recomendable si tienes un directorio “privado” con reglas de acceso):

• 1) Solicita una ruta que sepas que está restringida por configuración:

curl -i http://tu-dominio-o-ip/private/

• 2) En access log verás 403.
• 3) En error log busca mensajes del tipo client denied by server configuration (a menudo con AH01630).

Opción 2 (si controlas un entorno de práctica): provocar un 403 por permisos del sistema de archivos (hazlo solo en un directorio de laboratorio):

• 1) Quita permisos de lectura/ejecución al directorio objetivo (según tu caso) y solicita el recurso.
• 2) Revisa el error log para mensajes relacionados con permisos (por ejemplo, “Permission denied”).

Qué aprender: un 403 casi siempre requiere mirar el error log para saber si fue por configuración de acceso o por permisos del sistema de archivos.

Patrones a memorizar (resumen operativo)

• 404 en access log + “File does not exist” en error log: recurso estático inexistente o ruta mal construida.
• 403 en access log + “client denied by server configuration” (AH01630): regla de acceso/denegación.
• 500 en access log + errores de handler/proxy/timeout en error log: probable fallo de aplicación o backend.