Análisis Estadístico de un Servidor Web

¡Bienvenido al maravilloso mundo del análisis de uso de un servidor web!

Este documento tiene el fin de suministrar los conocimientos necesarios de como se realizan los análisis de un servidor web, que buscar y que se puede encontrar.

Específicamente este documento esta dirigido a los usuarios de Webalizer (una de las aplicaciones usada en las servidores de ICTEA) pero puede ser válida para la mayoría de las aplicaciones de análisis de servidores web.

Si se inicia en el análisis web o, simplemente desea saber como funciona el análisis de un servidor web, este documento es para Ud.

¡Visíteme, por favor!

Muy bien, tiene una web y desea saber si alguien la visita, y, si es así, que es lo que ven y cuantas veces.

Por suerte para Ud., la mayoría de los servidores web mantienen un registro de que ocurre, así que, sólo tiene acceder a él y mirar.

Los registros son ficheros de texto, por lo que con cualquier editor de texto (como el Block de Notas de Windows) le valdrá. Cada vez que alguien visita una página de su web, o pide cualquier componente de ella (conocido como URL o Uniform Resource Locator), el servidor web escribe una línea al final del registro que indica esa petición.

Desafortunadamente, los ficheros de registro son algo que parece imposible de ser leído por un humano no iniciado. Mientras que Ud. puede ser capaz de saber si alguien accede a su web, cualquier otra información necesita de algo adicional para ser leída.

Una entrada típica del registro sería algo como:

192.168.45.13 - - [24/May/2005:11:20:39 -0400] "GET /mipagina.html HTTP/1.1" 200 117

Esto indica una petición desde un ordenador con dirección IP 192.168.45.13 de la URL /mipagina.html al servidor web. También indica la fecha y hora en que se hace la petición, el tipo de petición, el código de resultado de esa petición y cuantos bytes se enviaron al navegador remoto.

Existirá una línea similar a esta por cada petición hecha al servidor web en el periodo cubierto por el registro.

Un 'Hit' es otra forma de decir 'petición hecha al servidor web', así, cada línea del registro representa un 'Hit'. Si quiere saber cuantos 'Hits' recibió su servidor, simplemente cuente el número de líneas en el fichero de registro. Y como cada línea indica una petición de una determinada URL desde una determinada dirección IP, puede fácilmente conocer las peticiones que recibió por cada una de sus páginas web o las peticiones que recibió desde una dirección IP determinada simplemente contando las líneas del registro que las contienen.

Si, así de sencillo. Y mientras esto se puede hacer de forma no automática usando un editor de texto (como el 'Bloc de notas' de Windows) o cualquier otro procesador de texto, es más sencillo y práctico usar un programa especificamente diseñado para analizar los registros, comoWebalizerit, ya que realiza todo el trabajo por usted, suministra herramientas para analizar otros aspectos de su servidor web y presenta los datos de forma fácil de interpretar.

¿Cómo funciona Webalizer? -

Bien, para entender lo que puede analizar debe saber que información obtiene su servidor y como la obtiene.

Finalmente deberá entender como funciona el protocolo HTTP (HyperText Transport Protocol), y sus puntos fuertes y debiles.

Básicamente, un servidor web está a la espera de recibir una petición de un navegador. Una vez recibe la petición, el servidor la procesa y envia algo al navegador que ha realizado la petición (y como se ha indicado antes, la petición la registra).

Las peticiones son tipicamente de una URL, aunque existe otro tipo de información que puede solicitar un navegador remoto, tales como el tipo de servidor web, versiones del protocolo HTTP que soporta, fechas de modificación, etc., aunque estas no son comunes.

Para visualizar la interacción entre el servidor, el navegador y las páginas web veremos con un ejemplo el flujo de la información. Suponga una simple página web 'mipagina.html', que es una página HTML y que contiene dos imágenes gráficas: 'miimagen1.jpg' y 'miimagen2.jpg'.

La interacción entre el servidor y el navegador sería algo como lo siguiente:

  1. El navegador solicita la URL 'mipagina.html'.
  2. El servidor recibe la petición y envía la página HTML.
  3. El navegador nota que en dicha página hay dos gráficos, así que solicita el primero 'miimagen1.jpg'.
  4. El servidor recibe la petición y envía el gráfico.
  5. El navegador solicita entonces el segundo gráfico, 'miimagen2,jpg'.
  6. El servidor recibe la petición y envía el gráfico.
  7. El navegador presenta la página con los dos gráficos al usuario.

Se añadirían las siguientes líneas al registro del servidor:

192.168.45.13 - - [24/May/2005:11:20:39 -0400] "GET /mipagina.html HTTP/1.1" 200 117

192.168.45.13 - - [24/May/2005:11:20:40 -0400] "GET /miimagen1.jpg HTTP/1.1" 200 231

192.168.45.13 - - [24/May/2005:11:20:41 -0400] "GET /miimagen2.jpg HTTP/1.1" 200 432

¿Qué podemos conocer de este intercambio? Basándose en lo indicado antes, podemos contar el número de líneas del fichero de registro para saber que el servidor recibió tres 'hits' (peticiones) durante el período cubierto. También podemos determinar el número de peticiones de cada URL (en este caso, 1 por cada).

En cada línea podemos ver que el servidor recibió tres peticiones desde la dirección IP 192.168.45.13, y la hora en que se recibieron dichas peticiones. Los dos números al final de cada línea representan el código de respuesta y el número de bytes enviados al navegador peticionario. El código de respuesta indica como el servidor gestionó la petición y estos códigos están definidos como parte del protocolo HTTP.

En este ejemplo, todos son 200 que significa que todo fue OK. Un código de respuesta que le puede resultar familiar es el muy común '404 - No Encontrado', que indica que la URL solicitada no se pudo encontrar en el servidor. Existen otros muchos códigos de respuesta, sin embargo, estos son los más comunes.

Y esto es lo que puede saber con precisión de los ficheros de registro. Pero se preguntará por qué la mayoría de los programas de análisis de los registros presentan otros muchos valores. Se pueden obtener otros valores más 'obscuros' como el número de códigos de respuesta diferentes, el número de peticiones hechas (hits) en un periodo determinado, el valor total de los bytes enviados a los navegadores remotos, etc.

Se pueden obtener otros valores basados en ciertas suposiciones, sin embargo, estos no se pueden considerar totalmente precisos, y algunos pueden ser bastante imprecisos.

Un servidor web puede usar otros formatos de los ficheros de registro, que dan más información que el formato CLF (Common Log Format) indicado antes, y estos formatos se discutirán en breve.

Por ahora, sepa que, lo único que puede saber con precisión es la dirección IP que realiza la petición y que URL pide, y cuando se realiza la petición, como se muestra en el ejemplo de antes.

El Bueno, el Feo y el Malo.-

Ahora ya tiene una idea de como funciona un servidor web y que información se puede obtener de sus ficheros de registro, como el número de peticiones al servidor de URLs específicas, número de direcciones IP que realizan peticiones, cuantas peticiones se realizan desde cada dirección IP y cuando se hicieron.

Con esa información, se puede responder a preguntas como: "¿Cuál es la URL más popular de mi web?", "¿Cuál es la siguiente más popular?", "¿Desde qué dirección IP se han realizado más peticiones a mi servidor?" y "¿Qué ocupado ha estado el servidor durante un periodo?".

La mayoría de los programas de análisis le permitirán responder a preguntas como "¿A que hora está mi web más activa?" o "¿Qué día de la semana es el más ocupado?". Le permiten analizar el modelo de visitas a la web, lo que puede ser no tan aparente mirando simplemente los ficheros de registro del servidor web.

Todas las preguntas pueden ser contestadas con absoluta precisión con un simple análisis de los ficheros de registro.

¡Buenas noticias! ¿Malas noticias? Bien, con todo lo que puede determinar mirando a los ficheros de registro, existen muchas cosas que no puede determinar con precisión. Desafortunadamente, algunos programas de análisis le incitan a pensar lo contrario, y olvidan indicarle (sobre todo los programas comerciales) que muchas determinaciones no son más que suposiciones y no pueden ser consideradas en absoluto precisas. ¿Cómo qué? se preguntará. Bien, por ejemplo, lo que algunos programas llaman 'navegación del visitante' o simplemente 'navegación' y supone que indican que páginas visitó un usuario de su web y en que orden. ¿O qué sobre el tiempo que se supone qué un visitante pasó en su web? Otro parámetro que no es posible calcular con precisión es el de 'visitas' o cuantos usuarios 'han visitado' su web en un periodo de tiempo. Todos estos no pueden ser calculados con precisión por diferentes razones. Veamos algunas:

El protocolo HTTP es 'apatrida'.-

En un programa de ordenador que hace correr en su propia máquina, siempre puede determinar lo que el usuario está haciendo. Accede al programa, hace lo que sea, y cuando termina, sale del programa.

El protocolo HTTP, sin embargo, es diferente. El servidor web sólo ve peticiones desde una dirección IP. La dirección IP se conecta, envía la petición, recibe la respuesta y se desconecta. El servidor web no tiene idea lo que pasa en el lado remoto entre estas peticiones, e incluso, lo que hizo con la respuesta que se le envió.

Esto hace imposible determinar cosas como cuanto tiempo pasó un visitante en su web. Por ejemplo, si una dirección IP hace una petición a su servidor de su página inicial, luego, a los 15 minutos hace otra de cualquier otra página de su web. ¿Puede determinar cuanto tiempo el visitante ha pasado en su web? La respuesta es, claro, ¡No! Simplemente porque pasaron 15 minutos entre las peticiones, no sabe lo que la dirección remota hizo entre las peticiones.

Pudo visitar su web, ir a cualquier otra web para volver 15 minutos después a la suya y pedir otra página.

Algunos programas de análisis dirán que el visitante paso al menos 15 minutos en su web más algún tiempo adicional para ver la última página pedida (como 5 minutos o así). Esto es realmente una estimación y nada más.

No puede determinar visitantes individuales.-

Los servidores web reciben las peticiones y envían la respuesta a la dirección IP que hace la petición. No hay forma de determinar que es esa dirección IP, sólo que la petición la hizo ella. Puede ser una persona física, un programa que corre en una máquina, o pueden ser muchas personas que emplean la misma dirección IP (más sobre esto más adelante). Algunos de Uds. notarán que el protocolo HTTP dispone de un mecanismo para autenticación del usuario, cuando se solicita 'nombre de usuario' y 'contraseña' para acceder a una web o a páginas de esta. Y mientras que esto es verdad, es algo que una web pública, como son la mayoría, no usa (de otra forma no sería pública).

Por ejemplo, digamos que se hace una petición al servidor desde una dirección IP, y que un minuto más tarde, otra dirección IP hace una petición. ¿Puede decir cuanta gente visitó su web? De nuevo, la respuesta es ¡No! Una de esas peticiones puede venir del 'spider' de un buscador, un programa diseñado para rastrear una web buscando enlaces y cosas así. Ambas peticiones pudieron haber venido del mismo usuario, pero desde distintas direcciones IP.

Algunos programas de análisis intentarán determinar el número de visitantes basándose en cosas como la dirección IP más el tipo de navegador, pero incluso así, no son más que estimaciones basadas en hipótesis imprecisas.

La topología de la red Internet hace problemático incluso las direcciones IP.-

Antes, cada máquina que deseaba hablar en Internet, disponía de su propia y única, dirección IP. Sin embargo, según crece Internet se produce una mayor demanda de direcciones IP. Como consecuencia, se desarrollan diferentes métodos de conectarse a Internet para paliar el problema de direcciones IP.

Supongamos, por ejemplo, un usuario doméstico de conexión telefónica. Hace un llamada al suministrador de servicios de Internet, los ordenadores negocian la conexión y se le asigna una dirección IP de un conjunto de direcciones IP que se le han asignado al suministrador. Una vez que el usuario se desconecta, esa dirección IP está disponible para otros usuarios. El usuario doméstico obtiene típicamente una dirección IP distinta cada vez que se conecta, significando que, si por cualquier motivo se desconecta, al reconectarse obtendrá una dirección IP diferente.

Dada esta situación, el mismo usuario puede aparecer con diferentes direcciones IP en un periodo de tiempo.

Otra situación típica se produce en una empresa, dónde todos los PCs emplean direcciones IP privadas para hablar entre ellos internamente, y se conectan a Internet a través de una máquina 'gateway' o 'firewall' que traduce sus IPs privadas a la IP pública que usa el gateway/firewall. Esto puede hacer que todos los usuarios en la empresa aparezcan como si estuviesen usando la misma dirección IP.

Los servidores 'proxy' funcionan de una forma similar, pudiendo existir miles de usuarios que aparecen provenientes de la misma dirección. Dadas estas situaciones, ¿puede decir cuántos usuarios han visitado su web si el fichero de registro muestra 10 peticiones desde la misma dirección IP en la última hora? De nuevo la respuesta es ¡No! Ha podido ser el mismo usuario, o han podido ser múltiples usuarios detrás del mismo 'firewall'. ¿Y si el registro muestra 10 peticiones desde 10 direcciones IP distintas? ¿Piensa que han sido 10 usuarios distintos? Pueden haber sido 10 usuarios distintos, uno o más usuarios y el 'spider' de un buscador, o cualquier combinación.

Pero espere, hay más.-

Bien, ¿qué hemos aprendido? En resumen, no sabe quien o que realiza las peticiones a el servidor, y no puede suponer que una sola dirección IP es un sólo usuario. Naturalmente puede hacer todo tipo de estimaciones, pero eso es lo que hay y no puede considerarlas precisas.

Veamos el siguiente ejemplo: La dirección A hace una petición al servidor. Un minuto después, la dirección B hace otra petición, y 10 minutos después la dirección A hace otra petición. ¿Qué se puede determinar de esta secuencia? Bien, podemos suponer la visita de dos usuarios. Pero ¿y si la dirección A es un firewall? Las dos peticiones desde A pueden haber sido dos usuarios distintos. Y si el usuario en A se desconecta, y al reconectarse obtiene una dirección diferente (dirección B) y alguien se conectó en este momento y obtuvo la dirección A. O puede ser un usuario que se conecta a través de un 'reverse-proxy' y las tres peticiones provinieron del mismo usuario. ¿Y puede decir la navegación del usuario en la web o cuanto tiempo permaneció en ella?

Afortunadamente ahora sabe que la respuesta a estas preguntas es un rotundo NO. No podemos, sin ser capaces de identificar usuarios únicos, decir lo que un usuario único hace. Sin embargo, no todo está perdido. Con el tiempo, la gente ha encontrado formas de superar estas limitaciones. El código de los sistemas se ha escrito para sortear la naturaleza 'apatrida' del protocolo HTTP. Se emplean 'cookies' y otros identificadores para realizar el seguimiento de los usuarios, así como páginas web dinámicas con bases de datos de soporte. Sin embargo, todo esto es, básicamente, externo al protocolo, y, por tanto, no queda registrado de forma estándar por el servidor, y se necesitan herramientas especializadas para ser analizado.

En todos los demás casos, cualquier valor que indique da información de estos, sólo pueden ser considerados estimaciones basadas en ciertas asunciones.

Un ejemplo de ello puede encontrarse en la herramienta Webalizer. El concepto de 'Visit' es un valor que no puede considerado exacto, aunque sea de las cosas que Webalizer muestra. Se incluyó debido a las numerosas peticiones de individuos que usaban el programa. Se basa en asumir que una sola dirección IP representa un sólo usuario. Ya hemos indicado como esta suposición es muy debil en el mundo real, y si lee la documentación del programa, verá que claramente indica que el valor 'Visits' (junto a 'Entry page' y 'Exit page') no se deben considerar precisos, sino simplemente valores estimados. No hemos todavía profundizado en los conceptos de páginas 'Entry' y 'Exit', pero se basan en el concepto de 'Visit' que ya sabemos no es preciso. Se suponen que son la primera y última página que ve una visita de su web. Si se recibe una petición que se considera una nueva 'Visit', entonces la URL de esa petición es, en teoría, la página de entrada (Entry page) a la web. De igual forma, la última URL solicitada sería la página de abandono de la web (Exit page).

De igual forma, y al estar basados en el concepto de 'Visit', se deben considerar con la misma precaución el concepto de navegación de la visita ('path' o 'trail'), es decir, que páginas ha visitado y en que orden.

Uno de los valores más graciosos a considerar en un determinado programa de análisis, es el que se supone de dónde procede la visita, basado en dónde esta registrado el dominio que realiza la petición. Idea inteligente, pero sin ningún valor. Tomemos por ejemplo el dominio del suministrador AOL (America On-Line) que está registrada en Virginia. El programa considera a todos los que usan AOL como viviendo en Virginia, que sabemos no es el caso de este suministrador con puntos de acceso a Internet en todo el mundo (AOL es unos de los suministradores de conectividad más importantes de Estados Unidos (como en España, Telefónica).

Personalmente, hace tiempo me conectaba a Internet desde Madrid a través de AOL. Para las webs que visitara yo era una visita desde Virginia y no era así.)

Otros valores que puede determinar.-

Ahora que ha visto lo que es posible, puede pensar que existen otros valores que estos programas muestran y que precisos pueden ser.

Afortunadamente, y en base a lo que ha leído hasta ahora, deberá ser capaz de saberlo por Ud. mismo. Uno de estos valores es el de 'page' o 'page view'. Como sabemos, una página web esta formada por un documento HTML de texto y normalmente otros elementos como imágenes gráficas, audio u otros objetos multimedia, hojas de estilo, etc. La petición de una página web puede generar docenas de peticiones de estos elementos, pero la mayoría de la gente desea saber cuantas páginas web se han solicitado sin tener que considerar todos los elementos que las forman. Puede obtener este número si sabe que tipo de ficheros puede considerar una 'página'. En un servidor normal, estos serían aquellas URLs con extensión .htm o .html. Quizás su web es dinámica, por lo que las extensiones de sus páginas web serán .asp, .pl o .php. Obviamente no querrá contar las imágenes .gif o .jpg como páginas, ni tampoco las hojas de estilo, gráficos dinámicos flash u otros elementos. Puede analizar el fichero de registro y contar las peticiones de URLs que coinciden con sus criterios de 'página', pero la mayoría de los programas de análisis web (incluyendo Webalizer) realizan esta labor por Ud.

Otra información.-

Hasta ahora sólo hemos considerado el formato CLF (Common Log Format), pero existen otros. El más común es el denominado 'combinado', y que toma el formato CLF y le añade dos elementos más de información. Al final se añaden 'user agent' y 'referrer'.

Un 'user agent' es simplemente el nombre del navegador o programa (Internet Explorer, Mozilla Firefox, Chrome, Opera, Konqueror, Safari, etc.) que se usa para realizar la petición al servidor web.

El 'referrer' se supone que es la página web desde la que el usuario llega a su web.

Desafortunadamente, ambos pueden dar lugar a confusión. El nombre de 'user agent' puede ser puesto el que se desee en los navegadores modernos. Un truco corriente de los usuarios del navegador Opera es indicar que es un 'user agent' Internet Explorer de forma que pueden ver webs que sólo permiten visitas de Internet Explorer.

Y el 'referrer', conforme a la documentación estándar (RFC) para el protocolo HTTP, se puede o no usar en los navegadores elegidos, y si se usa, no tiene que ser preciso e incluso informativo.

El servidor web Apache (que es uno de los más usados en Internet) permite el registro de otras cosas tales como la información de las cookies, el tiempo empleado en gestionar una petición y muchas cosas más.

Desafortunadamente, la inclusión y localización de esta información en los ficheros de registro de los servidores no es estándar.

Otro formato desarrollado por W3C (World Wide Web Consortium), permite generar registros a partir de elementos variados de información, y su localización puede ser cualquiera en un registro, siendo necesaria una cabecera para mapearlos.

Los programas de análisis web manejan unos formatos mejor que otros.

Técnicas de Análisis.-

La única forma de tener una visión precisa de lo que hacer el servidor web es mirar sus ficheros de registro.

Esta es la forma en que la mayoría de los programas de análisis obtienen sus datos, y es la más precisa. Se pueden emplear otros métodos con distintos resultados.

Un método común, que fue muy popular por algún tiempo, fue el uso de un 'contador de visitas'. Básicamente, consistía en un 'bit' dinámico incluido en una página web, que incrementaba un contador y mostraba su valor cada vez que la página era solicitada.

Un problema de este método era que había que incluir un fichero gráfico distinto por cada página de la que se deseaba hacer el seguimiento. Otro problema se presentaba si el navegador del usuario remoto no presentaba imágenes (tenía esta opción no habilitada o usaba un navegador de 'sólo texto' que no presentaba imágenes). También era posible 'inflar' el valor del contador simplemente pulsando el botón 'refrescar' del navegador una y otra vez.

Se desarrollaron métodos similares usando los lenguajes Java y Javascript, en un intento de obtener incluso más información sobre la visita, tales como determinar la resolución de pantalla y el sistema operativo usado.

Por supuesto, esto podía también ser fácilmente 'burlado'.

Algunas empresas desarrollaron sistemas que decían eran capaces de hacer un seguimiento remoto del servidor web, mediante la inclusión de una imagen o elemento javascript en su web, que contactaba el sistema de la empresa cada vez que la imagen o elemento javascript era solicitado.

Todos tenían los mismos problemas y limitaciones. Podía deshabilitarse la presentación en el navegador de imágenes y java/javascript y navegar la web de forma totalmente 'oculta' (excepto para los ficheros de registro).

Sepa que estos tipos de contadores y web remotas de uso no son tan precisas como se puede pensar.

Conclusión.-

Ahora debe ser obvio que sólo se pueden determinar con precisión ciertos valores del fichero de registro del servidor.

Hay valores totalmente precisos, y otros imprecisos en los que se puede confiar más o menos dependiendo de las suposiciones que se hayan hecho.

¿Quiere saber cuantas peticiones han dado como resultado un error '404 - No Encontrado'. Vaya y cuéntelas, y confíe totalmente en el número que obtenga.

¿Quiere saber el número de usuarios que han visitado su web? Buena suerte con ello. A no ser que abandone los ficheros de registro, será un valor impreciso el que obtenga. Pero debe tener una idea de lo que es y no posible, así que, cuando vea los registros de uso sabrá determinar los que los números significan y cuanto confiar en ellos.

También sabrá ahora que mucho depende de como esté configurado el programa de análisis, y que una configuración mala da resultados malos.

Considere el ejemplo de 'paginas'. Si su programa de análisis piensa que sólo las URLs con extensión .htm o .html es una página, y su web está formada sólo por páginas .php, el número de páginas vistas será totalmente inválido, no porque el programa sea malo sino porque alguien le dio información errónea en que basar sus cálculos.

Recuerde que el conocimiento es poder, así que ahora tiene el poder de hacer las preguntas adecuadas y obtener los resultados precisos.

La próxima vez que mire el informe de análisis del servidor lo verá desde una perspectiva distinta dados sus nuevos conocimientos.

 

Glosario de Términos.-

Cabeceras principales

Hits representa el número total de peticiones hechas al servidor en un periodo de tiempo (mes, día, hora, etc.)

Files representa el número total de peticiones (hits) que resulta realmente en algo enviado por el servidor. No por todas las peticiones se envían datos, como las peticiones '404 - No Encontrado', o las peticiones de páginas que están en la memoria temporal del PC.

Truco: Comparando la diferencia entre 'hits' y 'files', puede obtener una indicación bruta de visitantes que repiten, ya que cuanto mayor es la diferencia entre los dos, mayor es el número de usuarios solicitando páginas que ya están en la memoria temporal de su PC (ya las ha visto).

Sites es el número de direcciones únicas IP que realizan peticiones al servidor. Se debe tener cuidado al usar este valor con otro fin. Muchos visitantes pueden parecer provenir de un sólo 'site', pero también pueden aparecer como provenientes de diferentes direcciones IP, así que debe considerarse una estimación del número de visitantes a su web.

Visits aparecen cuando una máquina remota solicita una página de su web por vez primera. Mientras sigue haciendo peticiones dentro de un periodo de temporización, todas estas peticiones se consideran parte de la misma 'Visit'.

Si la máquina hace una petición al servidor, y el periodo de tiempo desde la última que hizo es mayor que el periodo de temporización (normalmente 30 minutos) se considera una nueva 'Visit'. Puesto que sólo las peticiones de páginas generan 'Visits', las webs que enlazan con gráficos u otras URls no de páginas, no son contabilizadas, reduciéndose el número de falsas 'Visits'.

Pages son las URLs en que se considera se solicita toda la página y no todos los elementos individuales (tales como gráficos y audio clips) que la componen.

Cierta personas llaman a este valor 'page views' o 'page impressions', y es por defecto cualquier URL que tiene por extensión .htm, .html, .php, .cgi, etc.

Tráfico.- Un KByte (1 KB) son 1024 bytes. Se usa para indicar la cantidad de datos (tráfico) que se han transferido entre el servidor y la máquina remota.

 

Definiciones comunes

Un Site es una máquina remota que hace peticiones a su servidor, y se basa en la dirección IP de la máquina remota/Hostname.

URL (Uniform Resource Locator). Todas las peticiones que se hacen a un servidor web son para pedir 'algo'.

La URL es ese 'algo', y representa un objeto en el servidor web accesible al usuario remoto, o produce un error (p.e. 404 - No Encontrado). Las URLs pueden ser de cualquier tipo (HTML, Audio, Gráfico, etc.)

Referrers son aquellas URLs que dirigen un usuario a su web o hacen que el navegador solicite algo al servidor.

La mayor parte de peticiones se realizan desde sus propias URLs, ya que la mayoría de las páginas HTML tienen enlaces a otros objetos tal como ficheros gráficos.

Si una de sus páginas HTML contiene enlaces a 10 imágenes, entonces cada petición de la página HTML producirá 10 'hits' más con el 'referrer' siendo la URL de su propia página HTML.

Search Strings (palabras de búsqueda) se obtienen examinando las palabras del referente (referrer) y buscando los modelos conocidos de varios buscadores.

Las máquinas de búsqueda y modelos a buscar pueden ser especificados por el usuario en un fichero de configuración, pero por defecto se analizan los principales buscadores.

Nota: Sólo disponible si esta información está en los ficheros de registro.

User Agents es un nombre que se refiere al navegador que emplea el usuario (Internet Explorer, Mozilla Firefox, Chrome, Opera, Safari, Konqueror, etc.).

Cada navegador se registra de forma única en el servidor. Tenga en cuenta, sin embargo, que muchos navegadores permiten que el usuario cambie su nombre, y puede encontrar nombres falsos en el informe.

Nota: Sólo disponible si esta información está en los ficheros de registro.

Entry/Exit Pages son aquellas páginas que se solicitan la primera en una 'Visit' (Entry), y la última (Exit).

Estas páginas se calculan usando la lógica de 'Visits' indicada antes.

Cuando se contabiliza una nueva 'Visit', la página que solicita se contabiliza como 'Entry page', y cualquiera que sea la última URL pedida se cuenta como una 'Exit page'.

Countries (países) se determinan en base al dominio de nivel superior (p.e. .es, .fr, .it, etc.) del 'site' que hace la petición.

Esto es, sin embargo, cuestionable, ya que ahora no existe un fuerte control de dominios como había en el pasado. Un dominio .COM puede residir en USA, o en cualquier otro lugar del mundo. Un dominio .IL puede estar realmente en Israel, sin embargo, puede también estar localizado en USA, o en cualquier otro lugar del mundo. Los dominios más frecuentemente encontrados son: .COM (Comercial USA), .NET (Servicios de Internet), .ORG (Organizaciones sin animo de lucro) y .EDU (Instituciones de Educación).

Se puede mostrar un alto porcentaje como Unresolved/Unknown (No Resuelto/Desconocido), ya que un gran número de conexiones de acceso a Internet no dan como resultado un nombre si no simplemente una dirección IP.

Response Codes (códigos de respuesta) son los definidos como parte del protocolo HTTP. Estos códigos los genera el servidor web e indican el estado en que se finaliza cualquier petición.

VOLVER

  • 3 Utenti hanno trovato utile questa risposta
Hai trovato utile questa risposta?

Articoli Correlati

Sobre Webalizer

Webalizer es una aplicación que produce páginas web de análisis, desde los...

Powered by WHMCompleteSolution