7.2. Log de Eventos

Funcionamiento del log y los diferentes usos que se le puede dar.

Ponemos especial énfasis en su utilización como método de Debug del código en desarrollo.

7.2.1. Introducción

El objetivo de este módulo es registrar ciertos eventos, acciones, movimientos, operaciones, ... para poder averiguar lo que está haciendo la aplicación. Por defecto éstos se registran en una tabla de sistema. Esta tabla se llama tcmn_errlog y hay que crearla previamente a usarla. Más adelante se pueden definir otros métodos como podría ser el correo, ficheros, ... o mejor Pear::Log. En los ficheros de configuración (propiedad DSNZone/dbDSN con id 'gvh_dsn_log') se puede definir una fuente de datos válida para añadir registros a la tabla.

Esto habitualmente lo usaremos para detectar errores de una aplicación en explotación o para poder realizar una traza detallada de una acción en desarrollo.

Hemos realizado una clasificación de los eventos que se registran en la tabla dependiendo de su gravedad:

Tabla 7.2. Tabla de clasificación de los eventos

tipo descripción
PANIC Errores graves, la aplicación no deberia seguir ejecutándose
ERROR Errores
WARNING Errores menores
NOTICE Información a nivel de Auditoría
DEBUG_USER Mensajes de traza (debug) del programador
DEBUG_IGEP Mensajes de traza (debug) de gvHidra

Por defecto se registran todos los eventos de los dos primeros tipos. Si queremos cambiarlo, podemos hacerlo indicando a la aplicación el nivel de sensibilidad. Es decir, indicar que tipo de eventos se tienen que registrar. Para ello se puede escoger de los siguientes valores:

  • LOG_NONE : No registra nada.

  • LOG_ERRORS: Registra únicamente ERROR y PANIC. (valor por defecto)

  • LOG_AUDIT: Registra todos los anteriores más WARNING y NOTICE.

  • LOG_ALL: Registra todas las acciones.

El valor lo podemos poner de forma estática en el atributo logSettings del fichero gvHidraConfig.inc.xml de la aplicación o de forma dinámica con el método ConfigFramework->setLogStatus (ver configuración).

Hay que tener precaución con esta variable, para que en explotación no se genere más información que la necesaria. Normalmente le asignaremos un valor u otro en función de si estamos en producción o no.

7.2.2. Crear eventos en el log

Un programador puede crear eventos en el log simplemente llamando al método setDebug de la clase IgepDebug.

Ejemplo:

function creacionInformes(){
  IgepDebug::setDebug(DEBUG_USER,'Pasamos a crear los informes');
  ....
}

En este ejemplo, y dependiendo del valor del atributo logSettings, el programador inserta una entrada en el log que indica que se ha pasado por el método creacionInformes.

El programador podrá hacer uso del log indicando la gravedad del mensaje que desee atendiendo a la clasificación. Se recomienda hacer uso de DEBUG_USER si se esta realizando un debug en desarrollo y WARNING o NOTICE si se quiere realizar auditoría de lo que realicen los usuarios en explotación.

7.2.3. Consulta del Log

Para ver los eventos generados, se ha creado una consola que permite consultar lo que se inserta en la tabla de sistema. Se recomienda a los programadores que hagan uso de ella añadiendo en el fichero menuHerramientas.xml la siguiente linea:

<opcion titulo="Log Aplicación" descripcion="Log Aplicación" urlAbs="igep/_debugger.php" imagen="menu/51.gif"/>

Hay que tener precaución en este último punto para que esta opción no esté accesible para los usuarios finales.