> ## Documentation Index > Fetch the complete documentation index at: https://docs.befailproof.ai/llms.txt > Use this file to discover all available pages before exploring further. # Deployment > AgentEye Deployment-Dokumentation. Diese Anleitung beschreibt das Deployment des AgentEye-Servers und Dashboards in der Produktion. *** ## Architekturübersicht ``` [ KI-Agent-Maschinen ] [ Ihre Infrastruktur ] Python SDK | schreibt JSONL +----------------------+ v +--->| PostgreSQL 15+ | agenteye-collector --HTTP--+ | | (relationale Ablage) | | | +----------------------+ v | +--------+ | +----------------------+ | Server |<------+--->| ClickHouse 24+ | +--------+ | | (Events / Analytik) | ^ | +----------------------+ API | | | | +----------------------+ +-----------+ +- - >| Redis 7+ (optional) | | Dashboard | +----------------------+ +-----------+ ``` * **Server**: Rust-HTTP-Dienst; empfängt Event-Batches, schreibt sie in ClickHouse und verwaltet den relationalen Zustand in PostgreSQL. * **Dashboard**: Next.js-Webanwendung; liest und schreibt ausschließlich über die Server-API. * **agenteye-collector**: wird auf Agent-Maschinen eingesetzt, nicht auf dem Server-Host. * **Postgres 15+**: ERFORDERLICH. (Ab Version 14 in der Multi-Tenant-Version angehoben; das Org-Mitgliedschaftsschema verwendet einen `ON DELETE SET NULL`-Fremdschlüssel mit Spaltenliste, der Postgres 15+ erfordert. Postgres vor der Bereitstellung dieser Version aktualisieren.) Speichert den OLTP-Zustand: `api_keys`, `users`, `sessions`, `evaluation_jobs` (Warteschlange), `dashboards`, `saved_queries`, `otp_codes` sowie die Multi-Tenant-Tabellen `orgs`, `org_memberships`, `org_settings`. * **ClickHouse 24+**: ERFORDERLICH. Der Analyse-Store für alle eingehenden Events. Engine: `ReplacingMergeTree`, nach Monat partitioniert, geordnet nach `(session_id, ts, dedup_key)`. Der Server verbindet sich über `CLICKHOUSE_URL`; die mitgelieferte `deploy/base/clickhouse/` enthält eine leistungsoptimierte Einzelknoten-Konfiguration. **Multi-Tenant-Anforderung:** Die mitgelieferte Konfiguration aktiviert SQL-Zugriffsverwaltung + `users_without_row_policies_can_read_rows=false`, damit der Server pro Organisation einen schreibgeschützten ClickHouse-Benutzer und eine Zeilenrichtlinie erstellen kann (die engine-seitig erzwungene Isolationsgrenze für den SQL-Editor und den KI-Agenten). Wenn Sie eine eigene ClickHouse-Konfiguration verwenden, übernehmen Sie diese Einstellungen (siehe `deploy/base/clickhouse/configmap.yaml`). * **Redis 7+**: *optional* als gemeinsamer Cache- und Rate-Limit-Backend. Server und Dashboard verbinden sich beide über `REDIS_URL`. Ist Redis nicht vorhanden, fallen beide auf Postgres-only-Pfade zurück. Siehe **Redis (optionaler Cache)** weiter unten. *** ## Server ### Image herunterladen ```bash theme={null} echo $AGENTEYE_TOKEN | docker login ghcr.io -u x --password-stdin docker pull ghcr.io/agenteye-enterprise/server:beta-latest ``` > Aktuelle Builds werden unter `beta-latest` veröffentlicht; `latest` wird nur stabilen Releases zugewiesen. Für die Produktion sollten Sie einen konkreten `:v`-Tag festlegen; siehe [Verfügbare Image-Tags](#available-image-tags). ### Umgebungsvariablen | Variable | Erforderlich | Standardwert | Beschreibung | | --------------------------------------------- | ----------------------------------------- | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `DATABASE_URL` | Ja | keiner | Postgres-DSN. Standard-libpq-Verbindungszeichenfolge mit Schema `postgres://`. Unterstützt `?sslmode=require` und andere libpq-Parameter. Das Passwort darf keine `/`, `+` oder `=` enthalten; verwenden Sie `openssl rand -hex` zum Generieren URL-sicherer Passwörter. | | `ADMIN_KEY` | Nein | keiner | Bootstrap-Admin-API-Schlüssel. Wird bei jedem Start mit allen Berechtigungen per Upsert gesetzt. Rotation durch Ändern des Werts und Neustart. | | `LISTEN_ADDR` | Nein | `0.0.0.0:8080` | TCP-Adresse zum Binden | | `MAX_BODY_BYTES` | Nein | `134217728` (128 MB) | Maximale Anfrage-Body-Größe | | `ADMIN_EMAIL` | Nein | keiner | Bootstrap-Admin-Benutzer-E-Mail. Wird bei jedem Start per Upsert mit allen Berechtigungen gesetzt und als geschützt markiert: kann weder deaktiviert noch über Dashboard/API in seinen Berechtigungen geändert werden. Um den Bootstrap-Admin zu wechseln, ändern Sie `ADMIN_EMAIL` und starten neu; die neue E-Mail-Adresse wird als geschützt per Upsert gesetzt, die vorherige behält ihren Schutz, bis er manuell in der Datenbank aufgehoben wird. | | `ALLOWED_EMAILS` | Nein | keiner (alle blockiert) | Kommagetrennte Liste erlaubter E-Mail-Adressen für Benutzererstellung und Anmeldung. Unterstützt exakte Adressen (`user@example.com`) und Domain-Wildcards (`*@example.com`). Wenn nicht gesetzt, können keine Benutzer erstellt werden oder sich anmelden. **Nur beim ersten Start:** Befüllt die Zulassungsliste der Standard-Org beim ersten Start; danach ist die Seite [`//settings`](#operational-settings) jeder Org die maßgebliche Quelle, und Änderungen dieser Umgebungsvariablen haben keine Wirkung mehr. | | `SMTP_HOST` | Nein | keiner | SMTP-Serverhostname für den Versand von OTP-E-Mails. Wenn nicht gesetzt, werden OTP-Codes stattdessen nach stdout geloggt. | | `SMTP_PORT` | Nein | `587` | SMTP-Serverport | | `SMTP_USERNAME` | Nein | keiner | SMTP-Authentifizierungs-Benutzername | | `SMTP_PASSWORD` | Nein | keiner | SMTP-Authentifizierungspasswort | | `SMTP_FROM` | Nein | keiner | Absender-E-Mail-Adresse für OTP-E-Mails | | `SMTP_TLS` | Nein | STARTTLS | STARTTLS wird verwendet, sofern nicht explizit deaktiviert: `false` oder `0` sendet Klartext (kein TLS); jeder andere Wert — einschließlich nicht gesetzt — aktiviert STARTTLS. | | `DASHBOARD_URL` | Nein | integrierter Standard | Dashboard-Ursprung zum Erstellen des OTP-E-Mail-Magic-Links sowie der Incident-Magic-Links in Alert-Benachrichtigungen. Wenn nicht gesetzt, fällt er auf einen integrierten Standard zurück (und bei OTP zuerst auf den vom Dashboard abgeleiteten Request-Ursprung). Setzen Sie dies für Split-Domain-Setups, damit E-Mail- und Slack/Incident-Links auf Ihr Dashboard zeigen. Siehe **E-Mail-Magic-Link-URL** weiter unten; die meisten Betreiber müssen dies nicht setzen. | | `SESSION_TTL_SECS` | Nein | `86400` (24 h) | Dashboard-Sitzungsdauer in Sekunden. **Nur beim ersten Start:** Nach dem ersten Deployment per Org über [`//settings`](#operational-settings) bearbeitbar. | | `OTP_TTL_SECS` | Nein | `600` (10 min) | OTP-Code-Gültigkeitsdauer in Sekunden. **Nur beim ersten Start:** Nach dem ersten Deployment per Org über [`//settings`](#operational-settings) bearbeitbar. | | `REDIS_URL` | Nein | keiner | Optionales gemeinsames Cache- und Rate-Limit-Backend, z. B. `redis://redis:6379/0`. Wenn gesetzt, cacht der Server authentifizierte API-Key-Lookups, das `/models`-Aggregat des Dashboards, die Session-Liste und die Env-List-Facette; außerdem wird das OTP-Request-Rate-Limiting von Postgres COUNT auf Redis INCR umgestellt. Wenn nicht gesetzt oder nicht erreichbar, läuft der Server ohne Cache (das OTP-Limit fällt auf Postgres zurück, alle anderen Cache-Aufrufe fallen auf die Quelle zurück). Siehe **Redis (optionaler Cache)** weiter unten. | | `CLICKHOUSE_URL` | **Ja** | keiner | Basis-URL der ClickHouse-Instanz, z. B. `http://clickhouse:8123`. Der Server wendet sein Events-Schema bei jedem Start auf diese Datenbank an und verweigert den Start, wenn ClickHouse nicht erreichbar ist. Siehe **ClickHouse (erforderlicher Analyse-Store)** weiter unten. | | `CLICKHOUSE_DATABASE` | Nein | `agenteye` | ClickHouse-Datenbankname (Schema). Der Server erstellt ihn beim Start, falls er nicht existiert. | | `ORG_CH_SECRET` | Nein (single-tenant) / **Ja (multi-org)** | Entwicklungsstandard | HMAC-Schlüssel, aus dem das ClickHouse-Passwort jedes Tenants pro Organisation abgeleitet wird. Der SQL-Editor und das `run_query` des KI-Agenten werden als schreibgeschützter ClickHouse-Benutzer der Org ausgeführt, dessen Zeilenrichtlinie die Tenant-Isolation in der Engine erzwingt. Single-Tenant-Deployments starten problemlos mit dem integrierten Entwicklungsstandard; **bevor Sie eine zweite Org anlegen, MÜSSEN Sie einen starken, stabilen Wert setzen**, da der CLI `agenteye-orgctl org create` die Ausführung mit dem integrierten Entwicklungsstandard verweigert. Eine Rotation führt dazu, dass alle ClickHouse-Benutzer der Org verwaisen, bis beim nächsten Start eine erneute Provisionierung erfolgt (der Boot-Zeit-Abgleich heilt dies automatisch). Halten Sie den Wert geheim und über alle Replikate hinweg unverändert. Die Org-Provisionierung selbst ist nur für Betreiber; siehe **Organisationen (Multi-Tenancy)** weiter unten. | | `DEFAULT_ORG_NAME` | Nein | `Default` | Anzeigename, der für die integrierte Standard-Org gesetzt wird. **Nur beim ersten Start** und nur solange die Org noch ihre frisch migrierte generische Identität trägt, wird er beim Start angewendet und danach ignoriert. Sobald Sie die Org umbenennen (`agenteye-orgctl org rename`), ist die Umbenennung maßgeblich und diese Umgebungsvariable hat keine weitere Wirkung. | | `DEFAULT_ORG_SLUG` | Nein | `default` | URL-Slug für die integrierte Standard-Org, der Dashboard-Pfad, unter dem sie erreichbar ist (`//…`). Gleiche Nur-beim-ersten-Start/nur-unberührt-Semantik wie `DEFAULT_ORG_NAME`. Muss 1–40 Kleinbuchstaben und Ziffern mit einzelnen internen Bindestrichen sein und darf kein [reserviertes Wort](#organizations-multi-tenancy) sein; ein ungültiger Wert wird ignoriert (die Org behält `default`). Ermöglicht es einem Single-Tenant-Install, z. B. unter `/acme` statt `/default` erreichbar zu sein, ohne einen Post-Deploy-CLI-Schritt. | | `RUST_LOG` | Nein | `info` | Log-Ausführlichkeit (`debug`, `warn`, `error`, `agenteye_server=trace`) | | `EVALUATOR_ENDPOINT` | Nein | keiner | Basis-URL Ihres Evaluator-Dienstes (z. B. `http://evaluator:9000`). Wenn nicht gesetzt, ist die gesamte Evaluierungspipeline ein No-op; es werden keine Queue-Zeilen geschrieben, keine Worker laufen. Siehe [Evaluation Suite](/de/agenteye/evaluation-suite). | | `EVALUATOR_TOKEN` | Nein | keiner | Wird als `Authorization: Bearer ` an den Evaluator gesendet. **Muss mit dem Wert übereinstimmen, mit dem der Evaluator-Dienst konfiguriert ist.** Nur optional, wenn Ihr Evaluator ohne Token konfiguriert ist. | | `EVALUATOR_WORKERS` | Nein | `2` | Parallelität: Anzahl der Worker-Tasks pro Server-Instanz, die Evaluierungen dispatchen. Kann sicher über mehrere horizontal skalierte Server ausgeführt werden. | | `EVALUATOR_CLAIM_BATCH` | Nein | `4` | Maximale Anzahl von Evaluierungen, die ein einzelner Worker pro Tick beansprucht. Batches werden **gleichzeitig** dispatcht, sodass die Gesamtparallelität an Ihrem Evaluator-Endpunkt `EVALUATOR_WORKERS × EVALUATOR_CLAIM_BATCH` beträgt. | | `EVALUATOR_POLL_IDLE_SECS` | Nein | `2` | Wie lange ein Worker zwischen Dispatch-Versuchen schläft, wenn nichts fällig ist. | | `EVALUATOR_POLLING_INTERVAL_SECS` | Nein | `10` | Endgültiger Fallback-Takt (Sekunden) für `GET /evaluate/{id}`-Polls, wenn der Evaluator weder ein `next_poll_secs` pro Response noch ein `default_poll_interval_secs` von `GET /config` zurückgibt. | | `EVALUATOR_REQUEST_TIMEOUT_MS` | Nein | `30000` | Pro-HTTP-Request-Timeout gegenüber dem Evaluator (Millisekunden). | | `EVALUATOR_MAX_ATTEMPTS` | Nein | `5` | Nach dieser Anzahl fehlgeschlagener Versuche wird eine Evaluierung als terminaler `error` (oder `timeout`, wenn die Fehler Request-Timeouts waren) erfasst. | | `EVALUATOR_CONFIG_REFRESH_SECS` | Nein | `300` (5 min) | Wie oft der Server `GET /config` vom Evaluator neu abruft. | | `EVALUATOR_MAX_POLL_DURATION_SECS` | Nein | `3600` (1 h) | Maximale Wall-Clock-Zeit, während der eine Session in der Poll-Warteschlange verbleiben darf, bevor AgentEye sie als `timeout` beendet. Schützt vor einem Evaluator, der dauerhaft `pending` zurückgibt. | | `ALERT_WORKERS` | Nein | `1` | Parallelität: Anzahl der Worker-Tasks pro Server-Instanz, die Alert-Regeln auswerten. Siehe [Alerts](/de/agenteye/alerts). | | `ALERT_CLAIM_BATCH` | Nein | `16` | Maximale Anzahl von Alerts, die ein einzelner Worker pro Tick beansprucht. | | `ALERT_POLL_IDLE_SECS` | Nein | `5` | Wie lange ein Alerts-Worker schläft, wenn die Warteschlange leer ist. | | `ALERT_REQUEST_TIMEOUT_MS` | Nein | `15000` | Pro-Trigger-Auswertungs-Timeout (ClickHouse-Abfragen + ausgehende Kanal-HTTP). | | `ALERT_MAX_ATTEMPTS` | Nein | `5` | Aufeinanderfolgende transiente Fehler, bevor ein Alert nach normalem Takt statt exponentiellem Backoff neu geplant wird. | | `AUDIT_WORKERS` | Nein | `1` | Parallelität: Anzahl der Worker-Tasks pro Server-Instanz, die Audits ausführen. Siehe [Audits](/de/agenteye/audits). | | `AUDIT_CLAIM_BATCH` | Nein | `1` | Maximale Anzahl fälliger Audits, die ein einzelner Worker pro Tick beansprucht. Eine agentische Untersuchung ist eine lange Schleife, daher ist der Standard 1. | | `AUDIT_POLL_IDLE_SECS` | Nein | `30` | Wie lange ein Audits-Worker schläft, wenn kein Audit fällig ist. | | `AUDIT_REQUEST_TIMEOUT_MS` | Nein | `30000` | Pro-Policy-Query-Timeout gegenüber ClickHouse (Millisekunden). | | `AUDIT_LLM_TIMEOUT_MS` | Nein | `1440000` | Timeout für den agentischen Untersuchungsaufruf an den KI-Assistenten-Dienst. Ein vollständiger Agent-Loop läuft mehrere Minuten; halten Sie diesen Wert ÜBER dem eigenen `AGENTEYE_AUDIT_TIMEOUT_MS` des Agenten, damit der Agent seine Teilergebnisse zurückgibt, bevor der Server aufgibt. | | `AUDIT_MAX_ATTEMPTS` | Nein | `5` | Aufeinanderfolgende transiente Fehler, bevor ein Audit nach normalem Takt statt exponentiellem Backoff neu geplant wird. | | `AGENTEYE_AGENT_URL` / `AGENTEYE_AGENT_TOKEN` | Nein | — | Die agentische Untersuchung des Audits ruft den KI-Assistenten-`agent`-Dienst auf und **nutzt dabei dieselbe Verbindung wie der Assistent** — setzen Sie diese beiden also auch auf dem **Server** (die mitgelieferten Manifeste/Compose tun das). Beide gesetzt ⇒ Audits führen die KI-Untersuchung durch; eines fehlt ⇒ Audits laufen **nur mit Policy** (der deterministische SQL-Policy-Pass läuft trotzdem), unabhängig vom `llm_enabled`-Flag des Audits. Der Agent muss außerdem ein LLM konfiguriert haben — siehe [assistant.md](/de/agenteye/assistant). | **KI-Assistenten-Dienst — Audit- und Sandbox-Einstellungen.** Die agentische Untersuchung und ihre In-Pod-Python-Sandbox werden auf dem **Agent-Dienst** (nicht dem Server) konfiguriert, alle mit dem Präfix `AGENTEYE_AUDIT_*` und alle optional: | Variable | Standard | Bedeutung | | --------------------------------------------------------------------------------------------------------- | ------------------------------------------ | ---------------------------------------------------------------------------------------------------------- | | `AGENTEYE_AUDIT_MAX_STEPS` | `200` | Maximale Agenten-Turns pro Untersuchung. | | `AGENTEYE_AUDIT_TIMEOUT_MS` | `1200000` | Wall-Clock für eine Untersuchung (20 Min.). Muss **unter** dem `AUDIT_LLM_TIMEOUT_MS` des Servers bleiben. | | `AGENTEYE_AUDIT_MAX_CONCURRENCY` | `1` | Gleichzeitige Untersuchungen pro Agent-Pod (getrennt vom Budget des Chat-Assistenten). | | `AGENTEYE_AUDIT_SANDBOX_TIMEOUT_MS` / `_MEM_MB` / `_CPU_SECS` / `_OUTPUT_MAX_BYTES` / `_SCRIPT_MAX_BYTES` | `20000` / `768` / `10` / `64000` / `64000` | Pro-Skript-Limits für die Bubblewrap-Sandbox. | **Sandbox-Plattformanforderung.** Die Audit-Code-Sandbox führt das Python des Modells in einem Bubblewrap-Jail aus, das **unprivilegierte User-Namespaces** benötigt. Der Agent-Pod muss die `clone()`-Flags erlauben — setzen Sie `seccompProfile: Unconfined` (k8s) oder `security_opt: [seccomp:unconfined]` (compose) auf dem Agenten. Wenn der Node-Kernel unprivilegierte User-Namespaces deaktiviert (z. B. bei einigen GKE-COS-Images), **schlägt der Sandbox-Preflight fehl und der Auditor degradiert automatisch auf SQL-only** — kein Fehler, nur `sandbox_available: false` im `/health` des Agenten. ### Starten Setzen Sie `DATABASE_URL` in Ihrer Umgebung und übergeben Sie es dann an den Container: ```bash theme={null} docker run -d --restart unless-stopped \ --name agenteye-server \ -e DATABASE_URL="$DATABASE_URL" \ -e ADMIN_KEY="$ADMIN_KEY" \ -p 8080:8080 \ ghcr.io/agenteye-enterprise/server:beta-latest ``` Der Server führt Datenbankmigrationen automatisch beim Start durch; kein separater Migrationsschritt erforderlich. ### Health-Check ``` GET /health # Liveness - immer {"status":"ok"} sobald der Prozess läuft GET /ready # Readiness - 200 wenn Postgres + ClickHouse erreichbar, sonst 503 ``` Keine Authentifizierung erforderlich. Verwenden Sie `/health` für **Liveness**-Probes und `/ready` für **Readiness**-/Load-Balancer-Probes. `/ready` prüft die harten Abhängigkeiten, ohne die der Server nicht bedienen kann (Postgres + ClickHouse), sodass ein laufender Server, der seine Datenbank nicht erreicht, aus der Rotation genommen und als `NotReady` angezeigt wird; Redis wird gemeldet, schlägt aber nie bei der Readiness-Prüfung fehl. In den mitgelieferten Kubernetes-Manifesten zeigt die Readiness-Probe bereits auf `/ready`, während Liveness auf `/health` bleibt. Siehe [enterprise-docs/health-monitoring.md](/de/agenteye/health-monitoring) für das vollständige Bild, einschließlich optionalem Kubernetes-nativen Pod-Fehler-Alerting an Slack. ### E-Mail-Magic-Link-URL OTP-Login-E-Mails enthalten eine Ein-Tap-Schaltfläche **Dashboard öffnen**. Ein Klick darauf bringt den Benutzer auf `/login?token=&email=
`; das Dashboard tauscht dieses Paar gegen eine Session aus und leitet zur App weiter, ohne manuelle Code-Eingabe. Der Server löst den Dashboard-Ursprung für den Link-Aufbau in drei Ebenen auf: 1. **`X-AgentEye-Dashboard-Url`-Header**: Wird automatisch vom `/api/auth/otp/request`-Proxy des Dashboards aus seinem eigenen öffentlichen Ursprung gesetzt. In einem Same-Origin-Deployment (Server und Dashboard teilen sich einen Host hinter einem Ingress, der Proxy-Header weiterleitet) **ist keine Konfiguration erforderlich**. 2. **`DASHBOARD_URL`-Umgebungsvariable**: Setzen Sie diese, wenn Ihr Dashboard auf einem anderen Ursprung erreichbar ist als dem, den der OTP-Request-Endpunkt des Servers sieht (getrennte `api.example.com` / `app.example.com`), oder wenn Ihr Ingress den öffentlichen Host nicht in den Dashboard-Pod weiterleitet (sodass `request.nextUrl.origin` sonst auf eine Wildcard-Bind-Adresse wie `0.0.0.0:3000` aufgelöst würde). Beispiel: `DASHBOARD_URL=https://app.example.com`. 3. **Standard**: `https://app.befailproof.ai`, wird nur verwendet, wenn keines der oben genannten vorhanden ist. Der Header-Wert wird validiert: Nur `https://*`- und Loopback-(`http://localhost*`, `http://127.0.0.1*`)-Ursprünge werden akzeptiert, und Wildcard-Bind-Adressen (`0.0.0.0`, `[::]`) werden auch mit dem `https://`-Schema abgelehnt. Alles andere fällt auf Ebene 2 zurück. Setzen Sie es auf einem laufenden Cluster mit einem Einzeiler; keine Datei, kein Kustomize-Rebuild: ```bash theme={null} kubectl set env deployment/server -n agenteye \ DASHBOARD_URL=https://app.example.com ``` Dies löst ein Rollout aus; die neuen Pods übernehmen den Wert beim ersten Request. Beachten Sie, dass das Override nur im Deployment lebt; ein nachfolgendes `kustomize build | kubectl apply` gegen den Overlay löscht es, sofern Sie dieselbe Umgebungsvariable nicht in den `server-env.yaml`-Patch Ihres Overlays aufnehmen. *** ## Dashboard ### Image herunterladen ```bash theme={null} docker pull ghcr.io/agenteye-enterprise/dashboard:beta-latest ``` ### Umgebungsvariablen | Variable | Erforderlich | Standardwert | Beschreibung | | ----------------------- | ------------ | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `AGENTEYE_SERVER_URL` | Ja | keiner | Basis-URL des Servers, z. B. `http://localhost:8080` | | `AGENTEYE_API_KEY` | Ja | keiner | API-Schlüssel, den das Dashboard zur Authentifizierung gegenüber dem Server verwendet. Benötigt alle Berechtigungen (Admin-Schlüssel empfohlen). | | `AE_LOG_LEVEL` | Nein | `info` | Server-seitige Log-Ausführlichkeit: `debug`, `info`, `warn`, `error`. Auf `debug` setzen, um Upstream-Request/Response-Zeilen und Session-Validierungs-Traces bei der Diagnose zu sehen. | | `AE_LOG_JSON` | Nein | auto | `1` erzwingt JSON-per-Zeile-Ausgabe; `0` erzwingt menschenlesbare Ausgabe. Wenn nicht gesetzt, wird JSON automatisch aktiviert, wenn `NODE_ENV=production`. JSON wird in der Produktion empfohlen, damit Logs mit `jq` oder einem Log-Aggregator sauber geparst werden können. | | `AE_ANALYTICS_DISABLED` | Nein | keiner | Auf `1`/`true` setzen, um die anonyme Produktnutzungs-Telemetrie des Dashboards zu deaktivieren. Siehe [Telemetrie & Datenschutz](#telemetry--privacy) weiter unten. | | `REDIS_URL` | Nein | keiner | Optionales gemeinsames Cache-Backend, z. B. `redis://redis:6379/0`. Wenn gesetzt, cacht das Dashboard `validateSession()`-Ergebnisse über Replikate hinweg und teilt den Next.js-Fetch-Cache für die Latenz-Aggregat-/Env-List-Proxy-Routen. Edge-seitige OTP-Request- und Verify-Rate-Limits verwenden ebenfalls Redis, wenn vorhanden (offen fallend, wenn Redis nicht erreichbar; das serverseitige Limit ist der Sicherheits-Backstop). Siehe **Redis (optionaler Cache)** weiter unten. | | `AGENTEYE_AGENT_URL` | Nein | keiner | Basis-URL des optionalen KI-Assistenten-`agent`-Dienstes, z. B. `http://agent:9100`. **Nicht setzen, um den Assistenten vollständig auszublenden**: Im Dashboard erscheint keine Assistent-Blase. Siehe [enterprise-docs/assistant.md](/de/agenteye/assistant). | | `AGENTEYE_AGENT_TOKEN` | Nein | keiner | Gemeinsames Geheimnis, das das Dashboard dem `agent`-Dienst präsentiert. Muss mit dem auf dem Agenten konfigurierten `AGENTEYE_AGENT_TOKEN` übereinstimmen. Siehe [enterprise-docs/assistant.md](/de/agenteye/assistant). | ### Starten ```bash theme={null} docker run -d --restart unless-stopped \ --name agenteye-dashboard \ -e AGENTEYE_SERVER_URL="http://your-server-host:8080" \ -e AGENTEYE_API_KEY="$ADMIN_KEY" \ -p 3000:3000 \ ghcr.io/agenteye-enterprise/dashboard:beta-latest ``` ### Telemetrie & Datenschutz Das Dashboard sendet **anonyme Produktnutzungs-Analytics** an den Analytics-Dienst von Exosphere (PostHog): welche Dashboard-Seiten aufgerufen werden und eine Handvoll UI-Aktionen wie das Erstellen eines API-Schlüssels oder das Neubewerten einer Session. Dieses Nutzungssignal gibt Aufschluss darüber, welche Features priorisiert werden. * **Keine Agenten-, Session- oder Event-Daten verlassen je Ihre Infrastruktur.** Nur die Dashboard-UI-Nutzung wird gemeldet. Seiten-URLs werden vor dem Senden von Identifikatoren bereinigt, und Betreiber werden nur durch eine undurchsichtige interne ID identifiziert, niemals per E-Mail. * Telemetrie ist **standardmäßig aktiviert**. Um sie vollständig zu deaktivieren, setzen Sie `AE_ANALYTICS_DISABLED=1` auf dem Dashboard-Container und starten neu. * Analytics werden an den eigenen `/ingest`-Pfad des Dashboards gesendet, den das Dashboard als Reverse-Proxy an PostHog (`https://us.i.posthog.com`) weiterleitet. Anfragen zunächst first-party zu halten bedeutet, dass Browser-Werbeblocker sie nicht blockieren. Der **Dashboard-Container** benötigt ausgehenden Zugriff auf PostHog; wenn dieser blockiert ist, funktioniert die Telemetrie still nicht und das Dashboard ist nicht beeinträchtigt. *** ## KI-Assistent (optional) Ein im Dashboard integrierter KI-Assistent ermöglicht es Ihrem Team, Fragen zu ihren Agent-Daten in natürlicher Sprache zu stellen (Sessions zusammenfassen, SQL für den `/queries`-Editor entwerfen und gespeicherte Abfragen in Dashboard-Kacheln umwandeln), ohne das Dashboard zu verlassen. Er läuft als separater interner `agent`-Container (auf dem Claude Agents SDK), der nur vom Dashboard erreichbar ist, und bleibt **deaktiviert, bis Sie einen LLM-Endpunkt konfigurieren**. Um ihn zu aktivieren, setzen Sie auf dem `agent`-Dienst eine LLM-Verbindung (**Portkey** über `PORTKEY_API_KEY` + einen Modell-Katalog-Slug `AGENTEYE_AGENT_MODEL=@/`, direktes Anthropic über `ANTHROPIC_API_KEY`, ein anderes Gateway über `ANTHROPIC_BASE_URL`, oder Bedrock/Vertex), einen **dedizierten** Datenschlüssel und ein gemeinsames `AGENTEYE_AGENT_TOKEN`, das mit dem Dashboard übereinstimmt. Dashboard-Benutzer benötigen außerdem die `agent:use`-Berechtigung. Für den Datenschlüssel des Assistenten müssen Sie nichts manuell anlegen: Wählen Sie ein zufälliges Geheimnis, setzen Sie es als `AGENTEYE_API_KEY` auf dem `agent` **und** als `AGENT_API_KEY` auf dem `server`, und der Server befüllt es beim Start mit einem festen Berechtigungssatz. Sein Datenzugriff ist schreibgeschützt (`events:read`, `evaluations:read`, `dashboards:read`, `queries:read`), und er besitzt zusätzlich genehmigungsgepflegte Authoring-Scopes (`dashboards:write`, `queries:write`, `queries:run`), damit er gespeicherte Abfragen entwerfen und validieren sowie Dashboard-Kacheln im Auftrag des Benutzers erstellen kann; alle SQL-Abfragen laufen weiterhin über die schreibgeschützte ClickHouse-Rolle der Org, sodass dies erweitert, was der Assistent erstellen kann, nicht welche Daten er erreichen kann. Die Scopes sind im Code festgelegt und können nicht durch Konfiguration erweitert werden. Dieser Schlüssel ist geschützt; er kann nicht über die API deaktiviert oder regeneriert werden, nur durch Ändern des Werts und Neustart rotiert werden. Verwenden Sie niemals den Admin-/Dashboard-Schlüssel dafür. Vollständige Einrichtung, die vollständige Umgebungsvariablen-Referenz, Telemetrie-Optionen und das Sicherheitsmodell finden Sie in **[enterprise-docs/assistant.md](/de/agenteye/assistant)**. *** ## ClickHouse (erforderlicher Analyse-Store) ClickHouse hält Ihre Dashboards bei hohen Event-Volumina reaktionsfähig und ermöglicht es dem `/queries`-SQL-Editor, Events, Evaluierungen und Sessions in einem einzigen Store zu verknüpfen. Es ist der erforderliche kanonische Store für alle eingehenden Events, alle terminalen Evaluierungsergebnisse und die abgeleiteten Per-Session-Aggregate. PostgreSQL enthält die relationalen/veränderlichen Zustandstabellen (api\_keys, users, otp\_codes, evaluation\_jobs, dashboards, saved\_queries); die analytische Oberfläche lebt in ClickHouse, damit die Dashboard-Rollups und Ihre eigenen SQL-Abfragen sie nativ scannen und verknüpfen können, ohne datenbankübergreifende Round-Trips. Der Server verweigert den Start ohne `CLICKHOUSE_URL`. ### Schema Beim Server-Start werden drei ClickHouse-Objekte erstellt, alle idempotent (`CREATE IF NOT EXISTS`): * **`agenteye.events`**: `ReplacingMergeTree(ingested_at)`, partitioniert nach `toYYYYMM(ts)`, geordnet nach `(session_id, ts, dedup_key)`. Doppelte Einfügungen (Collector-Wiederholungen) werden beim Merge auf eine einzelne Zeile reduziert; der Server berechnet einen deterministischen SHA-256-`dedup_key` für jedes Event, sodass Wiederholungen sicher sind. * **`agenteye.evaluations`**: `ReplacingMergeTree(ingested_at)`, partitioniert nach `toYYYYMM(finished_at)`, geordnet nach `(session_id, finished_at, dedup_key)`. Einmal pro terminalem Evaluierungsergebnis durch die Evaluierungspipeline geschrieben. Gleiches Dedup-Key-Modell wie `events`. * **`agenteye.agent_sessions`**: ein **VIEW** über `agenteye.events`, keine physische Tabelle. Jede Spalte wird abgeleitet (`started_at = min(ts)`, `last_event_at = max(ts)`, `ended_at = max(if event_type='agent_end', ts, NULL)`, `event_count = count()`, usw.). Kein Pro-Event-Upsert und kein separates Backfill; der View reflektiert automatisch, was in `events` enthalten ist. Für Rückwärtskompatibilität mit gespeicherten Abfragen, die `analytics.evaluations` / `analytics.sessions` referenzieren, erstellt der Server außerdem eine `analytics`-ClickHouse-Datenbank mit Views über die `agenteye.*`-Tabellen; `analytics.events`, `analytics.evaluations`, `analytics.agent_sessions`, `analytics.sessions` werden alle korrekt aufgelöst. ### Konfiguration Das mitgelieferte docker-compose und `deploy/base/clickhouse/` liefern einen für AgentEye's Workload optimierten ClickHouse-Dienst: * 2 GiB angefordert / 4 GiB Limit Arbeitsspeicher im mitgelieferten Base-Overlay (für kleine POC/Staging-Knoten dimensioniert); Produktionskunden sollten aufwärts skalieren — der empfohlene Mindestbedarf ist 2c / 4Gi Request, 6c / 8Gi Limit. `max_server_memory_usage_to_ram_ratio=0.9` * 5 GiB Mark-Cache + 8 GiB unkomprimierter Cache * `background_pool_size=16`, `background_merges_mutations_concurrency_ratio=2` * MergeTree: `parts_to_throw_insert=3000`, `parts_to_delay_insert=1500`, `non_replicated_deduplication_window=1000` * `local_io_method=auto` (io\_uring auf unterstützten Kerneln) * `fsync_metadata=0`: akzeptabel wegen At-Least-Once-Ingest + ReplacingMergeTree-Dedup * `query_log` aktiviert mit 30-Tage-TTL; `query_thread_log` entfernt (teuer bei hohem QPS) * `max_execution_time=30` für benutzerseitige Abfragen * 100 GiB PVC im StatefulSet-Template (Kunden-Overlays SOLLTEN dies für die Produktion auf eine schnelle SSD-Storage-Class überschreiben) ### Backups Ihr vollständiger Datensatz wird nächtlich in einem einzelnen wiederherstellbaren Archiv gesichert, sodass ein Cluster- oder Speicherverlust behebbar ist. ClickHouse wird automatisch durch den täglichen `agenteye-backup`-CronJob gesichert, der PostgreSQL und ClickHouse in einem Durchgang sichert. ClickHouse wird über seine HTTP-API gelesen: `agenteye.events` und `agenteye.evaluations` werden im ClickHouse-nativen Format gesichert (die Views und Zeilenrichtlinien werden beim Server-Start neu erstellt, sodass die Tabellendaten das vollständige Bild sind) und zusammen mit dem Postgres-Dump in ein einzelnes komprimiertes Archiv gebündelt, das in Ihren Objektspeicher hochgeladen wird. Ziel-Bucket und Cloud-Anmeldedaten werden pro Overlay konfiguriert. Siehe den Abschnitt **Backups** in [enterprise-docs/kubernetes-deployment.md](/de/agenteye/kubernetes-deployment) für Upload-Konfiguration und Wiederherstellungsschritte. *** ## Redis (optionaler Cache) Redis ist ein **optionales** gemeinsames Cache- und Rate-Limit-Backend, das von Server und Dashboard verwendet wird. Mit Redis und gesetztem `REDIS_URL` auf beiden Diensten: * **Server** cacht authentifizierte API-Key-Lookups, die `/events/environments`- und `/evaluations/environments`-Listen, das `/events/latency_aggregate`-Rollup (die schwerste Abfrage, die das Dashboard pollt), die `/sessions`-Liste und wechselt das OTP-Request-Rate-Limiting von Postgres `COUNT(*)` zu Redis `INCR + EXPIRE`. * **Dashboard** cacht `validateSession()`-Ergebnisse, damit die 10–20 authentifizierten API-Aufrufe, die ein typischer Seitenaufruf ausgibt, alle eine gemeinsame Upstream-Session-Prüfung teilen. Es begrenzt außerdem OTP-Request und OTP-Verify am Dashboard-Edge per Rate-Limiting. **Beide Dienste degradieren graceful, wenn Redis nicht erreichbar ist.** Jeder Cache-Aufruf gibt innerhalb eines begrenzten Timeouts `Err` zurück und der Aufrufer fällt auf die Quelle zurück (Postgres auf dem Server, der upstream Rust-Server auf dem Dashboard). OTP-Rate-Limiting fällt auf dem Server auf den Postgres-`COUNT(*)`-Pfad zurück (die Sicherheitseigenschaft bleibt erhalten); das Edge-OTP-Limit des Dashboards fällt offen, während das serverseitige Limit weiterhin gilt. Redis-Ausfall verschlechtert die Latenz, nicht die Korrektheit. ### Konfiguration Das docker-compose-Bundle enthält bereits einen Redis-Dienst und verdrahtet `REDIS_URL=redis://redis:6379/0` in Server und Dashboard. Um ein externes Redis zu verwenden, setzen Sie `REDIS_URL` auf Ihren Endpunkt und entfernen Sie den `redis`-Dienst aus der Compose-Datei. ### Arbeitsspeicher und Persistenz Das mitgelieferte Redis-Image läuft mit `--appendonly yes --appendfsync everysec --maxmemory 256mb --maxmemory-policy allkeys-lru`. AOF-Persistenz bedeutet, dass der Cache Container-Neustarts überlebt; `everysec` ist die richtige Balance zwischen Haltbarkeit und Leistung, da der Verlust der letzten Sekunde an Cache-Schreibvorgängen harmlos ist. LRU-Eviction begrenzt das Speicherwachstum. ### Wann Redis NICHT eingesetzt werden sollte * Einzelinstanz-Dev/QA. Die In-Process-Caches des Servers allein liefern den größten Per-Replikat-Vorteil; Redis fügt das Cross-Replikat-Sharing hinzu, das Einzelinstanz-Setups nicht benötigen. * Air-Gapped-Installationen, bei denen der Betriebsaufwand für einen weiteren Dienst den Latenz-Gewinn überwiegt. *** ## Docker Compose (empfohlen) Eine `docker-compose.yml` ist im `agenteye-enterprise/releases`-Repository verfügbar. Sie startet Postgres, den Server und das Dashboard mit einem einzigen Befehl. ```bash theme={null} GITHUB_TOKEN=$AGENTEYE_TOKEN gh release download \ --repo agenteye-enterprise/releases \ --pattern 'docker-compose.yml' \ --dir ./agenteye cd agenteye ``` **Standards über `.env` überschreiben:** ``` # Verwenden Sie URL-sichere Passwörter (keine /, + oder = Zeichen). # Generieren mit: openssl rand -hex 24 POSTGRES_PASSWORD=ihr-db-passwort ADMIN_KEY=ihr-admin-geheimnis # Dashboard-Authentifizierung ADMIN_EMAIL=admin@ihrefirma.com ALLOWED_EMAILS=*@ihrefirma.com # SMTP für OTP-E-Mails (weglassen, um OTP-Codes nach stdout zu loggen) # SMTP_HOST=smtp.ihranbieter.com # SMTP_PORT=587 # SMTP_USERNAME=ihr-smtp-benutzer # SMTP_PASSWORD=ihr-smtp-passwort # SMTP_FROM=noreply@ihrefirma.com RUST_LOG=info ``` ```bash theme={null} docker compose up -d ``` **Stoppen (behält Datenvolume):** ```bash theme={null} docker compose down ``` **Stoppen und alle Daten löschen:** ```bash theme={null} docker compose down -v ``` *** ## Betriebseinstellungen Eine kleine Gruppe betrieblicher Einstellungen, die früher durch Umgebungsvariablen festgelegt waren, sind jetzt pro Organisation über die **`//settings`**-Seite des Dashboards bearbeitbar; jede Org konfiguriert ihre eigenen. Änderungen werden innerhalb von Sekunden wirksam, ohne Neustart und ohne erneutes Deployment. | Einstellung | Bootstrap-Umgebungsvariable | Was sie steuert | | ------------------------------- | --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Erlaubte Anmeldungen | `ALLOWED_EMAILS` | E-Mails (oder `*@domain.com`-Wildcards), die berechtigt sind, ein OTP zu empfangen und als Benutzer hinzugefügt zu werden | | Standard-Benutzerberechtigungen | `DEFAULT_USER_PERMISSIONS` | Kommagetrennte Berechtigungs-Token, die vorausgewählt sind, wenn ein Admin **+ neuer Benutzer** öffnet. Jedes Token muss einer der unter [API-Schlüsselberechtigungen](/de/agenteye/api-keys) aufgelisteten Zeichenfolgen entsprechen. Standardmäßig das `standard`-Preset: schreibgeschützter Zugriff plus die alltäglichen On-Call-Aktionen (Re-Evaluierungen auslösen, Abfragen ausführen, Incidents bestätigen, den Assistenten nutzen). | | Sitzungsdauer | `SESSION_TTL_SECS` | Wie lange ein Dashboard-Login gültig bleibt, bevor eine erneute Authentifizierung erforderlich ist. Das Dashboard prüft die Upstream-Session alle 5 Sekunden, sodass eine Berechtigungsänderung unter `//users` beim nächsten Request des betroffenen Benutzers wirksam wird, ohne erneute Anmeldung. | | Einmalcode-Dauer | `OTP_TTL_SECS` | Wie lange ein OTP / Magic-Link verwendbar bleibt | | Alert-Benachrichtigungskanäle | `ALERTS_ENABLED_CHANNELS` | Kommagetrennte Liste von Kanal-Arten, die der Alert-Dispatcher verwenden darf: `email`, `slack`, `webhook`. Die Per-Alert-Konfiguration wird weiterhin unter `//alerts/` erstellt, aber der Dispatcher filtert jede ausgehende Zustellung durch diesen Satz; ein hier deaktivierter Kanal schließt mit einer `skipped_disabled`-Audit-Zeile kurz. Der `dashboard`-Kanal (der lokale Audit-Insert) ist immer erlaubt. Standardmäßig alle drei aktiviert. | ### Wie der Bootstrap funktioniert Einstellungen werden pro Organisation in `org_settings` gespeichert. Beim ersten Start befüllt der Server die fehlenden Zeilen der Standard-Org aus der entsprechenden Umgebungsvariablen (oder einem sinnvollen Standard, wenn die Umgebungsvariable nicht gesetzt ist). Danach **ist der gespeicherte Wert die maßgebliche Quelle und die Umgebungsvariable wird ignoriert**; das Ändern der Umgebungsvariablen bei einem späteren Neustart wirkt sich nicht auf den Wert einer aktiven Org aus, und zusätzliche Orgs starten mit Standardwerten und konfigurieren ihre eigenen. Das bedeutet: * Für ein frisches Deployment setzen Sie die Umgebungsvariablen wie oben gezeigt, und die Standard-Org liest sie beim ersten Start. * Um einen Wert später zu ändern, melden Sie sich im Dashboard an und bearbeiten ihn unter `//settings`. Die Änderung gilt innerhalb von Sekunden über alle Server-Replikate; kein Neustart erforderlich. * Eine Start-Log-Zeile zeichnet auf, was gesetzt wurde gegenüber was bereits vorhanden war, sodass Sie bestätigen können, dass der Bootstrap wirksam wurde: ```text theme={null} INFO settings bootstrap: seeded default-org row key=allowed_sign_ins env_var=ALLOWED_EMAILS seeded_from_env=true ``` #### Anmeldesemantik über Organisationen hinweg Eine Session und ein OTP sind global für den Benutzer, nicht für eine einzelne Org, sodass zwei Regeln die Pro-Org-Einstellungen bei der Anmeldung abstimmen: * **Session- / OTP-Dauer**: Die strengste (kürzeste) Dauer unter den Orgs, zu denen der Benutzer gehört, gewinnt. * **Erlaubte Anmeldungen**: Das Gate verbindet jede Org-Zulassungsliste per ODER mit der Org-Mitgliedschaft: Ein Benutzer darf ein OTP anfordern, wenn die Zulassungsliste einer beliebigen Org seine E-Mail-Adresse zulässt **oder** er bereits Mitglied einer beliebigen Org ist. ### Berechtigungen Der Zugriff auf eine `//settings`-Seite ist durch zwei Berechtigungen geschützt: * `settings:read`: Seite und aktuelle Werte anzeigen. * `settings:write`: Änderungen speichern. Der Bootstrap-Admin-Benutzer (aus `ADMIN_EMAIL` gesetzt) erhält automatisch beide zusammen mit allen anderen Berechtigungen. Anderen Benutzern können sie bei Bedarf unter `//users` gewährt werden. *** ## Organisationen (Multi-Tenancy) Ein einzelnes Deployment kann mehrere isolierte **Organisationen** (Tenants) bedienen; jede Datenzeile gehört genau einer Org, und die Isolation wird in der Datenbank-Engine erzwungen. Eine Single-Tenant-Installation benötigt hier nichts; alle Daten leben in einer integrierten `default`-Org. (Sie können dieser Org einen freundlicheren Namen und URL-Slug geben, sodass sie z. B. unter `/acme` statt `/default` erreichbar ist, indem Sie `DEFAULT_ORG_NAME` / `DEFAULT_ORG_SLUG` vor dem ersten Start setzen oder sie jederzeit mit `agenteye-orgctl org rename` umbenennen.) **Tenant-Provisionierung ist nur für Betreiber.** Organisationen und ihre Mitgliedschaften werden mit dem **`agenteye-orgctl`**-CLI erstellt und verwaltet, das **innerhalb des Server-Images** (neben `agenteye-server`) ausgeliefert wird und **innerhalb des vorhandenen Server-Pods** läuft; es gibt **keinen separaten Pod/Job, keine HTTP-API und keinen Dashboard-Button**. Es nutzt die `DATABASE_URL`, `CLICKHOUSE_URL` und `ORG_CH_SECRET` des Servers. ```bash theme={null} # Docker Compose - in den laufenden Server-Dienst hineinwechseln: docker compose exec server agenteye-orgctl org create --slug acme --name "Acme Corp" docker compose exec server agenteye-orgctl member add --org acme --email alice@acme.example --set admin # Kubernetes - in das laufende Server-Deployment hineinwechseln: kubectl -n agenteye exec deploy/server -- agenteye-orgctl org list ``` Verfügbare Verben: `org create | list | rename | delete | purge` und `member add | list | update | remove`, mit integrierten Berechtigungs-Sets `admin`, `standard` und `read-only`. Hinzugefügte Mitglieder erhalten beim ersten Dashboard-Login ein OTP. **Bevor Sie eine zweite Org erstellen:** Setzen Sie ein starkes, stabiles `ORG_CH_SECRET` (der `org create`-Befehl verweigert die Ausführung mit dem integrierten Entwicklungsstandard) und stellen Sie sicher, dass Postgres **15+** ist. **Unverändert:** Per-Org-API-Schlüssel werden weiterhin im Dashboard/API durch Org-Mitglieder erstellt; nur der Org- und Mitglieds-Lebenszyklus wurde in den CLI verschoben. Vollständige Befehlsreferenz und ein ausgearbeitetes Beispiel: **[enterprise-docs/tenant-management.md](/de/agenteye/tenant-management)**. *** ## Kontextfenster-Füllstand Jedes `model_response`-Event zeigt eine **Kontextfüllstand-Pille** — Eingabe- plus Ausgabe-Token als Prozentsatz des Kontextfensters dieses Modells. Die Bereiche sind `healthy` (0–24%), `watch` (25–49%), `compacting` (50–74%) und `reset context` (75–100%). AgentEye löst gängige Modell-IDs automatisch auf, sodass keine anfängliche Konfiguration erforderlich ist. Jedes Modell, das eine Organisation sendet, erscheint unter **Einstellungen → Modell-Kontextfenster**. Benutzer mit `settings:write` können dessen Fenster überschreiben oder ein privates/Proxy-Modell hinzufügen (0–1.000.000 Token); `0` bedeutet "unbekannt" und unterdrückt die Pille. Änderungen gelten für neu eingehende Events. Benutzer mit `settings:read` können die Liste einsehen. Neue Events erhalten den Füllstand ab dem Moment des Upgrades. Um auch **historische** Events (und die Pro-Modell-Liste) für ein bestehendes Deployment zu befüllen, führen Sie das einmalige Backfill aus — es wird innerhalb des Server-Images (wie `agenteye-orgctl`) ausgeliefert und läuft im vorhandenen Server-Pod: ```bash theme={null} # Vorschau (gibt die Pro-Org-Mutation aus, ändert nichts): kubectl -n agenteye exec deploy/server -- agenteye-backfill-context-window --dry-run # Anwenden: kubectl -n agenteye exec deploy/server -- agenteye-backfill-context-window # docker compose: docker compose exec server agenteye-backfill-context-window ``` Es ist idempotent (sicher mehrfach ausführbar) und nutzt `DATABASE_URL` / `CLICKHOUSE_URL` / `REDIS_URL` aus dem Pod. Führen Sie es erneut aus, nachdem Sie Modellfenster bearbeitet haben, wenn Sie möchten, dass vorhandene Events neu berechnet werden. *** ## Produktionsüberlegungen * **Postgres**: Verwenden Sie einen verwalteten Postgres-Dienst oder eine dedizierte Instanz mit regelmäßigen Backups. `DATABASE_URL` unterstützt alle Standard-libpq-Parameter, einschließlich `sslmode=require` für verschlüsselte Verbindungen. * **TLS**: Stellen Sie Server und Dashboard hinter einen Reverse-Proxy (nginx, Caddy, Traefik), der TLS terminiert. * **Firewall**: Der Server-Port (Standard 8080) sollte nur von Collector-Maschinen und dem Dashboard-Host erreichbar sein, nicht aus dem öffentlichen Internet. * **Admin-Schlüssel**: Setzen Sie `ADMIN_KEY` auf ein starkes zufälliges Geheimnis. Nach dem Bootstrapping erstellen Sie dedizierte, eingeschränkte Schlüssel für Collector und Dashboard, anstatt den Admin-Schlüssel überall zu verwenden. * **Image-Tags**: Fixieren Sie in der Produktion auf die Version in Ihren Release-Manifesten (z. B. `server:v0.0.1-beta.48`) statt auf einem Floating-Tag, um unbeabsichtigte Upgrades zu vermeiden. Aktuelle Beta-Builds werden unter `beta-latest` veröffentlicht; `latest` wird nur stabilen Releases zugewiesen. * **Health-Monitoring**: Auf Kubernetes verwendet die Readiness-Probe `/ready` (Postgres + ClickHouse-Erreichbarkeit), während Liveness auf `/health` bleibt. Für flottenweit Alerting nach Slack bei "Ist AgentEye selbst oben?", aktivieren Sie das optionale Robusta-Add-on; siehe [enterprise-docs/health-monitoring.md](/de/agenteye/health-monitoring). *** ## Verfügbare Image-Tags | Tag | Beschreibung | | ------------- | ----------------------------------------------------------------------- | | `latest` | Neuestes stabiles Release | | `beta-latest` | Neuestes Pre-Release (Beta) | | `v` | Fixierte Version, z. B. `v0.0.1-beta.48` (empfohlen für die Produktion) |