Saltar al contenido principal

Observabilidad IA — Requisitos previos

Esta página enumera lo que un cliente necesita aportar antes de que se aprovisione AI Observability.

Requisitos previos — SaaS​

En SaaS, AI Observability se ejecuta en la infraestructura gestionada por Beak en observe.beakops.com.

Tenant y licenciamiento​

  • Suscripción activa a Beak AI Observability — Dimensionada por tasa de ingesta (spans por minuto), período de retención y número de evaluaciones.
  • Tenants de Studio/Runtime/Gateway vinculados — La ingesta de trazas es más útil cuando al menos uno de estos productos también está incorporado.

Identidad y acceso​

  • SSO de administración — Microsoft Entra ID, Okta, Google Workspace o cualquier IdP OIDC para administradores de Observability, SREs e ingenieros de IA.
  • Modelo de propiedad de proyectos — Decidir qué grupos del IdP son propietarios de qué proyectos (un proyecto es la unidad de control de acceso).

Red y conectividad​

  • Tráfico saliente desde Studio, Runtime y Gateway — Los tres envían trazas a observe.beakops.com mediante HTTPS. Incluya este hostname en la lista de permitidos de su egreso.
  • Tráfico saliente desde aplicaciones personalizadas (opcional) — Las aplicaciones no desarrolladas sobre Beak también pueden enviar trazas; misma regla de salida.
  • Entrante: no se requiere — Observability no necesita ninguna regla de entrada en su infraestructura.

Retención de datos y privacidad​

  • Plan de retención — Elija una ventana de retención (30, 90, 180 o 365 días). Las ventanas más largas se facturan en consecuencia.
  • Gestión de PII — Decida si los prompts y completaciones se almacenan de forma completa, redactada o solo con hash. La política de redacción se aplica antes de la persistencia.
  • Selección de región — Elija una región de datos (EE. UU., UE, India). Afecta al lugar donde se almacenan las trazas y los datos de evaluación.

Licenciamiento​

  • Suscripción activa a Beak AI Observability según lo indicado anteriormente.

Responsabilidades del cliente​

  • Definir proyectos, propietarios y grupos de acceso.
  • Establecer la política de retención y redacción.
  • Crear conjuntos de datos de evaluación y revisar las alertas de regresión.
  • Revisar los registros de auditoría para el cumplimiento normativo.

Requisitos previos — On-prem​

En On-prem, AI Observability se ejecuta en Kubernetes gestionado por el cliente. La plataforma está construida sobre un pipeline de streaming.

Infraestructura​

  • Kubernetes 1.28+ — Clúster multinodo dimensionado para una ingesta sostenida. Dimensionamiento de referencia para 1.000 spans/seg: 6 nodos worker × 16 vCPU / 64 GiB de RAM cada uno.
  • Almacenamiento de objetos — Compatible con S3, Azure Blob o MinIO para el almacenamiento de spans a largo plazo.
  • Ingress — Ingress gestionado por el cliente con terminación TLS para la interfaz web de Observability y el endpoint de ingesta de trazas.

Almacenes de datos​

  • PostgreSQL 14+ con extensiones TimescaleDB y pgvector — Almacén único para spans, trazas, métricas, evaluaciones, alertas y las tablas de configuración (proyectos, conjuntos de datos, definiciones de evaluación, control de acceso). Las hipertablas de TimescaleDB proporcionan compresión de estilo columnar con partición temporal para datos de trazas/spans; pgvector respalda la detección de deriva semántica. Dimensionado según la retención y la tasa de ingesta; referencia: 8 vCPU / 64 GiB de RAM, 1 TB NVMe SSD para retención de 90 días a 1.000 spans/seg; escale verticalmente primero y luego agregue réplicas de lectura.
  • Redis 6+ — Utilizado para cachés de corta duración y límites de tasa en el endpoint de ingesta.

Identidad y acceso​

  • Proveedor de identidad — AD on-prem (LDAP/LDAPS), Microsoft Entra ID, Okta o cualquier IdP OIDC. Se recomienda el mismo proveedor que el resto de la suite Beak AI.
  • Certificados TLS — Certificado firmado por la CA corporativa para el hostname de Observability.

Red y conectividad​

  • Endpoint de ingesta de trazas — Expuesto internamente en un subdominio dedicado (p. ej., observe-ingest.<corp-domain>); los pods de Studio/Runtime/Gateway envían a él.
  • No se requiere exposición pública — Observability puede ser completamente interno.
  • Sincronización de hora — NTP en todos los nodos (requerido para la ordenación de spans).

Secretos y cifrado​

  • Clave de cifrado — Utilizada para cifrar los cuerpos de prompts/completaciones en reposo en el almacenamiento de objetos. Se almacena en el almacén de secretos del clúster.
  • Política de copias de seguridad — Copia de seguridad definida por el cliente del clúster de PostgreSQL (con reconocimiento de TimescaleDB: use pg_dump para las tablas de configuración y timescaledb-backup de TimescaleDB o copias de seguridad base de PG para las hipertablas) y la clave de cifrado.

Licenciamiento​

  • Suscripción activa a AI Observability on-prem — Chart de Helm para el stack de streaming y el panel de control, imágenes de contenedor y derechos por tenant nombrado.
  • Opción air-gapped — Disponible; coordine con Éxito del Cliente.

Responsabilidades del cliente​

  • Operaciones de PostgreSQL (con TimescaleDB + pgvector) y Redis, o utilizar una oferta gestionada de cada uno.
  • Ciclo de vida de los certificados TLS.
  • Integración con el IdP y mapeo de acceso a proyectos.
  • Políticas de retención, copia de seguridad y recuperación ante desastres.
  • Planificación de capacidad a medida que crece el volumen de agentes.

Páginas relacionadas​