Almacenamiento de líneas de log en una Base de Datos Sub-módulo Descripción

Definición de Categorías Una categoría enmascara a directorios y archivos reales. La idea es seleccionar dichas categorías para seleccionar archivos para su posterior análisis.

Estructura interna del Módulo 1

Selección de categorías Según las categorías seleccionadas, se revisa el log del servidor y las líneas que tengan referencias a archivos de dichas categorías se almacenan para su posterior análisis. A continuación se muestran los diagramas de flujo preliminares para cada sub- módulo:

Selección de Páginas

Páginas en Categ oría0 1

Páginas en C ategoría02 Páginas en Categoría03 Páginas en C ategoríaNN Seleccionar selec ciona_pags.pl D B (PAG)

Almacena las páginas selecc ionadas en el form ulario.

Sólo es tas páginas se tom arán en c uenta para las estadís tic as .

lee_log.pl DB (PAG) Log H ttp DB (L OG)

Lee c ontinuam ente el arch iv o 'Log Http' y guarda en la tabla LOG sólo las líneas que contengan

a las pá ginas esp ec ificadas en la tabla PAG.

Diagrama de flujo para la selección de categorías.

Se analizan los requerimientos de datos para crear un modelo que permita representar las necesidades de información del módulo 1.

• Cada línea de log está asociada a una página del sitio. • Cada página de interés debe estar en una categoría.

• Sólo las líneas de log de las páginas de interés se deben almacenar en la base de datos.

Con lo anterior, se llegó al siguiente modelo de datos:

Categorías CATEG_ID Páginas PAG_ID Log LOG_ID

Modelo de datos para la recopilación de las líneas de log.

Para la implementación de los modelos de datos de todo el sistema se optó por MySQL, ya que es un administrador de bases de datos robusto y veloz. Además, posee extensiones al SQL estándar que permiten realizar consultas estadísticas en forma rápida y confiable, lo que redunda en una menor cantidad de código asociado a la aplicación

Se establecen los campos de las tablas que servirán para el prototipo (Es probable que la versión final tenga campos muy parecidos), los que se resumen a continuación:

Tabla Campos Observación

Tabla de Categorías

CATEG_ID Clave Primaria

CATEG_NOMBRE

PAG Tabla de URLs

PAG_ID Clave Primaria

PAG_CATEG_ID Clave Foránea

LOG Tabla de Log

LOG_IP LOG_PERFIL LOG_FECHA LOG_HORA

LOG_PAG_ID Clave Foránea

CATEG

PAG_NOMBRE

Con el fin de tener datos para realizar las estadísticas, se crean registros aleatorios en la tabla LOG. Además, para crear las rutinas de estadísticas, el campo LOG_PERFIL se hace variar entre sus tres posibles valores (profesor, alumno, externo).

Además, se realiza un estudio de los tipos de gráficos que se esperan. Básicamente se requieren dos tipos, uno denominado “perfil” y otro “tiempo”. El primero muestra en un solo gráfico el promedio de peticiones por la unidad de tiempo que se ha seleccionada. Por ejemplo, se la unidad de tiempo es hora, el gráfico muestra la cantidad promedio de peticiones por hora. La idea es conocer cuál es la hora con más carga. (La unidad de tiempo también puede ser Día de la Semana o Mes).

Ejemplo Gráfico “Tiempo”

Ejemplo Gráfico “Perfil”

Para la creación de estos gráficos se utilizará el módulo PERL Chart, el que permite generar archivos PNG, JPEG y GIF.

Internamente, se realiza una consulta SQL para conocer la cantidad de peticiones en un determinado periodo de tiempo. Por ejemplo, para conocer el promedio de peticiones que se han hecho los días lunes, se ejecuta la siguiente consulta:

CREATE TABLE test TYPE=HEAP SELECT LOG_FECHA, COUNT(*) AS cnt FROM LOG WHERE GROUP BY

El módulo de Administración de Usuarios permite registrar usuarios y asignarles su respectivo perfil. Como resultado, se logra que para navegar por el sitio el usuario debe haberse registrado con anterioridad. Esta idea se ilustra en la siguiente figura:

WEEKDAY(LOG_FECHA)=0 LOG_FECHA;

SELECT AVG(cnt) FROM test; DROP TABLE test;

Esta consulta crea una tabla temporal en base a otra. Primero se seleccionan y cuentan todos los registros cuya fecha sea un día Lunes (WEEKDAY (LOG_FECHA)=0). Este query arroja un resultado como el siguiente:

LOG_FECHA | cnt ---+--- 2002-01-07| 102 2002-01-14| 201 2002-01-21| 189 2002-01-28| 203 2002-02-04| 34 etc....

Luego, la operación SELECT AVG (cnt) FROM test; devuelve el promedio de la columna cnt . Este número es el que se grafica finalmente.

Link entrada al sitio juanito ****** *** Password Username CAN CEL OK Bienv enido Juanito al web de ... Regístrate Aquí Formulario de registro de usuarios C on tinuar >>

Diagrama para la entrada al sitio web.

Cuando el usuario ingresa por primera vez al sitio, debe llenar el Formulario de Registro de Usuarios, que será explicado más adelante. Una vez registrado en el sistema, deberá ingresar su nombre de usuario y su contraseña para poder navegar por el sitio. Desde este momento, todos los enlaces seguidos por este usuario quedarán guardados en el log del servidor web, y como ya se explicó, sólo los links que estén bajo una categoría se almacenarán en la base de datos para su posterior análisis.

Del diagrama mostrado, se deduce que el formulario de registro de usuarios debe ser capaz de generar el archivo .htpasswd, para que el servidor web sea capaz de reconocer al usuario que intenta navegar. Para este fin, se utilizará el comando crypt de PERL, el cual permite encriptar bajo MD5, técnica que es utilizada por el comando htpasswd.

Para poder almacenar los datos de los usuarios se propone el siguiente modelo de datos:

ALUMNO NIVEL LOCAL PROFESOR RAMO EXTERNO

Modelo de datos para los usuarios del sistema.

EL modelo propuesto se construyó sobre la base de los siguientes requisitos:

• Un alumno puede pertenecer sólo a un NIVEL de aprendizaje (8º Básico, 1º

Medio, etc) y un NIVEL puede tener muchos alumnos.

• Todo usuario que sea EXTERNO al proyecto no está asociado a un

establecimiento educacional.

• Existen tres tablas principales, asociadas a cada perfil de usuario: ALUMNO,

PROFESOR, EXTERNO.

• Un profesor puede tener asociado un solo RAMO y cada ramo puede ser dictado

por muchos profesores.

• Un alumno pertenece a un establecimiento o LOCAL y cada establecimiento

puede tener muchos alumnos.

• Un profesor pertenece a un solo establecimiento o LOCAL; y a su vez, un

establecimiento puede tener muchos profesores.

El detalle de cada tabla se muestra en la sección 2.4 “Detalle de las tablas del modelo de datos propuesto”.

usuario en la base de datos, modifica el archivo .htpasswd correspondiente y devuelve al usuario a la página de inicio.

Registro de Usuarios reg_step_1.pl Perfil Continuar >> reg_step_2.pl D B Lee() Formulario respectiv o Nombre Continuar >> . . . reg_step_3.pl Escribe() Escribe() .htpass Print() Print() Submit() Submit() Link()

Perfeccionamiento del Módulo 2 en base al Módulo 3

Una vez que se tiene funcionado el módulo 3, se continúa el diseño del “Administrador de Usuarios”, el que permite eliminar y corregir los datos usuarios, así como comprobarlos (por ejemplo, para que un alumno realmente exista). Se reutilizan los scripts reg_step_2.pl, y reg_step_3.pl del módulo “Registro de Usuarios”. Se agrega el script user_admin.pl, el que se encarga de mostrar un resumen de los usuarios del sistema, así como generar los links para permitir la posterior modificación de datos por cada usuario o su eliminación del sistema.

Lista de Usuarios us er_adm in.pl Por Perfil Eliminar reg_step_2.pl D B Lee() Formulario respectiv o Nombre Continuar >> . . . reg_step_3.pl Escribe() Escribe() .htpassw Print() Print() Submit() Submit()

Link() Eliminar User

usuario01 usuarioNN

Ver

Submit()

Link()

Unión de Módulos

Se unen todos los módulos para realizar el primer prototipo del sistema. Se realizan una serie de modificaciones que tienden a un mejor desempeño del sistema:

• Agregar módulo mod_perl a Apache:

Este módulo permite a los scripts basados en PERL ocupar un intérprete optimizado para Apache. Entre sus cualidades resalta que siempre esta levantado, lo que significa un ahorro en tiempo y cpu a la hora de ejecutar scripts CGI. Funciona bien en una máquina con por lo menos 64[Mb] en RAM.

• Actualizar los módulos DBI (Data Base Interface) de PERL para MySQL. Estos módulos permiten acceder de manera transparente a motores de base de datos, tal como lo hace ODBC en Win32. Las últimas versiones de estos paquetes tiene más capacidades para trabajar con el módulo mod_perl (Por ejemplo, manejar conexiones persistentes hacia una base de datos entre distintas llamadas de un mismo script.)

Además de lo anterior, se afinan los detalles por el lado del cliente: • Validación de formularios con JavaScripts.