Traducción de
docs/en/runtime/tracing.md, que es el original. Si discrepan, manda el inglés.
Cada llamada a la pasarela crea una traza durable y una sucesión de eventos que
sólo se añaden: request.received, contract.validated, scenario.matched,
response.sent, más los eventos de detalle de idempotencia, estado y cola que
vengan después. Los cuerpos pasan por el tachado de secretos antes de
persistirse.
#Leer una
La consola las muestra por aplicación, en Trazas: el listado se pagina, se
ordena y se filtra en el servidor como todos los demás, y correlationId es la
columna que importa — es lo que quien llama manda en X-Correlation-Id para atar
una traza de aquí con una línea de sus propios registros.
Abrir una enseña sus momentos en orden, con los milisegundos entre ellos y cada cuerpo plegado:
request.received +0 ms cuerpo · ruta · método · cabeceras
application.resolved +2 ms proveedor · applicationId
contract.validated +3 ms operación
scenario.matched +3 ms escenario · origen · desenlace
response.sent +41 ms statusCode · resourceId · repetido
Esa secuencia responde lo que un código de estado no puede: a qué inquilino
resolvió la credencial, si el cuerpo satisfizo el contrato, qué escenario casó y
si vino de la aplicación o de X-Emulator-Scenario.
Los eventos se leen a través de la aplicación que va en la ruta, no sólo por el
identificador de la traza. Una traza lleva la petición que la hizo, así que
resolverla por identificador habría sido una manera de saltarse el alcance del
inquilino. El identificador de una traza de un inquilino que quien llama no puede
ver es trace_not_found, como cualquier otra fila invisible.
Los cuerpos se tachan al capturarlos, antes de que nada llegue a la base:
authorization y los tokens de tarjeta ya están como [REDACTED] en
almacenamiento, así que esta página no puede filtrar lo que nunca recibió.