Trazabilidad en las peticiones (II)

Relacionado con el post anterior, varias observaciones que desarrollaré a lo largo del post:

  1. No reinventar la rueda si todos nuestros servicios son REST y desarrollados por nosotros con Spring.
  2. Obtener la información identificativa de cada petición para poder realizar búsquedas.
  3. Repositorio único de trazas.

No reinventar la rueda si todos nuestros servicios son REST y desarrollados por nosotros con Spring.

Este punto choca un poco con lo que comentaba en el anterior post en cuanto a que pongamos un identificador único en el objeto de la petición pero, en el caso en que en nuestra arquitectura solo vayamos a tener servicios REST desarrollados por nosotros en Java/Spring (podríamos tener servicios REST con otros lenguajes / herramientas), mi recomendación es no reinventar la rueda y centrarnos en nuestra lógica, dejando a Spring Cloud Sleuth esa tarea. Mediante esta herramienta, automáticamente se genera un identificador de petición que se transfiere entre las peticiones mediante cabecera HTTP, con lo que podemos generar una traza con esta información con el patrón siguiente:

<PatternLayout pattern="%d{yyyy/MM/dd HH:mm:ss.SSS} %-5p [%-15c{1}] [TraceId]:%X{X-B3-TraceId}|[SpanId]:%X{X-B3-SpanId}|%X{TRACKING}|%m%n" />

Obtener la información identificativa de cada petición para poder realizar búsquedas

Asimismo, no sirve de nada el mantener un identificador único en todas las peticiones relacionadas si no tenemos algo de información sobre la que buscar. En este caso, me refiero a que, cada operación/método/verbo (cada uno que se quede con la nomenclatura que le guste más 🙂 ), debe mostrar los campos más identificativos de la misma, siempre y cuando éstos no resulten ser información sensible (ejemplo: no podemos sacar a traza el PAN completo de una tarjeta de crédito/débito, pero sí podríamos sacarlo enmascarado). Unos ejemplos de información significativa podrían ser:

  • Si es una compra, identificador del usuario que hace la compra y el identificador del producto, entendiendo como identificador del usuario al teléfono/MSISDN o dirección de correo electrónico.
  • Si es un envío de dinero de un usuario a otro, identificador del usuario origen, identificador del usuario destino y la cantidad de dinero enviada.
  • Si es una recarga o retirada, identificador del usuario y cantidad recargada/retirada.

De este modo, podemos hacer una búsqueda rápida por el identificador del usuario y ahí obtener el identificador único de las peticiones y ya poder seguir todas las trazas.

En cuanto a cómo escribir esta información significativa, mi recomendación es incluirla en el campo TRACKING que vimos en el anterior post del siguiente modo:

Repositorio único de trazas

Y por último, prácticamente en todos los proyectos en los que he estado (salvo en el último 🙂 ), para cada servicio teníamos que ir a la/s máquina/s donde estuviera desplegado para buscar en las trazas. Esto puede ser un inconveniente en una arquitectura orientada a microservicios donde cada máquina/contenedor contiene uno y solo un servicio (pudiendo éste estar desplegado a su vez en múltiples máquinas/contenedores).

Es por ello que recomiendo la utilización de un repositorio único. Este repositorio podría ser:

Como ventaja de los dos últimos es que son SaaS, por lo que no tenemos que preocuparnos de instalar/configurar/mantener un software que haga de repositorio así como mantener la/s máquina/s que alojen el repositorio.

Advertisements