Registro
El módulo «Registro» en Platform OneEntry permite a los administradores rastrear tanto las acciones de otros administradores en el sistema como la actividad de la API de contenido pública. El módulo consta de cuatro pestañas:
| Pestaña | Qué muestra |
|---|---|
| Registro de acciones de admin | Todas las acciones de los administradores en el sistema: creación, modificación, eliminación de entidades. |
| Tráfico de administradores | Sesiones de inicio de los administradores: cuándo ingresaron, cuándo salieron, desde qué dispositivo. |
| Estadísticas de la API de contenido | Contadores de llamadas a todos los endpoints públicos del sitio durante diferentes períodos. |
| Errores de la API de contenido | Todas las respuestas 4xx/5xx de la API pública con detalles de la solicitud y stack trace. |
En la interfaz del módulo, las pestañas están etiquetadas como: Registro de Admin, Registro de Acceso a la Aplicación de Admin, Estadísticas de la API de Contenido, Errores de la API de Contenido.
Cada pestaña está disponible bajo un permiso separado — ver Permisos para el registro.
Registro de acciones de admin
La pestaña principal, que muestra todas las acciones de los administradores en el sistema. Anteriormente se llamaba simplemente «Registro de acciones de admin» — ahora se ha renombrado a «Registro de acciones de admin» para distinguirla de las nuevas pestañas.
Elementos de la interfaz
La pestaña consta de dos bloques:
- Filtros
- Lista de acciones
Filtros
Para filtrar acciones, están disponibles los siguientes campos:
- Desde — campo de texto para ingresar la fecha a partir de la cual se deben filtrar las acciones.
- Hasta — campo de texto para ingresar la fecha hasta la cual se deben filtrar las acciones.
Las fechas se pueden ingresar como una cadena en el formato de fecha de su región, así como seleccionar la fecha necesaria mediante un calendario que aparece al hacer clic en el campo de entrada de fecha.
- ID de Administrador — campo numérico para el identificador único del administrador.
- Acciones del usuario — lista desplegable de acciones del usuario:
- Creación
- Modificación
- Eliminación
- Estado — lista desplegable de estados de las acciones:
- Exitoso
- Error
- Nombre del módulo — lista desplegable de nombres de módulos:
- Administradores
- Conjuntos de atributos
- Respaldo
- Gestión de bloques
- Gestión de eventos
- Configuración general
- Carga de archivos
- Editor de archivos
- Gestión de formularios
- Localización
- Marcadores
- Menú
- Módulos
- Gestión de contenido
- Productos
- Gestión de pedidos
- Configuración básica
- Gestión de pagos
- Gestión del estado del producto
- USUARIO
- Gestión de proveedores de autenticación y usuarios
- Gestión de plantillas
- Gestión de plantillas de vista previa
- ID de Registro — campo numérico para el identificador único del registro.
Debajo del bloque de filtros hay dos botones:
- Eliminar datos — elimina los registros del registro de acciones de admin para el período especificado por los campos Desde / Hasta (ver Limpieza de registros manualmente).
- Restablecer — restablece los filtros aplicados.
Lista de acciones
La lista de acciones se presenta en forma de tabla con seis columnas:
- Acciones del usuario
- Estado
- Inicio de sesión del usuario
- Nombre del módulo
- ID de registro
- Fecha y hora
Para cada columna hay una opción para ordenar los datos haciendo clic en el encabezado de la columna. El primer clic ordenará de forma descendente, el segundo de forma ascendente, el tercero restablecerá la ordenación.
Auditoría de visibilidad del bloque
Cada cambio de visibilidad del bloque (toggle «mostrar/no mostrar» en la administración de bloques) se registra automáticamente en el Registro de acciones de admin. Se puede ver qué administrador y cuándo cambió el estado de un bloque específico.
El cambio de visibilidad del bloque no se registraba en el registro — no se podía averiguar quién y cuándo ocultó/mostró el bloque. Ahora esto está disponible, y la operación se muestra en la lista general con el tipo «Gestión de bloques».
Tráfico de administradores (Registro de Acceso de Admin)
La pestaña «Tráfico de administradores» muestra cada inicio y cierre de sesión de un administrador en el sistema como un registro independiente. Ahora se puede ver de inmediato quién y cuándo ingresó al panel de administración — sin necesidad de consultar Grafana/Loki. Es útil para auditoría (especialmente para equipos grandes con varios administradores).
Campos de la tabla
La tabla consta de seis columnas:
| Columna | Qué significa |
|---|---|
| Inicio de sesión | nombre de usuario del administrador |
| IP | dirección IP desde la que ingresó el admin |
| Hora de inicio de sesión | fecha y hora del inicio de sesión |
| Hora de cierre de sesión | fecha y hora del cierre de sesión (para sesiones aún abiertas — vacío) |
| Duración | duración de la sesión (para sesiones activas — desde el inicio de sesión hasta el momento actual) |
| Razón | razón del cierre de la sesión: logout (salió por sí mismo) o admin_revoked (otro administrador cerró la sesión forzosamente, por ejemplo, a través de logoutAll) |
Al igual que en el Registro de acciones de admin, cualquier columna se puede ordenar haciendo clic en su encabezado.
La expiración del token (expired) y la reautenticación (refresh) no se registran como un registro separado — dicha sesión simplemente se marca como cerrada de manera perezosa, cuando realmente dejan de usarse.
Filtros
- Desde / hasta — período (campos de entrada de fecha con calendario).
- ID de Administrador — campo numérico para filtrar por un administrador específico.
- Estado de la sesión — lista desplegable del estado de la sesión: Todo / Activo / Cerrado.
Botón «Eliminar datos»
Elimina los registros de sesiones para el período especificado por los campos Desde / Hasta. Al hacer clic, se abre un cuadro de diálogo de confirmación:
Confirmar acción — ¿Eliminar todas las sesiones cerradas para el período especificado? Esta acción es irreversible. Las sesiones activas permanecerán.
Se eliminan solo las sesiones cerradas. Las sesiones activas (con autorización abierta) no se tocan — esto es una protección contra el «kill» accidental de colegas que están trabajando.
Estadísticas de la API de contenido
La pestaña «Estadísticas de la API de contenido» muestra los contadores de llamadas a todos los endpoints públicos del sitio (API de storefront) durante diferentes períodos — 1 hora, 24 horas, 7 días.
Qué muestra
- Lista de todos los endpoints públicos (
GET /api/content/...) — se recopila automáticamente del código, no es necesario mantener nada manualmente. - Contador junto a cada endpoint — cuántas veces se ha llamado durante el período seleccionado.
- Los números se obtienen de la métrica centralizada de Prometheus-nginx-ingress, que es responsable de nuestro tráfico. No se crean contadores separados en la base de datos del proyecto.
Elementos de la interfaz
- Período — lista desplegable del período: Última Hora / Últimas 24 Horas / Últimos 7 Días (por defecto — Últimas 24 Horas).
- Actualizar — botón para forzar la actualización de datos.
Los datos se presentan en una tabla de cuatro columnas:
| Columna | Qué significa |
|---|---|
| Ruta | ruta del endpoint (/api/content/...) |
| Método | método HTTP (GET, POST, …) |
| Descripción | breve descripción del endpoint |
| Solicitudes | número de llamadas durante el período seleccionado |
En la parte superior de la página se muestra un banner informativo:
Auto-limpieza no aplicable — Los datos se leen en tiempo real desde Prometheus, la retención está configurada a nivel de infraestructura de monitoreo. Esta pestaña no almacena datos en la base de datos CMS.
Si Prometheus no está disponible, aparece una advertencia sobre la tabla «Métrica temporalmente no disponible. Todos los endpoints se muestran con un conteo cero.» — la lista de endpoints aún se muestra, pero con un contador de 0.
Los datos se almacenan en Prometheus con una retención a nivel de infraestructura (generalmente 30 días). Para análisis más prolongados, es necesario almacenar de forma independiente. El banner informativo en la parte superior de la página advierte sobre esto.
Para qué sirve
El marketing y el producto pueden ver qué características de la API de storefront se utilizan realmente y cuáles están muertas. También es conveniente monitorear si «todo está funcionando» — una caída abrupta en las llamadas a un endpoint generalmente indica un problema en el lado del frontend.
La respuesta se almacena en caché durante 60 segundos en Redis — para no consultar a Prometheus en cada clic en «Actualizar».
Errores de la API de contenido
La pestaña «Errores de la API de contenido» muestra todas las respuestas 4xx/5xx que ha devuelto la API pública durante un período. Los desarrolladores que integran la aplicación del cliente con nuestra API ya no necesitan acceso a los registros del servidor — ven todos los errores de sus solicitudes directamente en el panel de administración.
Qué muestra
Cada registro es un error HTTP separado. La tabla consta de cinco columnas:
| Columna | Qué significa |
|---|---|
| Hora | marca de tiempo del error |
| Estado | estado HTTP (4xx / 5xx) |
| Método | método de la solicitud (GET, POST, …) |
| Ruta | ruta (/api/content/...) |
| Mensaje | texto del error |
Si no hubo errores durante el período seleccionado, en lugar de la tabla se muestra el mensaje «No se registraron errores para el período seleccionado».
El campo «Más detalles» abre una pantalla detallada con:
- Cuerpo de la solicitud (sin secretos — contraseñas, tokens, encabezados de autorización están enmascarados)
- Consulta — parámetros de la cadena de consulta
- Encabezados
- Stack trace — desplegado (hasta 8 KB)
Filtros
- Desde / hasta — período (campos de entrada de fecha con calendario).
- Estado HTTP — lista desplegable de estados. Se puede elegir un grupo (4xx - Lado del cliente, 5xx - Lado del servidor) o un código específico: 400, 401, 403, 404, 422, 500, 502, 503.
- Ruta — campo de texto para filtrar por ruta (por ejemplo,
/api/content/blocks/*).
Botón «Eliminar datos»
Elimina los registros de errores para el período especificado por los campos Desde / Hasta. Si no se especifica un período — elimina todos los errores.
Seguridad — sanitizador
El sanitizador elimina automáticamente datos sensibles. Los campos password, token, authorization, api_key, x-app-token, cookie, set-cookie (sin distinción de mayúsculas) se reemplazan por ***. Los cuerpos grandes se recortan a 2 KB.
Arquitectura
Los errores se registran a través de una cola ligera Bull, para que el registro en el log no retrase el procesamiento de la solicitud. Si la cola está llena (más de 1000 tareas pendientes) — se descartan silenciosamente nuevos errores, para no «caer» Redis.
Limpieza de registros manualmente
Los registros se limpian manualmente — en cada pestaña que almacena datos en la base de datos, hay un botón «Eliminar datos»:
| Pestaña | Qué elimina |
|---|---|
| Registro de acciones de admin | registros de acciones de admin para el período seleccionado |
| Tráfico de administradores | solo sesiones cerradas para el período seleccionado |
| Errores de la API de contenido | registros de errores para el período seleccionado |
El período de eliminación se establece mediante los campos Desde / Hasta en los filtros de la pestaña. Si no se especifica un período — se eliminan todos los registros del tipo correspondiente. Antes de eliminar, siempre se muestra un cuadro de diálogo de confirmación «Confirmar acción», la operación es irreversible.
El botón «Eliminar datos» en la pestaña «Tráfico de administradores» no elimina las sesiones activas de los administradores — incluso si se establece un período que cubre el momento actual, la sesión abierta de un colega que está trabajando no se eliminará. Solo se eliminan las sesiones cerradas.
Los datos de estadísticas se leen en tiempo real desde Prometheus y no se almacenan en la base de datos CMS, por lo que no hay botón «Eliminar datos» en esta pestaña — esto se indica con el banner «Auto-limpieza no aplicable».
Permisos para el registro
Cada pestaña del registro está disponible bajo un permiso separado en el árbol de permisos:
| Pestaña | Permiso |
|---|---|
| Registro de acciones de admin | journal.viewAdminActions (permiso existente, sin cambios) |
| Tráfico de administradores | journal.viewAdminAccess (nuevo permiso) |
| Estadísticas de la API de contenido | journal.viewContentApiStats (nuevo permiso) |
| Errores de la API de contenido | journal.viewContentApiErrors (nuevo permiso) |
Al actualizar el sistema, ambos nuevos permisos (journal.viewContentApiStats, journal.viewContentApiErrors) se otorgaron automáticamente a todos los administradores existentes con el permiso admins.get — a través de una migración de seed. No se rompió nada para los roles actuales.