¿Puedes rastrear una acción fallida en toda tu pila de aplicaciones autoalojadas? Lista de verificación para correlacionar registros
Usa un ID de solicitud o de correlación, marcas de tiempo coherentes y una prueba controlada para comprobar si los registros de tu proxy, aplicación, procesos de trabajo y dependencias cuentan una historia útil.
Traza el recorrido de la acción antes de buscar en los registros
Empieza con un fallo visible para el usuario y esquematiza el recorrido que podría seguir el trabajo. Un mapa habitual de investigación incluye el proxy inverso, la aplicación, un trabajador en segundo plano, la base de datos y cualquier dependencia externa implicada. Tómalo como una hipótesis: una aplicación concreta quizá solo use algunos de estos componentes o gestione el trabajo de otra manera.
Para cada paso, anota qué servicio genera registros, dónde puedes acceder a ellos y qué evento indicaría que la acción llegó o se completó. Así acotarás la búsqueda en lugar de revisar indiscriminadamente mensajes que no guardan relación.
- Anota la acción, la hora aproximada y el resultado esperado.
- Enumera los componentes que podrían gestionarla, incluidos los trabajadores asíncronos.
- Registra cómo acceder a los registros de cada componente y si puedes buscarlos por hora o por campo.
- Señala explícitamente las lagunas: un componente sin registros accesibles no puede aportar información al rastro.
Elige un identificador y comprueba hasta dónde se propaga
Un ID de solicitud o de correlación puede proporcionar un valor común para buscar eventos relacionados. No des por sentado que todos los servicios lo aceptan, lo reenvían o lo registran. Comprueba la configuración y los registros reales de cada componente de tu recorrido.
Si una solicitud entrante ya incluye un identificador, decide si lo conservarás o crearás uno en un punto de la ruta que controles. No trates como prueba fiable un valor proporcionado por el cliente sin comprobar cómo lo gestiona tu aplicación. La prueba práctica consiste en verificar que el mismo valor elegido aparece en los registros pertinentes, no simplemente que existe una opción de configuración.
- Elige un nombre de campo y un formato que tus componentes puedan registrar de forma coherente.
- Comprueba primero el proxy y la aplicación, y después cada componente posterior.
- En los componentes que no puedas configurar, anota qué campos alternativos pueden ayudar a acotar la búsqueda, como un intervalo de tiempo o un ID de trabajo.
- No incluyas credenciales, tokens ni información personal en el identificador.
Mantén el rastro al pasar a los trabajos en cola
Una acción del usuario puede completar su solicitud web antes de que se inicie o termine una tarea en cola. En ese caso, el registro de la solicitud por sí solo quizá no muestre el resultado. Comprueba si tu aplicación transfiere un valor de correlación al trabajo en cola y si el trabajador lo registra al iniciar, terminar o fallar la tarea.
Si el sistema de trabajos utiliza su propio ID de trabajo, registra la relación entre ese identificador y el ID de solicitud o de correlación original. Verifica este comportamiento con la aplicación y la configuración de cola que realmente utilizas; la compatibilidad y los nombres de campo varían.
- Confirma si el evento de puesta en cola registra un ID de trabajo y un ID de correlación.
- Comprueba si los registros del trabajador indican el inicio y el resultado final del mismo trabajo.
- Si el ID de correlación no se propaga, documenta el vínculo disponible entre la solicitud y el trabajo.
- Distingue entre un trabajo que nunca se puso en cola y otro que sí se puso, pero no llegó a completarse.
Haz comparables las marcas de tiempo y los campos de registro
Para que el rastro sea útil, los registros deben poder compararse. Comprueba qué zona horaria utiliza cada servicio, si las marcas de tiempo incluyen una zona horaria y si los relojes parecen estar desincronizados. Si los eventos parecen estar desordenados, tómalo como una cuestión que hay que investigar, en lugar de dar por sentado que el orden mostrado refleja la secuencia real.
Los campos coherentes y estructurados facilitan el filtrado. La documentación de Datadog señala que, antes de correlacionar registros con trazas, los registros deben estar en formato JSON o ser analizados por el procesador de registros apropiado para el lenguaje. Esa recomendación se refiere a la correlación de trazas; si la investigación solo utiliza registros, comprueba que tus propias herramientas de búsqueda puedan identificar de forma fiable los campos que necesitas.
- Busca una marca de tiempo, el nombre del servicio o componente, el nivel de gravedad, el mensaje del evento y el campo de correlación.
- Comprueba si las marcas de tiempo indican su zona horaria y si los relojes de los servicios parecen estar sincronizados.
- Prefiere un nombre de campo estable para el valor de correlación en todos los componentes.
- Prueba cómo analiza los campos tu visor de registros; no des por sentado que un valor en texto sin estructura se puede buscar como campo.
Realiza una prueba controlada de fallo
Antes de confiar en el rastro durante un incidente, pruébalo con una acción de bajo riesgo en un entorno controlado o en un momento en que puedas observar el resultado con seguridad. Usa un identificador conocido, provoca un fallo que puedas reconocer y después busca en los registros de cada componente. No provoques un fallo que pueda afectar a datos importantes de clientes o a las operaciones del negocio.
La prueba solo tiene éxito si puedes reconstruir una secuencia útil: dónde entró la acción, qué componente la gestionó, si el trabajo se puso en cola y dónde se hizo visible el fallo. Si el rastro se interrumpe, registra el traspaso que falta y decide si puedes añadir registros o necesitas otra fuente de evidencia.
- Usa una acción de prueba cuyo resultado de fallo esperado sea observable.
- Busca el ID de correlación conocido y compara los registros de los distintos componentes.
- Comprueba que el resultado del trabajador se pueda vincular con la acción que lo inició.
- Anota las lagunas, las marcas de tiempo ambiguas y los campos que no se pudieron buscar.
Mantén el rastro útil sin recopilar datos en exceso
Los registros de diagnóstico ayudan a investigar el comportamiento y los fallos, pero también pueden contener información confidencial si las aplicaciones o la configuración la escriben allí. Revisa los campos que revela la prueba y evita registrar credenciales, tokens de acceso o datos personales que no sean necesarios para la investigación.
Decide quién necesita acceder a los registros y durante cuánto tiempo deben estar disponibles para tus necesidades operativas. Estas decisiones dependen de tu aplicación, tus riesgos y tus requisitos de gobernanza; no des por sentado que el alojamiento o la gestión de la infraestructura las resuelven automáticamente. Airbip gestiona la infraestructura en la nube para aplicaciones autoalojadas y automatiza el enrutamiento y los certificados TLS, pero los clientes siguen teniendo que conocer sus propios acuerdos de acceso y retención de registros.
- Examina ejemplos reales de registros antes de ampliar la recopilación o compartir el acceso.
- Limita el acceso a quienes necesiten los registros para tareas operativas o de seguridad.
- Define deliberadamente el plazo de retención y revisa si sigue siendo adecuado para tus necesidades.
- Vuelve a comprobar el registro después de hacer cambios en la aplicación o la configuración.
Ten claro qué pueden demostrar los registros y qué no
Un rastro de diagnóstico correlacionado puede ayudar a explicar cómo se desarrolló un fallo, pero no constituye automáticamente un registro completo de quién realizó una acción ni garantiza que un registro sea una fuente autorizada. Si necesitas pruebas fiables de las acciones para fines de rendición de cuentas o gobernanza, identifica y mantén por separado los registros de auditoría adecuados.
Documenta los límites de tu rastro: componentes que no exponen registros, campos que no se propagan, periodos sin cobertura temporal y eventos que no se pueden vincular con seguridad. Es más útil explicar con claridad qué demuestran los registros que tratar un ID de correlación como prueba de cada paso.
- Usa los registros de diagnóstico para investigar el funcionamiento y los fallos.
- Determina si necesitas registros de auditoría independientes para tus requisitos de rendición de cuentas.
- Registra las lagunas conocidas y evita afirmar que tienes una cronología completa cuando las pruebas son incompletas.
- Repite la prueba controlada cuando cambien componentes importantes o los mecanismos de registro.
Preguntas frecuentes
¿Todos los servicios necesitan trazado distribuido para correlacionar una acción fallida?
No. Esta lista de verificación se centra en si los eventos de registro relacionados pueden vincularse mediante un identificador y compararse entre componentes. No presupone que todos los servicios admitan el trazado distribuido. Comprueba qué registra realmente cada componente y documenta las lagunas.
¿Qué pasa si un trabajo en cola no incluye el ID de solicitud original?
Comprueba si el evento de puesta en cola registra un ID de trabajo y si los registros del trabajador incluyen ese mismo ID. Si no hay un vínculo fiable con la solicitud que inició el trabajo, anota la laguna y evalúa si la aplicación o la configuración de trabajos pueden registrar uno.
¿Los registros de la aplicación deberían estar en formato JSON?
Los registros estructurados pueden facilitar la identificación y búsqueda de campos. La documentación de Datadog señala específicamente que, al correlacionar registros con trazas, estos deben estar en formato JSON o ser analizados por el procesador de registros apropiado para el lenguaje. Comprueba qué pueden analizar y buscar tus propias herramientas de registro.
¿Los registros de diagnóstico equivalen a los registros de auditoría?
No des por sentado que son intercambiables. Los registros de diagnóstico se usan para investigar el comportamiento y los fallos del sistema. Si necesitas un registro autorizado de acciones para fines de rendición de cuentas o gobernanza, determina qué registros de auditoría independientes son adecuados para tu aplicación y tus requisitos.
¿La infraestructura gestionada se ocupa del acceso y la retención de los registros?
No lo des por sentado. Comprueba las condiciones reales de tu aplicación y alojamiento, incluidos quién puede acceder a los registros y durante cuánto tiempo se conservan. La infraestructura gestionada no elimina la necesidad de conocer tus responsabilidades en materia de datos y gobernanza.
Fuentes y lecturas adicionales
- Correlate Logs and Traces — Datadog
- Application logs and agent traces in one view — Braintrust