En esta página se va a mostrar los campos que se añaden a nuestros logs en LAGAR cuando se ha configurado el rastreo distribuido con Sleuth, así como un ejemplo práctico de petición y visualización de logs.

Introducción

Como se mencionaba en la página de configuración, al trabajar con Sleuth se crean dos campos en nuestros logs:

• traceId - Identificador único de la traza/petición a través de todos las APIs.
• spanId - Identificador de los logs en un "salto" de la traza, es decir, identificador de los logs de una misma aplicación.

Se puede ver un ejemplo de cómo funcionan los campos traceId y spanId en la siguiente imagen:

• En la primera petición a Service 1, cuando no existen traceId ni spanId, Sleuth los crea con valores traceId=X y spanId=A (inicialmente, X = A).
• Al realizar una petición de Service 1 a Service 2, Sleuth asigna un nuevo valor de SpanId = B para el servicio 2. Con lo que los logs de Service 2 tendrán traceId=X y spanId = B.
• Opcionalmente, se pueden crear spans por programación para agrupar los logs de una determinada funcionalidad, esto se refleja en la imagen como SpanID = C.
• Siguiendo la traza de peticiones y respuestas a/desde Service 3 y Service 4, se observa como traceId se propaga entre servicios, con lo que siempre traceId=X , y spanId va cambiando según el servicio.

De esta forma podemos tracear una misma petición entre todos los microservicios que se van invocando desde el origen.

LAGAR

En LAGAR, los logs de nuestra aplicación ahora tendrán estos dos campos:

Ejemplo de Rastreo Distribuido

1. Pongamos que nos logueamos en https://micampus.um.es y accedemos a "Mis Certificados" - "Nuevo certificado".
   
   
   
   
2. Vamos a https://lagar.um.es para ver los logs que se han generado en la aplicación aulavirtual/mis-certificados-api:
   
   
   
   
   
   Como se puede observar, en esta primera petición se han creado los campos log_processed.mdc.traceId y log_processed.mdc.spanId con el mismo valor: 0bc3a81f8efdcac5
   
   
3. Si tenemos alguna incidencia, o creemos que hay algún error en alguno de los servicios que se invoca, podemos decirle a los responsables de esa aplicación (o a MNCS):
   
   - "Oye! mírame en el entorno X los logs con la traza log_processed.mdc.traceId=0bc3a81f8efdcac5, deben pertenecer al usuario log_processed.mdc.UMU-Token-Subject=ramon.ginel@ticarum.es "
   
   Por ejemplo, vamos a ver los logs de rrhh/serviciosrrhh-api:
   
   
   
   
   En los logs de rrhh/serviciosrrhh-api, podemos ver que para nuestra traza 0bc3a81f8efdcac5, tenemos dos bloques de logs con spanId diferentes.
   
   Esto es debido a que desde aulavirtual/mis-certificados-api, a partir de la misma request/traceId de origen, se han realizado dos llamadas a serviciosrrhh-api:
   
   - Una llamada a  /rrhh/serviciosrrhh-api/private/v1/afiliacion/ (a través de la librería fundewebjs-serviciosrrhh-client), que genera el spanId = 06845fe6cda1109e.
   - Una llamada a /rrhh/serviciosrrhh-api/private/v1/certificados/consultables, que genera el spanId = 6cbc8d8d68cc721e.
   
   
4. Continuar el proceso con el resto de aplicaciones invocadas en nuestro servicio hasta solucionar la circunstancia que motivó la búsqueda.
   De la misma forma que en el ejemplo de la introducción, el responsable de la aplicación rrhh/serviciosrrhh-api/ podría usar nuestra traza 0bc3a81f8efdcac5, 
   para preguntar por los logs de otros servicios a los que invocara (en caso de que lo haga) a raíz de la petición de origen.
   
   

Artículos Relacionados

Aquí aparecen artículos relacionados sobre la base de las etiquetas que usted seleccione. Haga clic para editar la macro y añadir o modificar las etiquetas.