<-
Apache > Servidor HTTP > Documentaci�n > Versi�n 2.0

Archivos de Registro (Log Files)

Idiomas disponibles:  en  |  es  |  ja  |  ko 

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.

top

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.

top

Registro de Errores (Error Log)

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

top

Registro de Acceso (Access Log)

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 termin� de procesar 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.

top

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.

top

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.

top

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.

top

Otros ficheros de registro

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.

Idiomas disponibles:  en  |  es  |  ja  |  ko