Logging Centralizado

Parte 2.1: Configurar el Logback

Parte 2: El Publicador de Eventos

Canalizacíon de eventos hacia el RabbitMQ

En esta parte de la historia, lo que haremos es que el Logback derivé los mensajes de eventos de logging hacia el exchange “logger.exchange”, de donde luego será redireccionado a la cola correspondiente se acuerdo a la clave de ruteo que le pasemos como parámetro.

Adición de dependencias al proyecto

Debemos agregar una dependencia clave al proyecto que será la encargada de gestionar la comunicación con el RabbitMQ y envíar las cadenas de eventos al mismo, para ello, localizamos el archivo pom.xml y agregamos en el bloque de <dependencies> la siguiente:

<!-- Integracion AMQP -->
<dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-amqp</artifactId>
</dependency>

1. Actualizamos el proyecto Maven:

2. Seleccionamos la carpeta del mismo y hacemos click derecho encima de la misma.

3. En el ítem de menú desplegado seleccionamos [Maven] > [Update project…]

4. Marcamos nuestro proyecto y click en el botón [OK] y esperamos a que el proceso de actualización de dependencias finalice.

Adición del “appender” al logback.xml

Cuando se hayan actualizado las dependencias del proyecto, procedemos a agregar el “appender” al archivo configuración del Logback para que envíe los mensajes de eventos al RabbitMQ.

Procedemos de la siguiente manera:

Abrimos el archivo logback.xml y a continuación del elemento <configuration scan="true"> agregamos la línea siguiente:

<property resource="application.properties" />

Con este paso estamos indicando que se ben buscar los parámetros de configuración en el archivo application.properties para completar los valores de la configuración.

Entre la última etiqueta </appender> y antes de <root level="INFO">, agregamos:

<appender name="AMQP"class="org.springframework.amqp.rabbit.logback.AmqpAppender">
	<layout>
		<encoder>
			<pattern>${logger.application.version} > ${logger.patron.archivo}</pattern>
		</encoder>
	</layout>
	<!-- RabbitMQ connection -->
	<host>${logger.rabbitmq.host}</host>
	<port>${logger.rabbitmq.port}</port>
	<username>${logger.rabbitmq.username}</username>
	<password>${logger.rabbitmq.password}</password>
	
	<applicationId>{logger.application.id}</applicationId>
	<virtualHost>${logger.rabbitmq.virtual-host}</virtualHost>

	<routingKeyPattern>${logger.rabbitmq.routingKeyPattern}
	</routingKeyPattern>
	<declareExchange>${logger.rabbitmq.declareExchange}</declareExchange>
	<exchangeType>${logger.rabbitmq.exchangeType}</exchangeType>
	<exchangeName>${logger.rabbitmq.exchangeName}</exchangeName>
	<generateId>true</generateId>
	<charset>UTF-8</charset>
	<durable>true</durable>
	<deliveryMode>PERSISTENT</deliveryMode>
</appender>

Está demás decir que después de cada cambio realizado a un archivo debemos guardarlos.

luego, dentro del elemento <root level="INFO"> agregamos la referencia al nuevo “appender”:

<appender-ref ref="AMQP" />

con lo que debería quedar así:

<root level="INFO">
	<appender-ref ref="FILE" />
	<appender-ref ref="CONSOLE" />
	<appender-ref ref="AMQP" />
</root>

En esta última parte, le decimos al Logback que lo tenga en cuenta para informar los eventos que ocurren durante la ejecución del programa.

Probamos los cambios hechos

Ahora toca probar lo hecho, ejecutamos nuestro programa (Click derecho sobre la carpeta raíz del proyecto, [Run As] > [Spring Boot App]).

Deberíamos estar viendo la salida en consola normalmente, y si nos fijamos en la cola de destino de los mensajes (“logger_input_queue”) en el RabbitMQ, deberíamos ver que la cantidad de mensajes listos se ha disparado hacia arriba.

Si listamos alguno de los mensajes, tendríamos que ver que tienen exactamente el mismo formato y contenido que lo que se escribe en la consola y en el archivo current.out, puesto que hemos especificado que utilizarán el mismo patrón (${logger.application.version} > ${logger.patron.archivo}).

Obs.: Sí surgen inconvenientes con la conexión entre el “appender AMQP” y el RabbitMQ, se mostrá la notificación correspondiente tanto en la consola como en el archivo current.out, pero no impedirá que el programa se ejecute con normalidad.

Si nos fijamos, las cadenas de mensajes de eventos llegan como texto plano y para poder procesarlas y persistirlas en la base de datos, necesitamos que cumplan algunas condiciones, como por ejemplo, una notación específica para poder parsearlas. Aqquí podríamos utilizar la vieja confiable XML o el siempre ligero JSON.

Para este ejemplo utilizaremos JSON debido a que se puede persistir como tal directamente en la base de datos MongoDB.

---

En el siguiente paso, haremos las configuraciones necesarias al appender AMQP para que genere los mensajes de e

Parte 2.2: Logback a JSON