Saltar al contenido principal

Aislamiento de Datos por Tenant

AI Observability está migrando de una base de datos compartida a una base de datos por tenant. Esta página explica ambos modelos, qué cambia cuando se realiza la transición en un despliegue y el ajuste OBS_TENANT_DB_MODE que controla dicho cambio.

Si solo utiliza SaaS y no tiene ningún despliegue autohospedado, el resumen es el siguiente: nada cambia para usted hasta que Beak complete la transición en su entorno; una vez completada, el selector de usuarios en Control de Acceso muestra únicamente los usuarios de su propio tenant.

Los dos modelos​

Base de datos compartida (el modelo original). Las trazas, spans, roles y usuarios de todos los tenants residen en una única base de datos beakai. Las filas se separan mediante una columna tenant_id y cada consulta filtra por ella.

Base de datos por tenant (el modelo objetivo). Los datos de cada tenant residen en su propia base de datos, resuelta a partir del registro de tenants de la plataforma. Las columnas tenant_id se conservan, pero ahora actúan como comprobación de consistencia y no como mecanismo de separación.

El segundo modelo es el estándar de la plataforma Beak AI — AI Studio, Agent Runtime, AI Security, Scheduler y Gateway Manager ya funcionan de esta manera. Las bases de datos por tenant constituyen un límite más sólido porque la separación deja de depender de que cada consulta recuerde aplicar el filtro: las filas de otro tenant simplemente no están presentes en la base de datos consultada.

Configuración​

OBS_TENANT_DB_MODE controla qué modelo utiliza un despliegue. Se establece por entorno.

ValorLee deEscribe enPropósito
offbeakai compartidabeakai compartidaEl modelo original. Por defecto.
readbase de datos del tenantbeakai compartidaVerificar lecturas con los datos migrados mientras las escrituras permanecen en su sitio, de modo que revertir sea un único cambio de ajuste.
dualbase de datos del tenantambasPeríodo de estabilización. No se pierde telemetría y revertir sigue siendo trivial.
fullbase de datos del tenantbase de datos del tenantEl modelo objetivo.

Ajustes relacionados que raramente necesitan modificación:

  • DB_TENANT_REGISTRY — la base de datos de registro utilizada para resolver un tenant a su propia base de datos. Por defecto tenant.
  • DB_TENANT_MIN_POOL_SIZE / DB_TENANT_MAX_POOL_SIZE — límites del pool de conexiones por base de datos de tenant. Por defecto 1 y 10. El mínimo es deliberadamente bajo porque cada réplica abre su propio pool por tenant activo; aumente el máximo solo después de verificar el valor de max_connections de la base de datos.

Un valor no reconocido para OBS_TENANT_DB_MODE detiene el servicio en el arranque en lugar de retroceder silenciosamente a off — un error tipográfico no puede confundirse con una transición completada.

Control de Acceso y roles no se migran parcialmente​

Los modos read y dual separan lecturas de escrituras únicamente para telemetría — trazas, spans, puntuaciones de evaluadores y eventos de alerta. Las cuentas de usuario y las asignaciones de roles siempre leen y escriben en la misma base de datos, y se trasladan a la base de datos del tenant en cuanto el modo sale de off.

Esto es relevante para revertir: las concesiones de roles y el aprovisionamiento en el primer inicio de sesión que ocurren durante un período de estabilización existen únicamente en la base de datos del tenant. Volver a off no elimina las cuentas de usuario — el siguiente inicio de sesión las vuelve a aprovisionar — pero las concesiones de roles explícitas realizadas durante el período de estabilización deben volver a concederse. Planifique los períodos de estabilización en consecuencia, o manténgalos breves.

Migrar un despliegue existente​

Los datos existentes deben copiarse en las bases de datos del tenant antes de cambiar el modo. Leer desde una base de datos de tenant vacía produce paneles vacíos, no un error.

El servicio incluye una utilidad de relleno retroactivo para esto:

# Informar de lo que se copiaría, sin escribir
python scripts/backfill_tenant_dbs.py --dry-run

# Copiar todos los tenants
python scripts/backfill_tenant_dbs.py

# Copiar un único tenant
python scripts/backfill_tenant_dbs.py --tenant 20

# Comparar recuentos de filas entre origen y destino
python scripts/backfill_tenant_dbs.py --verify

Propiedades que conviene conocer:

  • No destructivo. Solo inserta en las bases de datos del tenant. La base de datos compartida nunca se modifica, por lo que permanece como fallback completo.
  • Re-ejecutable. Cada inserción omite las filas que ya existen, por lo que ejecutarlo dos veces es seguro — y ejecutarlo de nuevo tras un período de estabilización recoge lo que se haya escrito en la base de datos compartida mientras tanto.
  • Solo datos. Nunca crea tablas. Los esquemas del tenant, incluidas las cuatro tablas de series temporales, se aprovisionan durante la incorporación del tenant.
  • Informa de lo que no moverá. Las cuentas de usuario que no tienen ningún rol en ningún tenant no pueden atribuirse a uno, por lo que permanecen en la base de datos compartida y se listan por nombre. Suelen ser cuentas obsoletas que merece la pena revisar.

El orden recomendado por entorno es: ejecutar el relleno retroactivo, establecer read y confirmar que los paneles coinciden, establecer dual durante un día laborable y, a continuación, establecer full. Los entornos se migran de uno en uno.

Qué notará tras la transición​

  • El selector de usuarios en Control de Acceso muestra únicamente los usuarios de su tenant. En el modelo compartido, el directorio de cuentas no tenía columna de tenant, por lo que el selector listaba a todos los usuarios de la plataforma. La asignación de roles siempre estaba correctamente limitada a su tenant — esto solo afectaba a quién aparecía listado, nunca a quién tenía acceso — pero ahora la lista también está limitada.
  • Los paneles, la búsqueda de trazas y los análisis no cambian. Los mismos datos, los mismos números, leídos desde una base de datos diferente.
  • Las configuraciones de alertas de anomalía, los informes de RCA y las configuraciones de evaluación ahora se guardan. Un defecto corregido junto con este trabajo apuntaba esas funciones al esquema de base de datos incorrecto, por lo que crearlas o listarlas fallaba. Si esas páginas parecían permanentemente vacías o daban error, esa era la razón; ahora funcionan correctamente.

Páginas relacionadas​