Archivos de registro de Apache_Http_Server

Para administrar eficazmente un servidor web, es necesario obtener comentarios sobre la actividad y el rendimiento del servidor, así como sobre cualquier problema que pueda estar ocurriendo. El servidor HTTP Apache proporciona capacidades de registro muy completas y flexibles. Este documento describe cómo configurar sus capacidades de registro y cómo comprender qué contienen los registros.

Visión general

El servidor HTTP Apache proporciona una variedad de mecanismos diferentes para registrar todo lo que sucede en su servidor, desde la solicitud inicial, a través del proceso de mapeo de URL, hasta la resolución final de la conexión, incluidos los errores que puedan haber ocurrido en el proceso. Además de esto, los módulos de terceros pueden proporcionar capacidades de registro o inyectar entradas en los archivos de registro existentes, y aplicaciones como programas CGI o scripts PHP u otros controladores pueden enviar mensajes al registro de errores del servidor.

En este documento discutimos los módulos de registro que son una parte estándar del servidor http.

Advertencia de seguridad

Cualquiera que pueda escribir en el directorio donde Apache httpd está escribiendo un archivo de registro, casi con certeza puede obtener acceso al uid con el que se inicia el servidor, que normalmente es root. Hacer NO dar a las personas acceso de escritura al directorio en el que se almacenan los registros sin ser conscientes de las consecuencias; consulte el documento de consejos de seguridad para obtener más detalles.

Además, los archivos de registro pueden contener información proporcionada directamente por el cliente, sin escapar. Por lo tanto, es posible que los clientes malintencionados inserten caracteres de control en los archivos de registro, por lo que se debe tener cuidado al tratar con registros sin procesar.

Registro de errores

El registro de errores del servidor, cuyo nombre y ubicación los establece el ErrorLog directiva, es el archivo de registro más importante. Este es el lugar donde Apache httpd enviará información de diagnóstico y registrará cualquier error que encuentre al procesar las solicitudes. Es el primer lugar para buscar cuando ocurre un problema al iniciar el servidor o con el funcionamiento del servidor, ya que a menudo contiene detalles de lo que salió mal y cómo solucionarlo.

El registro de errores generalmente se escribe en un archivo (generalmente error_log en sistemas Unix y error.log en Windows y OS / 2). En los sistemas Unix también es posible que el servidor envíe errores a syslog o canalizarlos a un programa.

El formato del registro de errores lo define el ErrorLogFormat directiva, con la que puede personalizar qué valores se registran. Un formato predeterminado es definido si no especifica uno. A continuación, se muestra un mensaje de registro típico:

[Fri Sep 09 10:42:29.902022 2011] [core:error] [pid 35708:tid 4328636416] [client 72.15.99.187] File does not exist: /usr/local/apache2/htdocs/favicon.ico

El primer elemento de la entrada del registro es la fecha y la hora del mensaje. El siguiente es el módulo que produce el mensaje (núcleo, en este caso) y el nivel de gravedad de ese mensaje. A esto le sigue el ID del proceso y, si corresponde, el ID del hilo del proceso que experimentó la condición. A continuación, tenemos la dirección del cliente que realizó la solicitud. Y finalmente está el mensaje de error detallado, que en este caso indica una solicitud de un archivo que no existía.

Puede aparecer una gran variedad de mensajes diferentes en el registro de errores. La mayoría se parece al ejemplo anterior. El registro de errores también contendrá la salida de depuración de los scripts CGI. Cualquier información escrita a stderr mediante un script CGI se copiará directamente al registro de errores.

Poniendo un %L token tanto en el registro de errores como en el registro de acceso producirá un ID de entrada de registro con el que puede correlacionar la entrada en el registro de errores con la entrada en el registro de acceso. Si mod_unique_id se carga, su ID de solicitud única también se utilizará como ID de entrada de registro.

Durante las pruebas, a menudo es útil monitorear continuamente el registro de errores para detectar cualquier problema. En sistemas Unix, puede lograr esto usando:

tail -f error_log

Registro por módulo

los LogLevel La directiva le permite especificar un nivel de gravedad de registro por módulo. De esta manera, si está solucionando un problema con solo un módulo en particular, puede aumentar su volumen de registro sin obtener también los detalles de otros módulos que no le interesan. Esto es particularmente útil para módulos como mod_proxy o mod_rewrite donde desea conocer los detalles sobre lo que intenta hacer.

Haga esto especificando el nombre del módulo en su LogLevel directiva:

LogLevel info rewrite:trace5

Esto establece el principal LogLevel a la información, pero lo convierte en trace5 por mod_rewrite.

Esto reemplaza las directivas de registro por módulo, como RewriteLog, que estaban presentes en versiones anteriores del servidor.

Registro de acceso

El registro de acceso al servidor registra todas las solicitudes procesadas por el servidor. La ubicación y el contenido del registro de acceso están controlados por el CustomLog directiva. los LogFormat La directiva se puede utilizar para simplificar la selección del contenido de los registros. Esta sección describe cómo configurar el servidor para registrar información en el registro de acceso.

Por supuesto, almacenar la información en el registro de acceso es solo el comienzo de la gestión del registro. El siguiente paso es analizar esta información para producir estadísticas útiles. El análisis de registros en general está más allá del alcance de este documento y no es realmente parte del trabajo del servidor web en sí. Para obtener más información sobre este tema y para las aplicaciones que realizan análisis de registros, consulte la Directorio abierto.

Varias versiones de Apache httpd han utilizado otros módulos y directivas para controlar el registro de acceso, incluidos mod_log_referer, mod_log_agent y el TransferLog directiva. los CustomLog directiva ahora subsume la funcionalidad de todas las directivas más antiguas.

El formato del registro de acceso es altamente configurable. El formato se especifica mediante una cadena de formato que se parece mucho a una cadena de formato printf (1) de estilo C. En las siguientes secciones se presentan algunos ejemplos. Para obtener una lista completa de los posibles contenidos de la cadena de formato, consulte la mod_log_configcadenas de formato.

Formato de registro común

Una configuración típica para el registro de acceso podría tener el siguiente aspecto.

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

Esto define el apodocommon y lo asocia con una cadena de formato de registro particular. La cadena de formato consta de directivas de porcentaje, cada una de las cuales le dice al servidor que registre una determinada información. Los caracteres literales también se pueden colocar en la cadena de formato y se copiarán directamente en la salida del registro. El carácter de cita (") debe escaparse colocando una barra invertida antes para evitar que se interprete como el final de la cadena de formato. La cadena de formato también puede contener los caracteres de control especiales “n“para nueva línea y”t“para pestaña.

los CustomLog directiva configura un nuevo archivo de registro utilizando el definido apodo. El nombre de archivo del registro de acceso es relativo al ServerRoot a menos que comience con una barra.

La configuración anterior escribirá entradas de registro en un formato conocido como Formato de registro común (CLF). Este formato estándar puede ser producido por muchos servidores web diferentes y leído por muchos programas de análisis de registros. Las entradas del archivo de registro generadas en CLF se verán así:

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

Cada parte de esta entrada de registro se describe a continuación.

127.0.0.1 (%h)

Esta es la dirección IP del cliente (host remoto) que realizó la solicitud al servidor. Si HostnameLookups se establece en On, luego el servidor intentará determinar el nombre de host y registrarlo en lugar de la dirección IP. Sin embargo, esta configuración no se recomienda ya que puede ralentizar significativamente el servidor. En su lugar, es mejor utilizar un posprocesador de registros como logresolve para determinar los nombres de host. La dirección IP que se indica aquí no es necesariamente la dirección de la máquina en la que está sentado el usuario. Si existe un servidor proxy entre el usuario y el servidor, esta dirección será la dirección del proxy, en lugar de la máquina de origen.

- (%l)

El “guión” en la salida indica que la información solicitada no está disponible. En este caso, la información que no está disponible es la identidad RFC 1413 del cliente determinada por identd en la máquina del cliente. Esta información es muy poco confiable y casi nunca debe usarse, excepto en redes internas estrictamente controladas. Apache httpd ni siquiera intentará determinar esta información a menos que IdentityCheck se establece en On.

frank (%u)

Este es el ID de usuario de la persona que solicita el documento según lo determinado por la autenticación HTTP. Normalmente se proporciona el mismo valor a los scripts CGI en el REMOTE_USER Variable ambiental. Si el código de estado de la solicitud (ver más abajo) es 401, entonces no se debe confiar en este valor porque el usuario aún no está autenticado. Si el documento no está protegido con contraseña, esta parte será “-“al igual que el anterior.

[10/Oct/2000:13:55:36 -0700] (%t)

La hora a la que se recibió la solicitud. El formato es:

[day/month/year:hour:minute:second zone]
day = 2*digit
month = 3*letter
year = 4*digit
hour = 2*digit
minute = 2*digit
second = 2*digit
zone = (`+' | `-') 4*digit

Es posible que la hora se muestre en otro formato especificando %formatt en la cadena de formato de registro, donde format es como en strftime(3) de la biblioteca estándar de C, o uno de los tokens especiales admitidos. Para obtener más detalles, consulte la mod_log_configcadenas de formato.

"GET /apache_pb.gif HTTP/1.0" ("%r")

La línea de solicitud del cliente se proporciona entre comillas dobles. La línea de solicitud contiene una gran cantidad de información útil. Primero, el método utilizado por el cliente es GET. En segundo lugar, el cliente solicitó el recurso /apache_pb.gif, y tercero, el cliente usó el protocolo HTTP/1.0. También es posible registrar una o más partes de la línea de solicitud de forma independiente. Por ejemplo, la cadena de formato “%m %U%q %H“registrará el método, la ruta, la cadena de consulta y el protocolo, lo que dará como resultado exactamente el mismo resultado que”%r“.

200 (%>s)

Este es el código de estado que el servidor envía al cliente. Esta información es muy valiosa, porque revela si la solicitud resultó en una respuesta exitosa (códigos que comienzan en 2), una redirección (códigos que comienzan en 3), un error causado por el cliente (códigos que comienzan en 4) o un error en el servidor (códigos que comienzan en 5). La lista completa de posibles códigos de estado se puede encontrar en el Especificación HTTP (RFC2616 sección 10).

2326 (%b)

La última parte indica el tamaño del objeto devuelto al cliente, sin incluir los encabezados de respuesta. Si no el contenido se devolvió al cliente, este valor será “-“. Iniciar sesión “0“sin contenido, utilice %B en lugar de.

Formato de registro combinado

Otra cadena de formato de uso común se llama Formato de registro combinado. Se puede utilizar de la siguiente manera.

LogFormat "%h %l %u %t "%r" %>s %b "%Refereri" "%User-agenti"" combined
CustomLog log/access_log combined

Este formato es exactamente el mismo que el formato de registro común, con la adición de dos campos más. Cada uno de los campos adicionales usa la directiva percent %headeri, dónde encabezamiento puede ser cualquier encabezado de solicitud HTTP. El registro de acceso con este formato se verá así:

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" ("%Refereri")

El encabezado de solicitud HTTP “Referer” (sic). Esto le da al sitio desde el que el cliente informa haber sido referido. (Esta debe ser la página que enlaza o incluye /apache_pb.gif).

"Mozilla/4.08 [en] (Win98; I ;Nav)" ("%User-agenti")

El encabezado de la solicitud HTTP del agente de usuario. Esta es la información de identificación que el navegador del cliente informa sobre sí mismo.

Registros de acceso múltiple

Se pueden crear múltiples registros de acceso simplemente especificando múltiples CustomLog directivas en el archivo de configuración. Por ejemplo, las siguientes directivas crearán tres registros de acceso. El primero contiene la información CLF básica, mientras que el segundo y el tercero contienen información del navegador y del referente. Los últimos dos CustomLog Las líneas muestran cómo imitar los efectos de la ReferLog y AgentLog directivas.

LogFormat "%h %l %u %t "%r" %>s %b" common
CustomLog logs/access_log common
CustomLog logs/referer_log "%Refereri -> %U"
CustomLog logs/agent_log "%User-agenti"

Este ejemplo también muestra que no es necesario definir un apodo con la LogFormat directiva. En cambio, el formato de registro se puede especificar directamente en el CustomLog directiva.

Registros condicionales

Hay ocasiones en las que es conveniente excluir determinadas entradas de los registros de acceso en función de las características de la solicitud del cliente. Esto se logra fácilmente con la ayuda de variables de entorno. Primero, se debe establecer una variable de entorno para indicar que la solicitud cumple ciertas condiciones. Esto generalmente se logra con SetEnvIf. Entonces el env= cláusula del CustomLog La directiva se usa para incluir o excluir solicitudes donde se establece la variable de entorno. Algunos ejemplos:

# Mark requests from the loop-back interface
SetEnvIf Remote_Addr "127.0.0.1" dontlog
# Mark requests for the robots.txt file
SetEnvIf Request_URI "^/robots.txt$" dontlog
# Log what remains
CustomLog logs/access_log common env=!dontlog

Como otro ejemplo, considere registrar solicitudes de hablantes de inglés en un archivo de registro y de personas que no hablan inglés en un archivo de registro diferente.

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

En un escenario de almacenamiento en caché, uno querría saber acerca de la eficiencia de la caché. Un método muy simple para averiguarlo sería:

SetEnv CACHE_MISS 1
LogFormat "%h %l %u %t "%r " %>s %b %CACHE_MISSe" common-cache
CustomLog logs/access_log common-cache

mod_cache correrá antes mod_env y, cuando tenga éxito, entregará el contenido sin él. En ese caso, se registrará un acierto de caché -, mientras que una falta de caché registrará 1.

Además de env= sintaxis, LogFormat admite valores de registro condicionados al código de respuesta HTTP:

LogFormat "%400,501User-agenti" browserlog
LogFormat "%!200,304,302Refereri" refererlog

En el primer ejemplo, el User-agent se registrará si el código de estado HTTP es 400 o 501. En otros casos, se registrará un literal “-” en su lugar. Asimismo, en el segundo ejemplo, el Referer se registrará si el código de estado HTTP es no 200, 204 o 302. (Tenga en cuenta el “!” Antes de los códigos de estado.

Aunque acabamos de demostrar que el registro condicional es muy potente y flexible, no es la única forma de controlar el contenido de los registros. Los archivos de registro son más útiles cuando contienen un registro completo de la actividad del servidor. A menudo, es más fácil simplemente posprocesar los archivos de registro para eliminar las solicitudes que no desea considerar.

Rotación de registros

Incluso en un servidor moderadamente ocupado, la cantidad de información almacenada en los archivos de registro es muy grande. El archivo de registro de acceso suele crecer 1 MB o más por cada 10.000 solicitudes. En consecuencia, será necesario rotar periódicamente los archivos de registro moviendo o eliminando los registros existentes. Esto no se puede hacer mientras el servidor se está ejecutando, porque Apache httpd continuará escribiendo en el archivo de registro anterior siempre que lo mantenga abierto. En su lugar, el servidor debe reiniciarse después de que los archivos de registro se muevan o eliminen para que abra nuevos archivos de registro.

Usando un agraciado reiniciar, se puede indicar al servidor que abra nuevos archivos de registro sin perder ninguna conexión existente o pendiente de los clientes. Sin embargo, para lograr esto, el servidor debe continuar escribiendo en los archivos de registro antiguos mientras termina de atender las solicitudes antiguas. Por lo tanto, es necesario esperar un tiempo después del reinicio antes de realizar cualquier procesamiento en los archivos de registro. Un escenario típico 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 forma de realizar la rotación de registros es utilizar registros canalizados como se explica en la siguiente sección.

Registros canalizados

Apache httpd es capaz de escribir errores y acceder a archivos de registro a través de una tubería a otro proceso, en lugar de directamente a un archivo. Esta capacidad aumenta drásticamente la flexibilidad del registro, sin agregar código al servidor principal. Para escribir registros en una tubería, simplemente reemplace el nombre del archivo con el carácter de la tubería “|“, seguido del nombre del ejecutable que debe aceptar entradas de registro en su entrada estándar. El servidor iniciará el proceso de registro de canalizaciones cuando se inicie el servidor y lo reiniciará si falla mientras el servidor está en ejecución. (Esta última característica es por eso que podemos referirnos a esta técnica como “registro de canalización confiable”).

Los procesos de registro canalizados son generados por el proceso principal de Apache httpd y heredan el ID de usuario de ese proceso. Esto significa que los programas de registro canalizados normalmente se ejecutan como root. Por tanto, es muy importante que los programas sean sencillos y seguros.

Un uso importante de los registros canalizados es permitir la rotación de registros sin tener que reiniciar el servidor. El servidor HTTP Apache incluye un programa simple llamado rotatelogs para 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 utilizan para encerrar todo el comando que se llamará para la tubería. Aunque estos ejemplos son para el registro de acceso, se puede utilizar la misma técnica para el registro de errores.

Al igual que con el registro condicional, los registros canalizados son una herramienta muy poderosa, pero no deben usarse cuando se encuentra disponible una solución más simple como el posprocesamiento fuera de línea.

De forma predeterminada, el proceso de registro canalizado se genera sin invocar un shell. Usar “|$” en lugar de “|“para desovar usando un caparazón (generalmente con /bin/sh -c):

# Invoke "rotatelogs" using a shell
CustomLog "|$/usr/local/apache/bin/rotatelogs   /var/log/access_log 86400" common

Este era el comportamiento predeterminado de Apache 2.2. Dependiendo de las especificaciones del shell, esto podría conducir a un proceso de shell adicional durante la vida útil del programa de canalización de registro y problemas de manejo de señales durante el reinicio. Por razones de compatibilidad con Apache 2.2, la notación “||“también es compatible y equivale a usar”|“.

Nota de Windows

Tenga en cuenta que en Windows, puede tener problemas al ejecutar muchos procesos de registrador de canalización, especialmente cuando HTTPD se ejecuta como un servicio. Esto se debe a que se ha agotado el espacio en el montón del escritorio. El espacio del montón de escritorio otorgado a cada servicio se especifica mediante el tercer argumento de la SharedSection en el valor de registro HKEY_LOCAL_MACHINE System CurrentControlSet Control SessionManager SubSystems Windows. Cambie este valor con cuidado; Se aplican las advertencias normales para cambiar el registro de Windows, pero también puede agotar el grupo de almacenamiento del escritorio si el número se ajusta demasiado alto.

Hosts virtuales

Cuando se ejecuta un servidor con muchos hosts virtuales, existen varias opciones para manejar los archivos de registro. Primero, es posible usar registros exactamente como en un servidor de un solo host. Simplemente colocando las directivas de registro fuera del secciones en el contexto del servidor principal, es posible registrar todas las solicitudes en el mismo registro de acceso y registro de errores. Esta técnica no permite una recopilación sencilla de estadísticas sobre hosts virtuales individuales.

Si CustomLog o ErrorLog las directivas se colocan dentro de un , todas las solicitudes o errores para ese host virtual se registrarán solo en el archivo especificado. Cualquier host virtual que no tenga directivas de registro aún tendrá sus solicitudes enviadas a los registros del servidor principal. Esta técnica es muy útil para una pequeña cantidad de hosts virtuales, pero si la cantidad de hosts es muy grande, puede ser complicado de administrar. Además, a menudo puede crear problemas con descriptores de archivo insuficientes.

Para el registro de acceso, existe un muy buen compromiso. Al agregar información sobre el host virtual a la cadena de formato de registro, es posible registrar todos los hosts en el mismo registro y luego dividir el registro en archivos individuales. Por ejemplo, considere las siguientes directivas.

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

los %v se utiliza para registrar el nombre del host virtual que atiende la solicitud. Luego, se puede usar un programa como split-logfile para posprocesar el registro de acceso para dividirlo en un archivo por host virtual.

Otros archivos de registro

Registro de bytes reales enviados y recibidos

mod_logio agrega en dos adicionales LogFormat campos (% I y% O) que registran el número real de bytes recibidos y enviados en la red.

Registro forense

mod_log_forensic proporciona el registro forense de las solicitudes de los clientes. El registro se realiza antes y después de procesar una solicitud, por lo que el registro forense contiene dos líneas de registro para cada solicitud. El registrador forense es muy estricto sin personalizaciones. Puede ser una herramienta de depuración y seguridad invaluable.

Archivo PID

En el inicio, Apache httpd guarda la identificación del proceso del proceso httpd principal en el archivo logs/httpd.pid. Este nombre de archivo se puede cambiar con el PidFile directiva. El id. De proceso es para que lo utilice el administrador para reiniciar y finalizar el demonio enviando señales al proceso padre; en Windows, use la opción de línea de comando -k en su lugar. Para obtener más información, consulte la página Detener y reiniciar.

Registro de secuencia de comandos

Para ayudar en la depuración, el ScriptLog La directiva le permite registrar la entrada y la salida de los scripts CGI. Esto solo debe usarse en pruebas, no para servidores en vivo. Hay más información disponible en la documentación de mod_cgi.