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 halla 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.
El registro de errores del servidor, cuyo nombre y ubicación se especifica en la directiva ErrorLog, (ubicado en /var/log/apache2/error.log) 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.
Registro de Errores
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.
Registro de Accesos
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.
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.
La configuración de este formato se realiza en el fichero /etc/apache2/apache2.conf 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 carácter 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.
Un ejemplo sería:
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ó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» significa 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 incluidas 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 clausula 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 mostrar 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.
