Archivos de Registro (Log Files)

Idiomas disponibles: en | + es | + ja | + ko | + tr

Esta traducción podría estar + obsoleta. Consulte la versión en inglés de la + documentación para comprobar si se han producido cambios + recientemente.

+ +

Para administrar de manera efectiva un servidor web, es + necesario tener registros de la actividad y el rendimiento del + servidor así como de cualquier problema que haya podido + ocurrir durante su operación. El servidor HTTP Apache ofrece + capacidades muy amplias de registro de este tipo de + información. Este documento explica cómo configurar esas + capacidades de registro, y cómo comprender qué + información contienen los ficheros de registro.

Advertencia de seguridad
Registro de Errores (Error Log)
Registro de Acceso (Access Log)
Rotación de los ficheros de registro
Ficheros de registro redireccionados (Piped Logs)
Hosts Virtuales
Otros ficheros de registro

Advertencia de seguridad

+ + +

Cualquiera que tenga permisos de escritura sobre el directorio + en el que Apache esté escribiendo un archivo de registro + puede con casi toda seguridad tener acceso al identificador de + usuario con el que se inició el servidor, normalmente + root. NO le de a nadie permisos de escritura sobre el + directorio en que se almacenan los ficheros de registro sin tener + en cuenta las consecuencias; consulte los consejos de seguridad para + obtener más información.

+ +

Además, los ficheros de registro pueden contener + información suministrada directamente por el cliente, sin + sustituir. Es posible por tanto que clientes con malas intenciones + inserten caracteres de control en los ficheros de registro. Por + ello es necesario tener cuidado cuando se procesan los ficheros de + registro originales.

Registro de Errores (Error Log)

Módulos Relacionados	Directivas Relacionadas
	`ErrorLog` `LogLevel`

+ + + + +

El registro de errores del servidor, cuyo nombre y + ubicación se especifica en la directiva ErrorLog, es el más importante de + todos los registros. Apache enviará cualquier + información de diagnóstico y registrará cualquier + error que encuentre al procesar peticiones al archivo de registro + seleccionado. Es el primer lugar donde tiene que mirar cuando + surja un problema al iniciar el servidor o durante su + operación normal, porque con frecuencia encontrará en + él información detallada de qué ha ido mal y + cómo solucionar el problema.

+ +

El registro de errores se escribe normalmente en un fichero + (cuyo nombre suele ser error_log en sistemas Unix y + error.log en Windows y OS/2). En sistemas Unix + también es posible hacer que el servidor envíe los + mensajes de error al syslog o pasarlos a un programa.

+ +

El formato del registro de errores es relativamente libre y + descriptivo. No obstante, hay cierta información que se + incluye en casi todas las entradas de un registro de errores. Por + ejemplo, este es un mensaje típico.

+ +

+ [Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1] + client denied by server configuration: + /export/home/live/ap/htdocs/test +

+ +

El primer elemento de la entrada es la fecha y la hora del + mensaje. El segundo elemento indica la gravedad del error que se + ha producido. La directiva LogLevel se usa para controlar los tipos + de errores que se envían al registro de errores según su + gravedad. La tercera parte contiene la dirección IP del + cliente que generó el error. Después de la dirección + IP está el mensaje de error propiamente dicho, que en este + caso indica que el servidor ha sido configurado para denegar el + acceso a ese cliente. El servidor reporta también la ruta en + el sistema de ficheros (en vez de la ruta en el servidor + web) del documento solicitado.

+ +

En el registro de errores puede aparecer una amplia variedad de + mensajes diferentes. La mayoría tienen un aspecto similar al + del ejemplo de arriba. El registro de errores también + contiene mensaje de depuración de scripts CGI. Cualquier + información escrita en el stderr por un script + CGI se copiará directamente en el registro de errores.

+ +

El registro de errores no se puede personalizar añadiendo + o quitando información. Sin embargo, las entradas del + registro de errores que se refieren a determinadas peticiones + tienen sus correspondientes entradas en el registro de acceso. El ejemplo de arriba se + corresponde con una entrada en el registro de acceso que + tendrá un código de estado 403. Como es posible + personalizar el registro de acceso, puede obtener más + información sobre los errores que se producen usando ese + registro también.

+ +

Si hace pruebas, suele ser de utilidad monitorizar de forma + continua el registro de errores para comprobar si ocurre + algún problema. En sistemas Unix, puede hacer esto + usando:

+ +

+ tail -f error_log +

Registro de Acceso (Access Log)

Módulos Relacionados	Directivas Relacionadas
`mod_log_config` `mod_setenvif`	`CustomLog` `LogFormat` `SetEnvIf`

+ + + + +

El servidor almacena en el registro de acceso información + sobre todas las peticiones que procesa. La ubicación del + fichero de registro y el contenido que se registra se pueden + modificar con la directiva CustomLog. Puede usar la + directiva LogFormat + para simplificar la selección de los contenidos que quiere + que se incluyan en los registros. Esta sección explica como + configurar el servidor para que registre la información que + usted considere oportuno en el registro de acceso.

+ +

Por supuesto, almacenar información en el registro de + acceso es solamente el principio en la gestión de los + registros. El siguiente paso es analizar la información que + contienen para producir estadísticas que le resulten de + utilidad. Explicar el análisis de los registros en general + está fuera de los propósitos de este documento, y no es + propiamente una parte del trabajo del servidor web. Para más + información sobre este tema, y para aplicaciones que analizan + los registros, puede visitar + + Open Directory o + Yahoo.

+ +

Diferentes versiones de Apache httpd han usado otros + módulos y directivas para controlar la información que + se almacena en el registro de acceso, incluyendo mod_log_referer, + mod_log_agent, y la directiva TransferLog. Ahora la + directiva CustomLog + asume toda la funcionalidad que antes estaba repartida.

+ +

El formato del registro de acceso es altamente configurable. El + formato se especifica usando una cadena de caracteres de formato + similar a las de printf(1) en lenguaje C. Hay algunos ejemplos en + las siguientes secciones. Si quiere una lista completa de los + posibles contenidos que se pueden incluir, consulte la + documentació sobre las cadenas de caracteres + de formato del mod_log_config.

+ +

Formato Común de Registro (Common Log + Format)

+ + +

Una configuración típica del registro de acceso + podría tener un aspecto similar a este.

+ +

+ LogFormat "%h %l %u %t \"%r\" %>s %b" common + CustomLog logs/access_log common +

+ +

Con esto se define el apodo (nickname) common y se + le lo asocia con un determinado formato. El formato consiste en + una serie de directivas con tantos por ciento, cada una de las + cuales le dice al servidor que registre una determinada + información en particular. El formato también puede + incluir caracteres literales, que se copiarán directamente + en el registro. Si usa el caracter comillas (") + debe anteponerle una barra invertida para evitar que sea + interpretado como el final la cadena de caracteres a + registrar. El formato que especifique también puede + contener los caracteres de control especiales "\n" + para salto de línea y "\t" para tabulador.

+ +

La directiva CustomLog crea un nuevo + fichero de registro usando el apodo definido. El + nombre del fichero de registro de acceso se asume que es + relativo al valor especificado en ServerRoot a no ser que empiece + por una barra (/).

+ +

La configuración de arriba escribirá las entradas + en el registro con el formato conocido como Formato Común + de Registro (CLF). Este formato estándar lo pueden generar + muchos servidores web diferentes y lo pueden leer muchos de los + progrmas que analizan registros. Las entradas de un fichero de + registro que respetan ese formato común tienen una + aparariencia parecida es esta:

+ +

+ 127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET + /apache_pb.gif HTTP/1.0" 200 2326 +

+ +

Cada una de las partes de la entrada se explican a + continuaci#243;n.

+ +

127.0.0.1 (%h): Es la dirección IP del cliente (host remoto) que hizo + la petición al servidor. Si la directiva HostnameLookups tiene valor + On, el servidor intentará determinar el + nombre del host y registrar ese nombre en lugar de la + dirección IP. Sin embargo, no se recomienda que use esta + configuración porque puede ralentizar significativamente + las operaciones del servidor. En su lugar, es mejor usar un + programa que realice esta tarea posteriormente sobre el + registro, por ejemplo logresolve. Las + direcciones IP que se registren no son necesariamente las + direcciones de las máquinas de los usuarios finales. Si + existe un servidor proxy entre el usuario final y el servidor, + la dirección que se registra es la del proxy.
- (%l): Un "guión" siginifica que la información que + debería ir en ese lugar no está disponible. En este + caso, esa información es la identidad RFC 1413 del + cliente determinada por identd en la máquina + del cliente. Esta información es muy poco fiable y no + debería ser usada nunca excepto con clientes que + estén sometidos a controles muy estrictos en redes + internas. Apache httpd ni siquiera intenta recoger esa + información a menos que la directiva IdentityCheck tenga valor + On.
frank (%u): Este es el identificador de usuario de la persona que + solicita el documento determinado por la autentificación + HTTP. Normalmente ese mismo valor se pasa a los scripts CGI + con la variable de entorno REMOTE_USER. Si el + código de estado de la petición (ver abajo) es 401, + entonces no debe confiar en la veracidad de ese dato porque el + usuario no ha sido aún autentificado. Si el documento no + está protegido por contraseña, se mostrará un + guión "-" en esta entrada.
[10/Oct/2000:13:55:36 -0700] + (%t): + La hora a la que el servidor recibió la + petición. El formato es: + +
+ [día/mes/año:hora:minuto:segundo zona_horaria] + day = 2*digit + month = 3*letter + year = 4*digit + hour = 2*digit + minute = 2*digit + second = 2*digit + zone = (`+' | `-') 4*digit +
+ Es posible mostrar la hora de otra manera especificando + %{format} en el formato a usar en el registro, + donde format se sustituye como se haría al + usar strftime(3) de la librería + estándar de C. +
"GET /apache_pb.gif HTTP/1.0" + (\"%r\"): La línea de la petición del cliente se muestra + entre dobles comillas. La línea de petición contiene + mucha información de utilidad. Primero, el método + usado por el cliente es GET. Segundo, el cliente + ha hecho una petición al recurso + /apache_pb.gif, y tercero, el cliente uso el + protocolo HTTP/1.0. También es posible + registrar una o más partes de la línea de + petición independientemente. Por ejemplo, el formato + "%m %U%q %H" registrará el método, ruta, + cadena de consulta y protocolo, teniendo exactamente el mismo + resultado que "%r".
200 (%>s): Es el código de estado que el servidor envía de + vuelta al cliente. Esta información es muy valiosa, + porque revela si la petición fue respondida con + éxito por el servidor (los códigos que empiezan por + 2), una redirección (los códigos que empiezan por + 3), un error provocado por el cliente (los códigos que + empiezan por 4), o un error en el servidor (los códigos + que empiezan por 5). La lista completa de códigos de + estado posibles puede consultarle en la + especificación de HTTP (RFC2616 sección + 10).
2326 (%b): La última entrada indica el tamaño del objeto + retornado por el cliente, no incluídas las cabeceras de + respuesta. Si no se respondió con ningún contenido + al cliente, este valor mostrará valor + "-". Para registrar "0" en ese caso, + use %B en su lugar.

+ + +

Formato de Registro Combinado (Combined Log Format)

+ + +

Otro formato usado a menudo es el llamado Formato de Registro + Combinado. Este formato puede ser usado como sigue.

+ +

+ LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" + \"%{User-agent}i\"" combined + CustomLog log/access_log combined +

+ +

Es exactamente igual que Formato Común de Registro, pero + añade dos campos. Cada campo adicional usa la directiva + %{header}i, donde header puede + ser cualquier cabecera de petición HTTP. El registro de + acceso cuando se usa este formato tendrá este aspecto:

+ +

+ 127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET + /apache_pb.gif HTTP/1.0" 200 2326 + "http://www.example.com/start.html" "Mozilla/4.08 [en] + (Win98; I ;Nav)" +

+ +

Los campos adicionales son:

+ +

"http://www.example.com/start.html" + (\"%{Referer}i\"): La cabecera de petición de HTTP "Referer" + (sic). Muestra el servidor del que proviene el cliente. (Esta + debería ser la página que contiene un enlace o + que contiene a /apache_pb.gif).
"Mozilla/4.08 [en] (Win98; I ;Nav)" + (\"%{User-agent}i\"): La cabecera de petición HTTP "User-Agent". Es la + información de identificación que el navegador del + cliente incluye sobre sí mismo.

+ + +

Cómo usar varios registros de acceso

+ + +

Para crear varios registros de acceso solamente tiene que + especificar varias directivas CustomLog en el fichero de + configuración. Por ejemplo, las siguientes directivas + crearán tres registros de acceso. El primero contendrá + la información básica en Formato Común de + Registro, mientras que el segundo y el tercero contendrán + contendrán la información de los "referer" y de los + navegadores usados. Las dos últimas líneas CustomLog muestran cómo + reproducir el comportamiento de las directivas + ReferLog y AgentLog.

+ +

+ LogFormat "%h %l %u %t \"%r\" %>s %b" common + CustomLog logs/access_log common + CustomLog logs/referer_log "%{Referer}i -> %U" + CustomLog logs/agent_log "%{User-agent}i" +

+ +

Este ejemplo también muestra que no es necesario definir un + "apodo" con la directiva LogFormat. En lugar de esto, + el formato de registro puede especificarse directamente en la + directiva CustomLog.

+ + +

Registro Condicional

+ + +

Algunas veces es más conveniente excluir determinadas + entradas del registro de acceso en función de las + características de la petición del cliente. Puede + hacer esto fácilmente con la ayuda de variables de entorno. Primero, debe + especificar una variable de entorno que indique que la + petición cumple determinadas condiciones. Esto se hace + normalmente con SetEnvIf. Entonces puede usar + la claúsula env= de la directiva CustomLog para incluir o + excluir peticiones en las que esté presente la variable de + entorno. Algunos ejemplos:

+ +

+ # Marcar las peticiones de la interfaz loop-back + SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog + # Marcar las peticiones del fichero robots.txt + SetEnvIf Request_URI "^/robots\.txt$" dontlog + # Registrar lo que quede + CustomLog logs/access_log common env=!dontlog +

+ +

Como otro ejemplo, considere registrar las peticiones de los + angloparlantes en un fichero de registro, y el resto de + peticiones en un fichero de registro diferente.

+ +

+ SetEnvIf Accept-Language "en" english + CustomLog logs/english_log common env=english + CustomLog logs/non_english_log common env=!english +

+ +

Aunque acabamos de mostar que el registro condicional es muy + potente y flexible, no es la única manera de controlar los + contenidos de los ficheros de registro. Los ficheros de registro + son más útiles cuanta más información sobre + la actividad del servidor contengan. A menudo es más + fácil eliminar las peticiones que no le interesen + procesando posteriormente los ficheros de registro + originales.

+ +

Rotación de los ficheros de registro

+ + +

Incluso en un servidor con una actividad moderada, la cantidad + de información almacenada en los ficheros de registro es muy + grande. El registro de acceso crece normalmente en 1MB por cada + 10.000 peticiones. Por lo tanto, es necesario rotar + periódicamente los registros moviendo o borrando su + contenido. Esto no se puede hacer con el servidor funcionando, + porque Apache continuará escribiendo en el antiguo registro + mientras que el archivo esté abierto. En lugar de esto, el + servidor debe ser reiniciado + después de mover o borrar los ficheros de registro para que + se abran nuevos ficheros de registro.

+ +

Usando un reinicio graceful, se le puede indicar al + servidor que abra nuevos ficheros de registro sin perder ninguna + petición siendo servida o en espera de algún cliente. Sin + embargo, para hacer esto, el servidor debe continuar escribiendo + en los ficheros de registro antiguos mientras termina de servir + esas peticiones. Por lo tanto, es preciso esperar algún + tiempo después del reinicio antes de realizar ninguna + operación sobre los antiguos ficheros de registro. Una + situación típica que simplemente rota los registros y + comprime los registros antiguos para ahorrar espacio es:

+ +

+ mv access_log access_log.old + mv error_log error_log.old + apachectl graceful + sleep 600 + gzip access_log.old error_log.old +

+ +

Otra manera de realizar la rotación de los registros es + usando ficheros de registro redireccionados + (piped logs) de la forma en que se explica en la siguiente + sección.

Ficheros de registro redireccionados (Piped Logs)

+ + +

Apache httpd es capaz de escribir la información del + registro de acceso y errores mediante una redirección a otro + proceso, en lugar de directamente a un fichero. Esta capacidad + incrementa de forma muy importante la flexibilidad de registro, + sin añadir código al servidor principal. Para escribir + registros a una redirección, simplemente reemplace el nombre + de fichero por el carácter "|", seguido por el + nombre del ejecutable que debería aceptar las entradas de + registro por su canal de entrada estándar. Apache + iniciará el proceso de registro redireccionado cuando se + inicie el servidor, y lo reiniciará si se produce algún + error irrecuperable durante su ejecución. (Esta última + funcionalidad es la que hace que se llame a esta técnica + "registro redireccionado fiable".)

+ +

Los procesos de registros son engendrados por el proceso padre + de Apache httpd, y heredan el identificador de usuario de ese + proceso. Esto significa que los programas a los que se + redireccionan los registros se ejecutan normalmente como root. Es + por ello que es muy importante que los programas sean simples y + seguros.

+ +

Un uso importante de los registros redireccionados es permitir + la rotación de los registros sin tener que reiniciar el + servidor. El servidor Apache HTTP incluye un programa simple + llamado rotatelogs con este propósito. Por + ejemplo para rotar los registros cada 24 horas, puede usar:

+ +

+ CustomLog "|/usr/local/apache/bin/rotatelogs + /var/log/access_log 86400" common +

+ +

Tenga en cuenta que las comillas se usan para abarcar el + comando entero que será invocado por la + redirección. Aunque estos ejemplos son para el registro de + acceso, la misma técnica se puede usar para el registro de + errores.

+ +

Otro programa para la rotación de los registros mucho + más flexible llamado cronolog está disponible + en un sitio web externo.

+ +

Como ocurre con el registro condicional, la redirección de + registros es una herramienta muy potente, pero no deben ser usados + si hay disponible una solución más simple de procesado + posterior de los registros fuera de línea.

Hosts Virtuales

+ + +

Cuando se está ejecutando un servidor con muchos hosts virtuales, hay varias formas de abordar + el asunto de los registros. Primero, es posible usar los registros + de la misma manera que se usarían si hubiera solamente un + host en el servidor. Simplemente poniendo las directivas que + tienen que ver con los registros fuera de las secciones <VirtualHost> en el + contexto del servidor principal, puede almacenar toda la + información de todas las peticiones en los mismos registros + de acceso y errores. Esta técnica no permite una + recolección fácil de las estadísticas individuales + de cada uno de los hosts virtuales.

+ +

Si una directiva CustomLog o ErrorLog se pone dentro una sección + <VirtualHost>, + todas las peticiones de ese host virtual se registrarán + solamente en el fichero especificado. Las peticiones de cualquier + host virtual que no tenga directivas de registro específicas + para él se registrarán en los registros del servidor + principal. Esta técnica es muy útil si usa un + pequeño número de hosts virtuales, pero si usa un gran + número de ellos, puede ser complicado de + gestionar. Además, puede a menudo provocar problemas con descriptores de fichero + insuficientes.

+ +

Para el registro de acceso, se puede llegar a un buen + equilibrio. Añadiendo información del host virtual al + formato de registro, es posible registrar las operaciones de todos + los hosts en un único registro, y posteriormente dividir el + fichero con todos los registros en ficheros individualizados. Por + ejemplo, considere las siguientes directivas.

+ +

+ LogFormat "%v %l %u %t \"%r\" %>s %b" + comonvhost + CustomLog logs/access_log comonvhost +

+ +

El %v se usa para registrar el nombre del host + virtual que está sirviendo la petición. Puede usar un + programa como split-logfile para + procesar posteriormente el registro de acceso y dividirlo en + ficheros independientes para cada host virtual.

Otros ficheros de registro

Módulos Relacionados	Directivas Relacionadas
`mod_cgi` `mod_rewrite`	`PidFile` `RewriteLog` `RewriteLogLevel` `ScriptLog` `ScriptLogBuffer` `ScriptLogLength`

+ + + + +

Fichero PID (PID File)

+ + +

Al iniciar, Apache httpd guarda el identificador del proceso + padre del servidor en el fichero + logs/httpd.pid. Puede modificar el nombre de este + fichero con la directiva PidFile. El identificador del + proceso puede usarlo el administrador para reiniciar y finalizar + el demonio (daemon) mediante el envío de señales al + proceso padre; en Windows, use la opción de línea de + comandos -k en su lugar. Para más información al + respecto, consulte la documentación sobre parar y reiniciar Apache.

+ + +

Registro de actividad de scripts (Script Log)

+ + +

Para ayudar a la detección de errores, la directiva + ScriptLog permite + guardar la entrada y la salida de los scripts CGI. Esta + directiva solamente debería usarla para hacer pruebas - no + en servidores en producción. Puede encontrar más + información al respecto en la documentación de mod_cgi.

+ + +

Registro de actividad de Rewrite (Rewrite Log)

+ + +

Cuando use las potentes y complejas funcionalidades de mod_rewrite, será casi + siempre necesario usar la direcitiva RewriteLog para ayudar a la + detección de errores. Este fichero de registro produce un + análisis detallado de cómo actúa este + módulo sobre las peticiones. El nivel de detalle del + registro se controla con la directiva RewriteLogLevel.

+ +