Registros y trazabilidad de extremo a extremo

Para seguir una petición a través de varios sistemas se le pone un identificador de correlación en la entrada, y cada salto lo conserva y lo escribe en su registro. Es habitual usar una cabecera como X-Request-ID o el estándar de contexto de traza del W3C, traceparent. Sin él, hay que casar peticiones por hora y dirección, y con varios clientes detrás de una misma dirección eso no es fiable.

Lo anotado también tiene reglas: ni credenciales, ni tokens, ni números de tarjeta en claro en un registro. Un registro se copia, se envía a otros sistemas y lo lee mucha gente.

La correlación revela huecos. Una petición que crea algo en la aplicación debería aparecer en el proxy, en la pasarela y en la aplicación. Si falta en uno, hay tres explicaciones posibles: el registro de ese salto estaba caído, la cabecera de correlación se perdió o la petición llegó a la aplicación por otro camino. Las tres merecen ser investigadas, y ninguna se concluye con la sola ausencia.

Compara registro_proxy, registro_pasarela y registro_aplicacion: una petición que creó una guía.

Una ruta con un token en la dirección (?token=...) lo deja en el registro del proxy, en el de la pasarela, en el historial del navegador y en cualquier sistema que reciba esas líneas. Las credenciales viajan en cabeceras, no en la dirección web, y el registro debe enmascararlas o descartarlas.

Mira la columna ruta de registro_proxy.

Unir registros por hora solo funciona si los relojes coinciden. Cinco minutos de diferencia bastan para que una secuencia de eventos parezca en otro orden, y para que la fila de un sistema se asocie a otra petición. Por eso los sistemas de un mismo recorrido deben usar un servidor de hora común.

La tabla relojes da la hora que marca cada sistema en un mismo instante y si se sincroniza.

Los registros de la pasarela incluyen las peticiones que no llegaron a la aplicación: las denegadas. Contarlas por cliente es una pregunta de rutina en una investigación: cuántas veces falló un cliente antes de que algo funcionara y por qué.

Consulta registro_pasarela y cuenta las decisiones denegada de un cliente concreto.