Database Logging

Cuando realizamos una instalación "Estándar" de Drupal 8, se instala el módulo "Database Logging" que permite que se guarden en la base de datos los registros de eventos del sistema. Esta información puede servirnos posteriormente para saber lo que está ocurriendo en nuestro sitio web, y en muchos casos solucionar los problemas que se presentan.

Los mensajes que se guardan están clasificados, por tipo y por nivel de severidad.

Los tipos son diversos, ya que los mensajes pueden clasificarse de diversa manera. Los nuevos módulos instalados pueden clasificar sus mensajes con nuevos tipos. Sin embargo, en la interfaz de usuario de Drupal donde se ven los mensajes recientes de registros solo se mostrarán como filtros los tipos de los mensajes que se encuentran actualmente registrados. Si se borran todos los mensajes, la casilla para seleccionar los tipos queda vacía.

Ejemplos de tipos son:

• Cron
• Sistema
• Usuario
• Php
• Webform

 

Y los niveles de severidad son los siguientes:

• Emergencia
• Alerta
• Crítico
• Error
• Advertencia
• Aviso
• Información
• Depuración

 

Los usuarios con un rol que tenga asignado el permiso "View site reports" pueden ver el registro de eventos, ingresando a Informes > Mensajes recientes de registro (o la ruta /admin/reports/dblog). Es conveniente dar acceso a los roles con funciones de administrador para que puedan hacer seguimiento a la actividad del sitio. Y también a las personas que suelan solucionar errores, ya que a través de este registro pueden ir depurando los problemas que se presentan.

 

 

Consultar el registro cuando no se puede acceder al sitio

Una situación que suele ocurrir es que no se puede acceder al sitio web. Y precisamente en esos momentos es más urgente tener información de lo que está sucediendo a través del registro de errores. Hay dos formas de hacerlo:

• Usando drush. Para ello podemos ejecutar el comando "drush wd-show". También podríamos usar "drush wd-show --tail" que nos puede ir mostrando los errores de manera continua si es que se presentan nuevos, hasta que sea interrumpido. Para saber las opciones de "drush wd-show" podemos consultar la ayuda con "drush help wd-show". A continuación mostramos algunas capturas de pantalla.

 

 

 

• Directamente en la base de datos. Es una opción que tiene más dificultades, ya que el mensaje de error tiene una estructura que usualmente contiene "variables" que se llenan con información que está en el campo variables. Sin embargo, a veces es la única alternativa que tenemos para ver los errores. En el siguiente apartado mostramos más detalles de como se almacena el registro de eventos en la base de datos.

 

Registro de eventos en la base de datos

Los eventos se almacenan en la tabla watchdog, que tiene la siguiente estructura.

 

Podemos observar los siguientes campos:

• wid, es el identificador de cada registro.
• uid, el id del usuario que estaba utilizando el sistema cuando se generó el registro. Es 0 si el visitante no estaba autenticado.
• type, el tipo de registro.
• message, la descripción del evento que ocurrió. Esta descripción contiene variables. Un ejemplo sería este mensaje "%module module installed.",  dónde "%module" se debe reemplazar por el nombre del módulo que fue instalado.
• variables, es el valor de las variables que aparecen en la descripción del evento (campo message). Es de tipo longblob, por lo que algunas herramientas de consulta pueden no mostrarlas.
• severity, el nivel de gravedad del mensaje.
• link
• location, es la ruta que se estaba visitando cuando ocurrió el evento.
• referer, como es que se llegó a la página que produjo el evento, cuando proviene desde un enlace o un formulario enviado por ejemplo.
• hostname, desde donde se hizo la petición, por ejemplo la ip desde donde se accedió a la página web.
• timestamp, el momento en que ocurrió el evento, en formato timestamp.
   

Como se configura este módulo

Para configurar las opciones de registro de sistema nos dirigimos a Configuration > Development > Logging and Errors (/admin/config/development/logging).

En esta pantalla podremos configurar de que manera se van a mostrar los mensajes (o no se van a mostrar) en la pantalla donde se produce el error. Los mensajes solo deberían mostrarse durante la fase de desarrollo, y no en el sitio en vivo, porque puede revelar más información de la necesaria a un visitante. También se configura la cantidad de mensajes que se van a mantener en el registro, luego de lo cual se va a ir borrando usando una tarea programada del cron. Se recomienda colocar un valor apropiado dependiendo de la capacidad de los servidores, y la actividad del sitio.
 

A tomar en cuenta

• Se  recomienda a los administradores del sitio revisar regularmente este registro de eventos para asegurarse que todo está funcionando correctamente, o existe algún mensaje llamativo a algún evento que se muestre con regular frecuencia.
• Cuando se encuentran errores, así no afecten el normal funcionamiento del sitio, repararlos, ya que escribir sobre esta tabla puede representar un tiempo adicional. Esto es especialmente importante cuando es un error que se está registrando continuamente como mensaje, llegando incluso a comprometer la velocidad del sitio web.
• Configurar apropiadamente la cantidad de registros, para que no crezca demasiado, dependiendo del tamaño del sitio web, y de las capacidades del servidor.
• Este registro está entre los primeros datos que revisamos cuando tenemos alguna falla en nuestro sitio web.
• Dado que a pesar de que todo esté correctamente configurado, el grabado de registros en la base de datos siempre representa una carga para el rendimiento, es posible configurar otras opciones para almacenar estos logs. Entre ellos se encuentra grabarlo en archivos usando el módulo syslog, usar algún módulo contribuido para grabarlo en memcache.