Versi�n 2.0 del Servidor HTTP Apache
Versi�n 2.0 del Servidor HTTP Apache
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.
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.
| M�dulos Relacionados | Directivas Relacionadas |
|---|---|
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
| M�dulos Relacionados | Directivas Relacionadas |
|---|---|
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.
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)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)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)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)
[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
%{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\")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)2326 (%b)-". Para registrar "0" en ese caso,
use %B en su lugar.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\")/apache_pb.gif)."Mozilla/4.08 [en] (Win98; I ;Nav)"
(\"%{User-agent}i\")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.
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.
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.
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.
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.
| M�dulos Relacionados | Directivas Relacionadas |
|---|---|
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.
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.
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.