Qué y hasta dónde debe registrar el lado de la aplicación
Hola, soy Otsuka, CTO de Liberogic.
En la entrega anterior, comparamos funciones de registro entre diferentes servicios como AWS, Cloudflare, Vercel, Supabase y headless CMS.
Cada servicio proporciona registros de ejecución, registros de errores y registros de operaciones administrativas.
¿Entonces, combinando todos estos, tenemos cubiertos todos los registros necesarios para un servicio web?
Desafortunadamente, no es tan simple.
Los registros que los servicios en la nube generan automáticamente son diferentes de los que deben registrarse en el lado de la aplicación que construimos.
En esta entrega, organizaremos cómo planificar el diseño de registros en un servicio web real, centrándonos en aspectos más prácticos.
Lo que no se puede saber solo con los registros del servicio
Si está utilizando Cloudflare Workers o Vercel Functions, los resultados de ejecución y errores se registran automáticamente hasta cierto punto.
Con Supabase, puede consultar registros de bases de datos, autenticación, API y más.
Sin embargo, el servicio solo puede registrar lo que sucede dentro de su propio sistema.
Lo que se retiene automáticamente | Lo que registra la aplicación |
|---|---|
Ejecución de Worker o Function | Recepción de consultas |
Excepciones o errores de procesamiento | Cambios en la información de miembros |
Respuesta de API | Cambios de permisos |
Conexión a la base de datos | Éxito o fracaso del envío de correo |
Operaciones de gestión del entorno en la nube | Detección de spam o rechazo por razones comerciales |
Por ejemplo, aunque podamos saber que la escritura en la base de datos fue exitosa, no podemos determinar si fue para "aceptar una consulta" o "modificar la información del miembro".
Los eventos operativos como estos deben ser registrados con significado asignado por el lado de la aplicación.
No todo debe registrarse en los registros
Podría parecer prudente registrar la mayor cantidad de información posible en los registros en preparación para investigaciones futuras.
Sin embargo, más registros no siempre significa mejor.
Si registramos todos los procesos en detalle, la información verdaderamente necesaria quedará enterrada. A medida que aumenta el volumen de registros, también aumentan los costos de almacenamiento y búsqueda.
Por eso, diseñamos los registros siendo conscientes de los "puntos de transición" en el procesamiento.
Por ejemplo, en el caso de un formulario de contacto,
- la recepción fue exitosa
- rechazamos debido a problemas en el contenido introducido
- rechazamos por detección de spam
- falló el guardado en la base de datos
- falló el envío del correo de notificación
registramos estos puntos donde el resultado del procesamiento cambia.
En lugar de mantener todas las variables intermedias y los procesos detallados, la idea es seleccionar los eventos necesarios para poder rastrear el historial posteriormente.
Guardamos los registros como datos, no como texto.
Es más útil incluir en los registros información que se pueda buscar posteriormente, en lugar de escribir simplemente «Ocurrió un error».
Elemento | Función |
|---|---|
Fecha y hora de ocurrencia | Verificar cuándo ocurrió |
Nombre del evento | Clasificar en qué proceso ocurrió |
Nivel de importancia | Distinguir entre éxito, advertencia y fallo |
ID del destino | Identificar los datos de destino |
ID de solicitud | Rastrear una serie de procesos |
Tiempo de procesamiento | Verificar retrasos y degradación del rendimiento |
Los registros que documentan estos elementos en un formato establecido se denominan registros estructurados.
Si los elementos se alinean en un formato como JSON, es más fácil realizar búsquedas como "verificar solo el procesamiento relacionado con un ID de solicitud específico" o "extraer solo los intentos de envío de correo que resultaron en error".
No escribir información personal en los registros
Al conservar registros de formularios de contacto, a veces se registran el nombre, la dirección de correo electrónico y el contenido completo de la consulta.
Aunque podría parecer conveniente para investigación, este es un diseño que debe evitarse.
Escribir en los registros | No escribir en los registros |
|---|---|
Fecha y hora de procesamiento | Contraseña |
Nombre del evento | Token de acceso |
Éxito o fracaso | Cookie |
ID de los datos objetivo | Cuerpo de la consulta |
ID de solicitud | Información de tarjeta de crédito |
Tiempo de procesamiento | Información personal innecesaria |
Los registros se transmiten a múltiples servicios o se almacenan durante períodos prolongados. Si contienen información personal o credenciales de autenticación, los registros mismos se convierten en una nueva fuente de filtración de datos.
Los datos operativos como el contenido de consultas se guardan en la base de datos, mientras que en los registros solo se registra el ID que identifica la consulta y el hecho de que la recepción fue exitosa.
Cuando sea necesario, utiliza ese ID para cotejar la información con el lado de la base de datos.
Reflexionando sobre formularios de contacto
En los formularios de contacto, a menudo se ve una estructura que solo envía un correo de notificación.
Sin embargo, aunque el envío del correo sea exitoso, no hay garantía de que llegue al destinatario.
Por eso es más seguro guardar primero el contenido del contacto en la base de datos y tratar el correo solo como notificación al responsable.
Con esta estructura, puedes distinguir si "el contacto no llegó" o si "el contacto se guardó pero solo falló el correo de notificación".
Esta sutil diferencia es realmente importante en el manejo real de contactos.
Separar búsquedas a corto plazo del almacenamiento a largo plazo
En la investigación de incidentes diarios, es importante poder buscar rápidamente los registros recientes.
Por otro lado, para registros de auditoría o investigaciones de incidentes, es importante poder recuperarlos meses o años después, incluso si rara vez se consultan.
Destino de almacenamiento | Propósito principal |
|---|---|
Pantalla de registro de cada servicio | Verificación de funcionamiento reciente |
Servicios de gestión de registros como Datadog | Búsqueda transversal, supervisión y notificaciones |
R2 o S3 | Almacenamiento a largo plazo de pruebas |
Coloca lo que necesitas para investigaciones recientes en un lugar fácil de buscar y traslada las pruebas a largo plazo a un destino de almacenamiento económico.
Es sencillo, pero en la práctica esta división es muy efectiva.
Los registros y el panel de control son cosas diferentes
Si tienes registros, puedes conocer el número de accesos, la tasa de errores y más.
Sin embargo, los valores que ves en los registros y en el panel de control tienen roles ligeramente diferentes.
- Registros: investigar eventos individuales en detalle
- Métricas: agregar el número de eventos, porcentajes, tiempos de procesamiento, etc.
- Panel de control: comprender las tendencias del sistema en general
Utiliza el panel de control para verificar el estado diario y, cuando encuentres anomalías, consulta los registros para investigar con más detalle.
Combinando estos dos enfoques, la operación se vuelve más fácil.
Lo mínimo que debes decidir
Finalmente, resumimos los elementos que debes verificar al diseñar registros.
- Eventos a registrar
- Elementos a incluir en el registro
- Exclusión de información personal y credenciales de autenticación
- Período durante el cual se pueden buscar registros recientes
- Rango de registros para almacenamiento a largo plazo
- Ubicación de almacenamiento de registros a largo plazo
- Personal responsable que puede ver los registros
- Método de eliminación de registros después del período de retención
Cuando se menciona el término "registro de auditoría", es posible que sienta que debe registrar todas las operaciones e implementar una base de gestión de registros de gran escala.
Por otro lado, si se trata de un sitio web general o un sitio de medios, puede comenzar decidiendo primero qué operaciones y resultados de procesamiento son importantes, y luego separar la búsqueda a corto plazo del almacenamiento a largo plazo.
Lo importante no es enumerar las funciones de registro de los servicios que se utilizan, sino verificar que el sistema en su conjunto conserva los registros necesarios.
¿Qué se debe registrar?
¿Para qué se registra?
¿Cuánto tiempo es necesario conservarlo?
Si organizas bien estas tres cuestiones, podrás diseñar un registro adecuado al proyecto sin crear una estructura innecesariamente grande.
Los registros normalmente no destacan.
Pero cuando ocurre algo, la capacidad de explicar «qué sucedió» se decide en el diseño inicial.
Es importante construir bien estos fundamentos prácticos y sólidos.
Bueno, hasta luego.
Pilar de la división técnica de Liberogic. Cuando escucha "Me gustaría que existiera esto, sería muy útil", lo implementa en un instante, añadiendo valor gracias a su ingenio innato. Persona con gran capacidad de comunicación, querida por muchos clientes, es un tesoro de nuestra empresa y adora los gatos.
Shō Ōtsuka
Director Técnico / Ingeniero Jefe / Representante de Nekoana LLC / Aparentemente más joven de lo que es