Servidor Apache HTTP versión 2.4
Servidor Apache HTTP versión 2.4
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 Advertencia de seguridad Registro de errores Registro por módulo Registro de acceso Rotación de registros Registros canalizados Hosts virtuales Otros archivos de registro
| Módulos relacionados | Directivas relacionadas |
|---|---|
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, incluyendo cualquier error que pueda 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.
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. No NO dar a la gente el acceso de escritura en el directorio de los registros se almacenan en 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.
| Módulos relacionados | Directivas relacionadas |
|---|---|
El registro de errores del servidor, cuyo nombre y ubicación los establece la
ErrorLogdirectiva, 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_logen sistemas Unix y
error.logen Windows y OS / 2). En los sistemas Unix también es posible que el servidor envíe errores
syslogo los canalice a un programa .
El formato del registro de errores lo define la ErrorLogFormatdirectiva, con la que puede personalizar los valores que 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 stderrpor un script CGI se copiará directamente al registro de errores.
Poner un %Ltoken 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_idestá cargado, 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
La LogLeveldirectiva 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_proxyo mod_rewritedonde quiere saber detalles sobre lo que está intentando hacer.
Haga esto especificando el nombre del módulo en su
LogLeveldirectiva:
Reescritura de información de LogLevel : trace5
Esto establece el main LogLevelen info, pero lo convierte en trace5for
mod_rewrite.
RewriteLogque estaban presentes en versiones anteriores del servidor.| Módulos relacionados | Directivas relacionadas |
|---|---|
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 la CustomLog
directiva. La LogFormat
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 Open Directory .
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 la
TransferLogdirectiva. La CustomLogdirectiva 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 las mod_log_config cadenas de formato .
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 apodo common 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 comillas ( ") 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 tabulación.
La CustomLog
directiva configura un nuevo archivo de registro utilizando el apodo definido
. El nombre de archivo para el registro de acceso es relativo a a ServerRootmenos 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 producidas 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)HostnameLookupsestá configurado en On, 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 logresolvepara 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)identden 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 IdentityCheckesté configurado en On.frank (%u)REMOTE_USERvariable de entorno. 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á " -" igual que la anterior.[10/Oct/2000:13:55:36 -0700]
(%t)
[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 %{format}ten la cadena de formato de registro, donde formates como en
strftime(3)la biblioteca estándar de C, o uno de los tokens especiales admitidos. Para obtener más información, consulte las mod_log_config cadenas de formato .
"GET /apache_pb.gif HTTP/1.0"
(\"%r\")GET. En segundo lugar, el cliente solicitó el recurso
/apache_pb.gify, en tercer lugar, 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 la misma salida que " %r".200 (%>s)2326 (%b)-". Para registrar " 0" sin contenido, utilice %Ben su
lugar.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 \"% {Referer} i \ "\"% {User-agent} i \ "" combinado CustomLog log / access_log combinado
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
, donde el encabezado puede ser cualquier encabezado de solicitud HTTP. El registro de acceso con este formato se verá así:%{header}i
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\")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. Las dos últimas CustomLoglíneas muestran cómo imitar los efectos de las directivas ReferLogy AgentLog.
LogFormat "% h%% l u% t \" % r \ "%> s% b" común CustomLog logs / access_log común CustomLog logs / referer_log "% {Referer} i ->% U" CustomLog logs / agent_log "% { Usuario-agente} i "
Este ejemplo también muestra que no es necesario definir un apodo con la LogFormatdirectiva. En cambio, el formato de registro se puede especificar directamente en la CustomLogdirectiva.
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. Luego, la
env=cláusula de la CustomLogdirectiva se usa para incluir o excluir solicitudes donde se establece la variable de entorno. Algunos ejemplos:
# Marcar solicitudes desde la interfaz de bucle de retorno SetEnvIf Remote_Addr "127 \ .0 \ .0 \ .1" dontlog # Marcar solicitudes para el archivo robots.txt SetEnvIf Request_URI "^ / robots \ .txt $" dontlog # Registrar lo que queda de CustomLog logs / access_log common env =! no registrar
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 - Idioma "en" inglés CustomLog logs / english_log common env = english CustomLog logs / non_english_log common env =! inglés
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_MISS} e" common-cache CustomLog logs / access_log common-cache
mod_cachese ejecutará antes
mod_envy, cuando tenga éxito, entregará el contenido sin él. En ese caso, se registrará un acierto de caché
-, mientras que un error de caché se registrará 1.
Además de la env=sintaxis, LogFormatadmite valores de registro condicionados al código de respuesta HTTP:
LogFormat "% 400,501 {User-agent} i" browserlog LogFormat "%! 200,304,302 {Referer} i" refererlog
En el primer ejemplo, User-agentse 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, Refererse registrará si el código de estado HTTP no es 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.
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.
Mediante el uso de una grácil reinicio, el servidor puede ser instruido para nuevos archivos de registro abiertos sin perder existentes o pendientes de conexiones de 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.
Apache httpd es capaz de escribir archivos de registro de acceso y error 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 tubería " |", seguido del nombre del ejecutable que debería 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 la razón por la que podemos referirnos a esta técnica como "registro canalizado confiable").
Los procesos de registro canalizados son generados por el proceso principal httpd de Apache 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" común
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 donde se encuentre 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. Use " |$" en lugar de " |" para generar usando un shell (generalmente con /bin/sh -c):
# Invocar "rotatelogs" usando un 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 es equivalente a usar " |".
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 de almacenamiento dinámico del escritorio otorgado a cada servicio se especifica mediante el tercer argumento del
SharedSectionparámetro 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.
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 de las <VirtualHost>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 las
directivas CustomLog
o ErrorLogse colocan dentro de una
<VirtualHost>
sección, 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
Se %vutiliza 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.
| Módulos relacionados | Directivas relacionadas |
|---|---|
mod_logioagrega dos LogFormatcampos adicionales
(% I y% O) que registran el número real de bytes recibidos y enviados en la red.
mod_log_forensicproporciona 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.
Al iniciarse, Apache httpd guarda el ID de proceso del proceso httpd principal en el archivo logs/httpd.pid. Este nombre de archivo se puede cambiar con la PidFiledirectiva. 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 .
Para ayudar en la depuración, la
ScriptLogdirectiva le permite registrar la entrada y 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 .
.png){kind=small}