> ## 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. # Single-Pod-Deployment: Collector + Application-Sidecar auf EKS > AgentEye Single-Pod-Deployment: Dokumentation für Collector + Application-Sidecar auf EKS. Betreiben Sie Ihre Anwendung und den AgentEye-Collector **im selben Kubernetes-Pod**, sodass Telemetriedaten zur Erfassung niemals eine Netzwerkgrenze überschreiten müssen. Das SDK Ihrer Anwendung und der Collector teilen sich einen gemeinsamen In-Pod-Ereignis-Spool, was einen latenzarmen, prozessinternen Telemetrie-Übergabe ohne exponierten localhost-Port, ohne Durchquerung eines Service-Mesh und mit einem direkt an die beobachtete Arbeitslast gebundenen Collector-Lebenszyklus ermöglicht. Das mTLS-Client-Zertifikat, das der Collector vorlegt, wird direkt über AWS Secrets Manager in Ihren Pod geliefert, sodass eine Zertifikatsrotation ohne manuelles Verschieben von Dateien auf Ihrer Seite auskommt. Das hier beschriebene Sidecar- und Shared-Spool-Modell ist cloud-agnostisch: Zwei Container, die sich ein `emptyDir`-Ereignis-Spool teilen, funktionieren auf jeder Kubernetes-Distribution. Lediglich der Pfad zur Zertifikatsauslieferung in diesem Leitfaden (AWS Secrets Manager + Secrets Store CSI Driver + IRSA) ist spezifisch für AWS/EKS. Wenn Sie eine andere Umgebung verwenden, behalten Sie das Pod- und Spool-Layout bei und ersetzen Sie den Secret-Mount-Mechanismus aus Phase 2 und 3 durch den Ihrer Plattform. > **Wann sollte dieses Muster verwendet werden?** Wählen Sie Single-Pod, wenn Ihre Anwendung den Collector nicht über eine Netzwerkgrenze hinweg ansprechen soll (latenzarme In-Pod-IPC, enge Lebenszyklus-Kopplung, Pod-Isolierung pro Mandant). Für Multi-App-Flotten, die einen gemeinsamen Collector pro Node oder Cluster verwenden, lesen Sie stattdessen [enterprise-docs/kubernetes-deployment.md](/de/agenteye/kubernetes-deployment). *** ## Auf einen Blick ``` ┌──────────────────────────────── Pod ─────────────────────────────────┐ │ │ │ ┌──────────────────────┐ ┌──────────────────────┐ │ │ │ your-app │ │ agenteye-collector │ │ │ │ (SDK writes JSONL) │ │ (sweeps events/, │ │ │ │ │ │ uploads over mTLS) │ │ │ └──────────┬───────────┘ └──────────┬───────────┘ │ │ │ writes reads │ │ │ ▼ ▼ │ │ ┌────────────────────────────────────────────────────┐ │ │ │ emptyDir: /var/lib/agenteye/{events,failed}/ │ │ │ │ (AGENTEYE_HOME - shared event spool) │ │ │ └────────────────────────────────────────────────────┘ │ │ ▲ │ │ │ reads cert │ │ ┌────────┴─────────┐ │ │ │ CSI (read-only): │ │ │ │ /etc/agenteye/ │ │ │ │ tls/client.{crt, │ │ │ │ key}, ca.crt │ │ │ └────────┬─────────┘ │ └───────────────────────────────────────────────────┼──────────────────┘ │ mounted by │ Secrets Store CSI │ (AWS provider + │ IRSA) ┌────────┴──────────┐ │ AWS Secrets │ │ Manager │ │ agenteye/mtls- │ │ client/ │ └────────┬──────────┘ ▲ │ push on issue / │ renewal ┌────────┴──────────┐ │ Exosphere │ │ delivers the cert │ │ bundle into your │ │ Secrets Manager │ │ on renewal │ └───────────────────┘ Outbound: collector → AGENTEYE_URL (mTLS, using the CSI-mounted cert). ``` Zwei Datenflüsse, zwei Volumes: * **Ereignisse (In-Pod):** Das SDK Ihrer Anwendung schreibt `.jsonl`-Dateien in das gemeinsame `emptyDir` unter `$AGENTEYE_HOME/events/`; der Collector-Sweeper liest und lädt sie hoch. Kein localhost-Port, kein Loopback – reine Shared-Filesystem-Übergabe. * **mTLS-Zertifikat (Pod ← Cloud):** Der Secrets Store CSI Driver bindet das Zertifikats-Bundle aus dem Secrets Manager als schreibgeschütztes Volume unter `/etc/agenteye/tls/` ein, begrenzt auf den Collector-Container. **Zwei unabhängige Parteien:** | Partei | Verantwortlichkeit | | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Exosphere | Stellt das mTLS-Client-Zertifikat aus und liefert das Bundle in das Secrets Manager **Ihres** AWS-Kontos unter einem stabilen Namen. Veröffentlicht das erneuerte Bundle vor Ablauf erneut in demselben Secret. | | Sie | Installieren den Secrets Store CSI Driver, gewähren dem ServiceAccount des Pods per IRSA Lesezugriff auf das Secret und wenden das Pod-Manifest an. Das ist alles. | *** ## Voraussetzungen ### In Ihrem AWS-Konto / EKS-Cluster * Ein EKS-Cluster mit einem zugehörigen **OIDC-Provider**. Überprüfen Sie dies mit: ```bash theme={null} aws eks describe-cluster --name \ --query "cluster.identity.oidc.issuer" --output text ``` Wenn der Befehl eine `https://oidc.eks.…`-URL zurückgibt, ist OIDC aktiviert. Andernfalls verknüpfen Sie einen: ```bash theme={null} eksctl utils associate-iam-oidc-provider \ --cluster --approve ``` * Der [Secrets Store CSI Driver](https://secrets-store-csi-driver.sigs.k8s.io/) und der [AWS-Provider](https://github.com/aws/secrets-store-csi-driver-provider-aws) sind im Cluster installiert (siehe § Phase 2). * AWS CLI v2 und `kubectl` auf Ihrer Arbeitsstation. ### Abstimmung mit Exosphere Vor der Bereitstellung liefert Exosphere das mTLS-Client-Bundle in das Secrets Manager Ihres AWS-Kontos und stellt Folgendes bereit: * Den **Secret-Namen** (Konvention: `agenteye/mtls-client/`) * Die **AWS-Region**, in der das Secret gespeichert ist * Die **AgentEye-Backend-URL** zur Konfiguration des Collectors * Ihren Collector-**API-Key** (siehe [enterprise-docs/api-keys.md](/de/agenteye/api-keys)) *** ## Phase 1: Was Exosphere liefert Sie generieren das mTLS-Client-Zertifikat nicht selbst. Exosphere stellt es aus und liefert das Bundle direkt in das Secrets Manager Ihres AWS-Kontos, sodass das einzige Credential-Material, das in Ihrer Umgebung landet, das fertige, einsatzbereite Secret ist. Was in Ihrem Konto ankommt: | Eigenschaft | Wert | | ----------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | Secret-Name | `agenteye/mtls-client/` (stabil über Erneuerungen hinweg) | | Region | Die AWS-Region, die Sie für Ihren EKS-Cluster festgelegt haben | | Payload | Ein einzelnes JSON-Secret mit drei Schlüsseln (`client.crt`, `client.key` und `ca.crt`), die jeweils das PEM-kodierte Material enthalten | | Tag | `AgentEyeCluster=` | Bei der Erneuerung wird dasselbe Secret mit einer neuen Version aktualisiert, sodass ARN und Name sich nie ändern; Ihre `SecretProviderClass` und IAM-Policy bleiben unverändert funktionsfähig. Informationen zum Zertifikatslebenszyklus (Gültigkeit, Erneuerungsrhythmus, Ablaufwarnungen) finden Sie unter [enterprise-docs/kubernetes-deployment.md](/de/agenteye/kubernetes-deployment). *** ## Phase 2: Secrets Store CSI Driver + AWS-Provider installieren Überspringen Sie diesen Schritt, wenn Sie bereits eine andere Arbeitslast betreiben, die AWS-Secrets per CSI einbindet. ```bash theme={null} # CSI Driver helm repo add secrets-store-csi-driver \ https://kubernetes-sigs.github.io/secrets-store-csi-driver/charts helm install -n kube-system csi-secrets-store \ secrets-store-csi-driver/secrets-store-csi-driver \ --set syncSecret.enabled=true \ --set enableSecretRotation=true \ --set rotationPollInterval=1h # AWS provider kubectl apply -f \ https://raw.githubusercontent.com/aws/secrets-store-csi-driver-provider-aws/main/deployment/aws-provider-installer.yaml ``` **Überprüfung:** ```bash theme={null} kubectl get pods -n kube-system | grep -E 'csi-secrets-store|aws-provider' ``` Erwartet: `Running` für jeden Pod. > **Warum `rotationPollInterval=1h`?** Wenn Exosphere ein erneuertes Zertifikat veröffentlicht, wird Secrets Manager direkt aktualisiert. Der CSI Driver liest das Secret in diesem Intervall erneut und überschreibt die eingebundenen Dateien. Der Collector liest die Zertifikatsdateien einmalig beim Start, sodass er das erneuerte Zertifikat erst nach einem Prozess-Neustart vorlegt; unter § Zertifikatsrotation erfahren Sie, wie Sie diesen auslösen. *** ## Phase 3: Pod-Lesezugriff auf das Secret gewähren (IRSA) ### 3.1 IAM-Policy erstellen Speichern Sie als `agenteye-mtls-reader-policy.json`: ```json theme={null} { "Version": "2012-10-17", "Statement": [ { "Sid": "ReadAgentEyeMtlsBundle", "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret" ], "Resource": "arn:aws:secretsmanager:::secret:agenteye/mtls-client/-*" } ] } ``` Ersetzen Sie ``, `` und ``. Das abschließende `-*` entspricht dem sechsstelligen Zufallssuffix, den AWS an jeden Secret-ARN anhängt. Policy erstellen: ```bash theme={null} aws iam create-policy \ --policy-name AgentEyeMtlsReader- \ --policy-document file://agenteye-mtls-reader-policy.json ``` ### 3.2 IAM-Rolle erstellen und an den ServiceAccount des Pods binden ```bash theme={null} eksctl create iamserviceaccount \ --name agenteye-pod \ --namespace \ --cluster \ --role-name AgentEyePodRole- \ --attach-policy-arn arn:aws:iam:::policy/AgentEyeMtlsReader- \ --approve ``` Dies erstellt einen `ServiceAccount` namens `agenteye-pod` mit der `eks.amazonaws.com/role-arn`-Annotation, die auf die neue Rolle verweist. ### 3.3 Erforderliche IAM-Berechtigungen: Zusammenfassung | Berechtigung | Geltungsbereich | Zweck | | ------------------------------- | -------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | | `secretsmanager:GetSecretValue` | `arn:aws:secretsmanager:::secret:agenteye/mtls-client/-*` | CSI Driver liest das Zertifikats-Bundle bei jedem Mount- und Rotations-Tick. | | `secretsmanager:DescribeSecret` | wie oben | CSI Driver ruft `DescribeSecret` auf, um Versionsänderungen zwischen den Abfragen zu erkennen. | **Gewähren Sie dem Pod NICHT** `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecret` oder `secretsmanager:DeleteSecret`. Der Pod liest das Secret ausschließlich; das Schreiben neuer Versionen übernimmt Exosphere bei der Ausstellung oder Erneuerung des Zertifikats. Wenn das Secret mit einem kundenverwalteten KMS-Schlüssel (nicht dem Standard-Schlüssel `aws/secretsmanager`) verschlüsselt ist, gewähren Sie zusätzlich: ```json theme={null} { "Effect": "Allow", "Action": ["kms:Decrypt"], "Resource": "arn:aws:kms:::key/", "Condition": { "StringEquals": { "kms:ViaService": "secretsmanager..amazonaws.com" } } } ``` *** ## Phase 4: Den Pod bereitstellen ### 4.1 SecretProviderClass `agenteye-mtls-spc.yaml`: ```yaml theme={null} apiVersion: secrets-store.csi.x-k8s.io/v1 kind: SecretProviderClass metadata: name: agenteye-mtls namespace: spec: provider: aws parameters: objects: | - objectName: "agenteye/mtls-client/" objectType: "secretsmanager" jmesPath: - path: '"client.crt"' objectAlias: "client.crt" - path: '"client.key"' objectAlias: "client.key" - path: '"ca.crt"' objectAlias: "ca.crt" ``` Der `jmesPath`-Block weist den AWS-Provider an, das JSON-Secret in drei separate Dateien auf der Festplatte aufzuteilen. Die Anführungszeichen in `'"client.crt"'` sind erforderlich, weil JMESPath `.` als Teilausdruck-Operator behandelt. ```bash theme={null} kubectl apply -f agenteye-mtls-spc.yaml ``` ### 4.2 Pod-/Deployment-Manifest **Wie die beiden Container miteinander kommunizieren.** Das AgentEye-SDK und der Collector kommunizieren nicht über einen Netzwerk-Socket; es gibt keinen lokalen HTTP-Port. Das SDK schreibt Ereignis-Batches als `.jsonl`-Dateien in `$AGENTEYE_HOME/events/`, und der Collector überwacht dieses Verzeichnis kontinuierlich und lädt jede Datei hoch. Für einen Sidecar-Pod bedeutet das: * Beide Container binden dasselbe `emptyDir`-Volume am **gleichen** Pfad ein. * Beide Container setzen `AGENTEYE_HOME` auf diesen Pfad. * Ihr Anwendungs-Image muss das AgentEye-SDK installiert und konfiguriert haben (siehe [enterprise-docs/python-sdk.md](/de/agenteye/python-sdk)). > Wenn `AGENTEYE_HOME` nicht gesetzt ist, verwenden sowohl das SDK als auch der Collector standardmäßig `~/.agenteye`, und die beiden Container haben unterschiedliche Home-Verzeichnisse, sodass sie auf zwei separate Spools landen würden und die Übergabe lautlos fehlschlägt. Setzen Sie `AGENTEYE_HOME` auf **beiden** Containern auf denselben expliziten Pfad. Die Überprüfung in §4.3 und die entsprechende Zeile im Abschnitt Fehlerbehebung erkennen dies, falls es versäumt wurde. `agenteye-pod.yaml` (Deployment mit einem Replikat, nach Bedarf skalierbar): ```yaml theme={null} apiVersion: apps/v1 kind: Deployment metadata: name: my-app-with-collector namespace: spec: replicas: 1 selector: matchLabels: app: my-app-with-collector template: metadata: labels: app: my-app-with-collector spec: serviceAccountName: agenteye-pod containers: - name: app image: env: # SDK writes event JSONL files into $AGENTEYE_HOME/events/ - name: AGENTEYE_HOME value: /var/lib/agenteye volumeMounts: - name: agenteye-spool mountPath: /var/lib/agenteye - name: agenteye-collector # Pin to a versioned :v tag for production; :beta-latest # tracks the current beta build (:latest exists only for stable releases). image: ghcr.io/agenteye-enterprise/collector:beta-latest args: ["start"] env: # Must match the app container's AGENTEYE_HOME so the collector # sweeps the same directory the SDK writes to. - name: AGENTEYE_HOME value: /var/lib/agenteye - name: AGENTEYE_URL value: "https://ingest.example.agenteye.com/events" - name: AGENTEYE_KEY valueFrom: secretKeyRef: name: agenteye-collector-api-key key: key - name: AGENTEYE_TLS_CERT value: /etc/agenteye/tls/client.crt - name: AGENTEYE_TLS_KEY value: /etc/agenteye/tls/client.key # Only when the AgentEye server presents a cert not signed by a # publicly-trusted CA (e.g. self-signed by an in-cluster issuer # because you have no real DNS domain). The CSI mount already # exposes ca.crt alongside the client cert/key. - name: AGENTEYE_TLS_CA value: /etc/agenteye/tls/ca.crt volumeMounts: - name: agenteye-spool mountPath: /var/lib/agenteye - name: agenteye-mtls mountPath: /etc/agenteye/tls readOnly: true livenessProbe: exec: command: ["agenteye-collector", "health"] initialDelaySeconds: 10 periodSeconds: 30 volumes: # Shared event spool between app and collector. emptyDir is fine: # events are transient and the collector drains them before pod # termination on graceful shutdown. - name: agenteye-spool emptyDir: {} # mTLS cert bundle, mounted read-only into the collector only. - name: agenteye-mtls csi: driver: secrets-store.csi.k8s.io readOnly: true volumeAttributes: secretProviderClass: agenteye-mtls ``` Das Secret `agenteye-collector-api-key` enthält den API-Key des Collectors (zur Bereitstellung siehe [enterprise-docs/api-keys.md](/de/agenteye/api-keys)). **Anwenden:** ```bash theme={null} kubectl apply -f agenteye-pod.yaml ``` ### 4.3 Überprüfung ```bash theme={null} # Pod sollte mit 2/2 bereiten Containern den Status Running haben kubectl get pods -n -l app=my-app-with-collector # Bestätigen, dass das Zertifikats-Bundle eingebunden wurde kubectl exec -n deploy/my-app-with-collector \ -c agenteye-collector -- ls -l /etc/agenteye/tls/ ``` Erwartet: `client.crt`, `client.key`, `ca.crt` sind alle vorhanden, schreibgeschützt und im Besitz des Container-Benutzers. **Bestätigen Sie, dass der gemeinsame Ereignis-Spool für beide Container sichtbar ist:** ```bash theme={null} # Im Collector sollten die Unterverzeichnisse events/ und failed/ angezeigt werden, # die der Collector beim Start automatisch erstellt: kubectl exec -n deploy/my-app-with-collector \ -c agenteye-collector -- ls /var/lib/agenteye/ # In der App sollten dieselben Verzeichnisinhalte angezeigt werden: kubectl exec -n deploy/my-app-with-collector \ -c app -- ls /var/lib/agenteye/ ``` Wenn die beiden Auflistungen voneinander abweichen, ist das Volume nicht in beiden Containern eingebunden (oder `AGENTEYE_HOME` unterscheidet sich); siehe § Fehlerbehebung. **End-to-End-Smoke-Test:** ```bash theme={null} kubectl exec -n deploy/my-app-with-collector \ -c agenteye-collector -- agenteye-collector flush ``` Erwartet: Der Collector lädt alle in der Warteschlange befindlichen Ereignisse hoch und gibt eine Zusammenfassung `Done: N/N uploaded, 0 failed.` aus. Wenn der Spool leer ist, gibt er `No pending files.` aus und beendet sich, ohne etwas zu validieren – führen Sie dies daher erst aus, nachdem Ihre Anwendung mindestens ein Ereignis geflusht hat. Beachten Sie, dass `flush` nur bei lokalen Konfigurationsfehlern mit einem Nicht-Null-Exitcode abbricht: fehlende Konfiguration (keine URL/kein Key auflösbar) oder ein unlesbares/nicht parsebares TLS-Zertifikat (siehe § Fehlerbehebung). Ein **falscher API-Key ändert den Exitcode nicht** — der Upload erhält eine `401`-Antwort, die Datei wird nach `failed/` verschoben, und der Befehl gibt dennoch `[FAILED] …` pro Datei sowie `Done: 0/N uploaded, N failed.` aus und beendet sich mit `0`. Um einen falschen Key oder einen abgelehnten Upload zu erkennen, lesen Sie die `Done:`/`[FAILED]`-Ausgabe oder prüfen Sie, ob Dateien in `$AGENTEYE_HOME/failed/` landen, nicht den Exitcode. *** ## Zertifikatsrotation Das Client-Zertifikat ist 90 Tage gültig und wird automatisch etwa 15 Tage vor Ablauf erneuert; Exosphere veröffentlicht das erneuerte Bundle dann in dasselbe Secrets Manager-Secret. Danach läuft der In-Pod-Ablauf wie folgt: 1. Das Secret in Secrets Manager erhält eine neue `AWSCURRENT`-Version. ARN und Name bleiben unverändert. 2. Innerhalb des `rotationPollInterval` (standardmäßig 1h; siehe § Phase 2) liest der CSI Driver die neue Version und überschreibt die Dateien unter `/etc/agenteye/tls/`. 3. Der Collector lädt die Zertifikatsdateien **einmalig beim Start**, sodass er das vorherige Zertifikat weiter vorlegt, bis der Prozess neu gestartet wird. Um zum erneuerten Material zu wechseln, starten Sie den Collector neu; ein Rolling Restart reicht aus: ```bash theme={null} kubectl rollout restart deploy/my-app-with-collector -n ``` Um dies zu automatisieren, fügen Sie einen Sidecar hinzu, der `/etc/agenteye/tls/` überwacht (z. B. mit `inotifywait`) und den Rollout auslöst, wenn sich die Dateien ändern. Da das vorherige Zertifikat nach der Erneuerung noch etwa 15 Tage gültig bleibt, haben Sie ein großzügiges Zeitfenster für den Neustart ohne Unterbrechung der Datenerfassung. Exosphere veröffentlicht das erneuerte Bundle für Sie; die einzige routinemäßige Aktion auf Ihrer Seite besteht darin, sicherzustellen, dass der Collector innerhalb dieses Zeitfensters neu gestartet wird. *** ## Fehlerbehebung | Symptom | Wahrscheinliche Ursache | Lösung | | -------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Pod bleibt in `ContainerCreating`, Ereignisse zeigen `MountVolume.SetUp failed for volume "agenteye-mtls"` | CSI-Provider kann Secrets Manager nicht erreichen | Prüfen Sie, ob IRSA korrekt gebunden ist: `kubectl describe sa agenteye-pod -n ` zeigt die `eks.amazonaws.com/role-arn`-Annotation. Prüfen Sie CloudTrail auf den AssumeRole-Aufruf. | | Fehler: `AccessDeniedException: not authorized to perform secretsmanager:GetSecretValue` | IAM-Policy ist auf den falschen ARN beschränkt | Das Secret-ARN-Suffix ist zufällig; verwenden Sie `agenteye/mtls-client/-*` mit Wildcard, nicht den exakten ARN. | | Fehler: `ParameterNotFound` vom AWS-Provider | Secret-Name stimmt nicht zwischen `SecretProviderClass.objects[].objectName` und dem von Exosphere gelieferten Secret überein | Bestätigen Sie den genauen Namen mit `aws secretsmanager list-secrets --filters Key=tag-key,Values=AgentEyeCluster`. | | `jmesPath`-Fehler, nur eine Datei eingebunden | JMESPath-Syntax | Die Punkte in den JSON-Schlüsseln erfordern doppelte Anführungszeichen: `'"client.crt"'`, nicht `client.crt`. | | Collector-Logs zeigen `tls: bad certificate` nach einer Erneuerung | Der CSI Driver hat die neue Version noch nicht abgefragt, oder der Collector läuft noch mit dem beim Start geladenen vorherigen Zertifikat | Bestätigen Sie, dass die eingebundenen Dateien aktualisiert wurden (`ls -l /etc/agenteye/tls/`), und starten Sie dann den Collector neu, um sie zu laden: `kubectl rollout restart deploy/my-app-with-collector -n `. Siehe § Zertifikatsrotation. | | Collector-Container crashloopt mit `no such file or directory: /etc/agenteye/tls/client.crt` | Volume beim ersten Start noch nicht befüllt; Startup-Probe zu aggressiv | Fügen Sie eine kurze Anfangsverzögerung hinzu oder verwenden Sie einen Init-Container, der auf das Vorhandensein der Datei wartet: `until [ -f /etc/agenteye/tls/client.crt ]; do sleep 1; done`. | | CSI-Driver-Pod `OOMKilled` | Standard-Speicherlimits zu niedrig für Cluster mit vielen SecretProviderClasses | Erhöhen Sie `--set linux.resources.limits.memory=200Mi` bei der Helm-Installation. | | App läuft einwandfrei, `agenteye-collector flush` meldet `No pending files.`, aber das AgentEye-Dashboard zeigt keine Ereignisse | App und Collector teilen sich nicht denselben Ereignis-Spool | Prüfen Sie, ob (a) beide Container dasselbe `agenteye-spool`-emptyDir am selben Pfad einbinden und (b) beide `AGENTEYE_HOME` auf diesen Pfad setzen. Führen Sie die beiden `ls /var/lib/agenteye/`-Prüfungen aus § 4.3 aus; die Auflistungen müssen übereinstimmen. | **Zuerst zu prüfende Logs:** ```bash theme={null} kubectl logs -n kube-system -l app=secrets-store-csi-driver --tail=100 kubectl logs -n kube-system -l app=csi-secrets-store-provider-aws --tail=100 kubectl describe pod -n -l app=my-app-with-collector ``` *** ## Referenz: Dateien auf dem Pod-Datenträger Der Pod hat zwei Datenpfade auf dem Datenträger: ### mTLS-Zertifikats-Bundle: `/etc/agenteye/tls/` (CSI, schreibgeschützt, nur Collector) Eingebunden durch den Secrets Store CSI Driver aus AWS Secrets Manager. | Datei | Inhalt | Vom Collector verwendet als | | ------------ | -------------------------------- | ----------------------------------------------------------------------------------------------------------- | | `client.crt` | PEM-kodiertes Client-Zertifikat | `AGENTEYE_TLS_CERT` | | `client.key` | PEM-kodierter privater Schlüssel | `AGENTEYE_TLS_KEY` | | `ca.crt` | PEM-kodiertes CA-Zertifikat | `AGENTEYE_TLS_CA` (optional, nur wenn das AgentEye-Server-Zertifikat nicht öffentlich vertrauenswürdig ist) | Alle drei sind schreibgeschützt eingebunden und im Besitz des Container-Benutzers. Sie werden vom CSI Driver bei der Rotation des Secrets neu geschrieben. ### Ereignis-Spool: `$AGENTEYE_HOME/` (emptyDir, gemeinsam les- und schreibbar für beide Container) Geteilt über ein `emptyDir`-Volume namens `agenteye-spool`. | Pfad | Geschrieben von | Gelesen von | Zweck | | ------------------------------- | ----------------------------- | -------------------- | ------------------------------------------------------------------------------------ | | `$AGENTEYE_HOME/events/*.jsonl` | App (AgentEye-SDK) | Collector-Sweeper | Ereignis-Batches, die das SDK geflusht hat und die auf den Upload warten. | | `$AGENTEYE_HOME/failed/` | Collector (bei Upload-Fehler) | Sie (beim Debugging) | JSONL-Dateien, die der Collector nach Wiederholungsversuchen nicht hochladen konnte. | | `$AGENTEYE_HOME/config.json` | Sie (optional) | Collector | Optionale Collector-Konfigurationsdatei (Alternative zu Umgebungsvariablen). | Sowohl das Unterverzeichnis `events/` als auch `failed/` werden beim Start automatisch vom Collector angelegt; kein `initContainer` erforderlich. *** ## Verwandte Dokumentation * [enterprise-docs/collector-installation.md](/de/agenteye/collector-installation): Binäroptionen des Collectors, mTLS-Konfigurationsreferenz, Daemon-Modi. * [enterprise-docs/kubernetes-deployment.md](/de/agenteye/kubernetes-deployment): Multi-Pod-Deployment, interne Abläufe der Zertifikatsausstellung, Lebenszyklus- und Ablaufwarnungen. * [enterprise-docs/api-keys.md](/de/agenteye/api-keys): Bereitstellung des vom Pod verwendeten Collector-API-Keys. * [enterprise-docs/troubleshooting.md](/de/agenteye/troubleshooting): Clusterweiter Fehlerbehebungsindex.