Propuesta Técnica: Modernización y Externalización del Sistema de Logs de Quartup

1. Estado Actual y Diagnóstico

Actualmente, los registros de actividad (LOGs) de Quartup se almacenan en tablas relacionales dentro de la misma base de datos de producción de cada cliente (tenant).

Desglose de tablas actuales:

quemregipag / quemregitra: Auditoría de ejecución de páginas y transacciones (operaciones CUD).
quemregipagcur: Registro temporal de informes en ejecución.
quemregiwes: Log de servicios web (principalmente integración con Prestashop), cubriendo tráfico entrante y saliente.
quupapilog: Registro de llamadas a la API-1 de Quartup.
quliqtoxlog: Seguimiento de ejecuciones del motor Q2X.

Solo el primer bloque de Auditoría está actualmente implantado de forma permanente, el resto de LOGs son actualmente volátiles, pero con potencial de persistencia.

En el presente documento nos centraremos en el bloque de Auditoría, dejando la renovación del resto para próximas revisiones.

Objetivos de la Renovación:

Optimización de Almacenamiento: Liberar espacio en los discos de alto rendimiento del entorno de producción.
Mejora del Rendimiento (I/O): Reducir la carga de operaciones de entrada/salida en el gestor SQL principal.
Integridad de Datos: Garantizar la consistencia entre los eventos de log y los datos de negocio.

2. Alternativas de Solución

Propuesta 1: Arquitectura Basada en CDC (Change Data Capture)

Esta opción propone una extracción pasiva de datos basada en los eventos del motor de base de datos.

Stack Tecnológico: MariaDB (Binlog en modo ROW) + Debezium + Kafka + Elasticsearch.
Funcionamiento: Debezium "lee" los cambios directamente de los logs binarios de MariaDB y los publica en un clúster de Kafka, para finalmente persistirlos en Elasticsearch.
Inconvenientes y Desafíos:
- Identificación de Contexto: De forma nativa, el CDC registra el cambio de la fila, pero no el usuario o tenant que ejecutó la acción.
- Solución Técnica: Se requiere el desarrollo de un SMT (Single Message Transformation) personalizado en Debezium. Este componente debe parsear los comentarios SQL (donde Quartup inserta los IDs de usuario y tenant) habilitando la opción binlog_rows_query_log_events = ON.
- Complejidad: Requiere gestionar una infraestructura adicional (Kafka/Elasticsearch).

Propuesta 2: Externalización SQL Síncrona (Online)

Envío de logs en tiempo real hacia una base de datos SQL externa dedicada exclusivamente a auditoría.

Funcionamiento: El flujo de la aplicación envía una señal al sistema externo en cada hito crítico: inicio de página, START TRANSACTION, operaciones CUD, y cierre (COMMIT/ROLLBACK).
Inconvenientes:
- Dependencia Crítica: Existe un acoplamiento fuerte. Si el sistema externo cae o presenta latencia, impacta directamente en la disponibilidad o rendimiento de la aplicación de producción.
- Riesgo de Pérdida: Sin una capa intermedia, cualquier error de red resultaría en la pérdida irremediable del log.

Propuesta 3: Externalización Híbrida (Online/Offline con Fallback)

Evolución de la propuesta 2, utilizando un patrón de Buffer Local.

Funcionamiento: El sistema intenta el envío online. Si el sistema externo no está disponible, el log se almacena temporalmente en una tabla de "cola" dentro de la base de datos local. Un proceso en segundo plano se encarga de reintentar el envío una vez se restablezca la conexión.
Ventajas: Elimina la necesidad de una infraestructura de mensajería compleja (como Kafka) manteniendo una alta fiabilidad.
Inconveniente: Durante las caídas del sistema externo, el objetivo de "reducir el I/O en producción" se ve comprometido temporalmente, ya que volvemos a escribir logs localmente.

3. Matriz Comparativa

Criterio	Propuesta 1 (CDC)	Propuesta 2 (Online)	Propuesta 3 (Híbrida)
Impacto en CPU/IO Producción	Mínimo (Lectura de Log)	Medio/Alto (Escritura remota)	Bajo (Variable)
Complejidad Implementación	Alta (Infraestructura)	Baja	Media
Garantía de Entrega	Muy Alta	Baja	Alta
Escalabilidad	Excelente (Elasticsearch)	Limitada (SQL)	Media (SQL)