Distribuzione gestita nel tuo cluster Kubernetes

AgentEye è una piattaforma di osservabilità e valutazione self-hosted per agenti AI e LLM. Cattura sessioni di agenti, chiamate di strumenti, richieste di modelli ed errori, li trasforma in analitiche ricercabili e valutazioni, e presenta i risultati in un dashboard con un assistente AI opzionale di sola lettura. Nel modello di distribuzione gestita, fornisci un cluster Kubernetes dedicato ed Exosphere esegue l’intera piattaforma al suo interno, distribuendo, configurando, operando, effettuando backup e aggiornando ogni componente per tuo conto. Il tuo team ottiene il valore della piattaforma (visibilità degli agenti, analitiche, valutazione e l’assistente opzionale) senza operare database, certificati o aggiornamenti. Tutti i dati rimangono all’interno del tuo account cloud.

---

​

Prerequisiti

• Un GitHub PAT per il pull delle immagini container e il download degli artefatti (vedi enterprise-docs/github-token.md)
• Un cluster Kubernetes dedicato (vedi i requisiti di seguito)
• Un bucket di archiviazione per i backup del database
• Connettività di rete: porta 443 in ingresso al load balancer del cluster

---

​

Step 1: Provisioning di un cluster Kubernetes dedicato

Crea un cluster Kubernetes dedicato a AgentEye. Non dovrebbe essere condiviso con altri carichi di lavoro, in modo che l’intera piattaforma (servizi applicativi, database, analitiche e caching) venga eseguita in isolamento senza impattare l’infrastruttura esistente.

Exosphere installa e gestisce tutto il resto nel cluster: ingress controller, certificati TLS, database, caching, monitoraggio e tutti i deployment dell’applicazione.

---

​

Step 2: Concedi accesso al team di AgentEye

Exosphere ha bisogno dell’accesso cluster-admin (o equivalente ampio RBAC) per gestire namespace, custom resource definition, ingress controller e provisioner di archiviazione.

---

​

Step 3: Configura la connettività di rete

Il tuo team di rete deve consentire il traffico in ingresso sulla porta 443 ai load balancer del cluster. La distribuzione esegue due load balancer separati: uno per l’acquisizione degli eventi (protetto da mTLS) e uno per il dashboard: L’endpoint di acquisizione è protetto da mutual TLS; i collector devono presentare un certificato client valido e una chiave API valida in ogni richiesta. Il dashboard viene eseguito sul suo load balancer e hostname separati, con accesso limitato agli indirizzi email/domini in whitelist. Record DNS (una tantum): crei due record CNAME in un dominio che controlli — uno per l’endpoint di acquisizione e uno per il dashboard (ad es. agenteye.your-company.example) — puntando ai nomi host del load balancer che Exosphere fornisce. Exosphere quindi effettua il provisioning automatico di certificati TLS pubblicamente attendibili per entrambi gli hostname, inclusi i rinnovi.

Nota porta 80: la convalida e il rinnovo del certificato automatizzati si convalidano sulla porta 80 di ogni load balancer. Se il tuo profilo di sicurezza richiede di limitare il load balancer del dashboard a intervalli IP aziendali, comunica prima a Exosphere — commutiam la convalida del certificato a un metodo basato su DNS (un record DNS aggiuntivo dal tuo lato) in modo che i rinnovi continuino a funzionare dietro la restrizione.

In uscita: I nodi del cluster hanno bisogno dell’accesso a internet per eseguire il pull delle immagini container da ghcr.io. Se la tua rete limita il traffico in uscita, inserisci in whitelist ghcr.io o specchia le immagini nel tuo registro interno.

---

​

Step 4: Fornisci un bucket di archiviazione per i backup

I backup del database sono archiviati in un bucket di archiviazione cloud che possiedi. Un singolo backup giornaliero scarica sia PostgreSQL (stato relazionale) che ClickHouse (eventi e valutazioni) in un singolo archivio compresso e lo carica nel tuo bucket. I backup vengono eseguiti anche prima di ogni aggiornamento.

---

​

Step 5: Designa un punto di contatto

Fornisci una persona o un canale Slack/Teams dal tuo lato per i problemi a livello di cluster: salute dei nodi, limiti dell’account cloud, modifiche di rete. Le operazioni quotidiane non coinvolgono questo contatto.

---

​

Cosa distribuiamo

Una volta che Exosphere ha accesso al cluster, vengono distribuiti e gestiti i seguenti componenti: L’offerta gestita gestisce anche la pipeline di valutazione della piattaforma, che valuta l’attività degli agenti in base ai tuoi criteri di valutazione. Vedi enterprise-docs/assistant.md e enterprise-docs/evaluation-suite.md per quello che queste capacità forniscono.

---

​

Cosa ti forniamo

Dopo il completamento della distribuzione, ricevi:

---

​

Cosa fai dopo la configurazione

Il tuo unico lavoro continuativo è sulle tue macchine di agenti, non sul cluster AgentEye:

1. Installa il collector in ogni cluster Kubernetes che esegue agenti AI: monta il certificato client e configura l’URL dell’endpoint e la chiave API. Vedi enterprise-docs/collector-installation.md.
2. Integra l’SDK Python nel codice del tuo agente. Vedi enterprise-docs/python-sdk.md.
3. Apri il dashboard nel tuo browser per visualizzare l’attività degli agenti.

Nessuna operazione di cluster, nessuna gestione del database, nessun rinnovo di certificati, nessun aggiornamento.

---

​

Sicurezza

• I dati rimangono nel tuo account cloud. Il cluster, l’archiviazione e i database vengono tutti eseguiti nel tuo ambiente. Nessun dato esce dal tuo confine.
• Tu controlli l’accesso. Il cluster è nel tuo account. Puoi controllare, monitorare o revocare l’accesso di Exosphere in qualsiasi momento. Tutte le operazioni passano attraverso il registro di audit del tuo cloud (CloudTrail, GCP Audit Logs, ecc.).
• mTLS nell’acquisizione degli eventi. Ogni richiesta del collector richiede sia un certificato client valido che una chiave API. Una chiave persa è inutile senza il certificato; un certificato rubato è inutile senza una chiave valida.
• Controllo dell’accesso al dashboard. Il dashboard viene eseguito sul suo load balancer separato, separato dall’acquisizione degli eventi, e l’accesso è passwordless via OTP email limitato agli indirizzi email/domini in whitelist. Una whitelist di intervalli di origine IP sul load balancer è disponibile su richiesta; poiché il rinnovo del certificato automatizzato deve raggiungere il load balancer, Exosphere accoppia la restrizione con la convalida del certificato basata su DNS in modo che i rinnovi continuino a funzionare.
• Certificati per cluster. Ogni tuo cluster riceve il suo certificato client. Se un cluster viene compromesso, quel certificato viene revocato indipendentemente senza influire sugli altri.

---

​

Timeline di distribuzione

Totale tipico: ~2 settimane dal kickoff al pronto per la produzione.

---

​

Supporto

Per domande o problemi, contatta Exosphere all’indirizzo support@exosphere.host.

---

​

Prossimi passi

• Getting Started: procedura dettagliata end-to-end
• Collector Installation: installa e configura il collector
• Python SDK: strumenta il codice del tuo agente
• API Keys: gestisci accesso e permessi
• Troubleshooting: problemi comuni e fix