Copyright © 2022-2026 basebox GmbH, all rights reserved.
Licensed to be used in conjunction with basebox, only.

// installation

Logging

Gilt für

Produkt: Server · Zielgruppe: Platform Operator · IT-Sicherheit

Wo Logs liegen, was das Audit-Log gegenüber Anwendungslogs festhält, welche Log-Level was enthalten, und wie Sie an ein SIEM weiterleiten. Drei Arten von Logs sind auseinanderzuhalten: das fachliche Audit-Log der Anwendung (für Administratoren), die Dienstlogs der Container (für Sie) und die Host-Logs des Servers.

Die drei Ebenen

Ebene	Was drinsteht	Wer liest	Wo
Audit-Log (Anwendung)	Wer hat wann was getan: Anmeldungen, Änderungen an Benutzern/Gruppen/Tagesmeldungen, Exporte, Werkzeugaufrufe (Metadaten), optional Gesprächsinhalte	Administratoren	Administration → Audit Log; CSV-Export; in `aisrv-db`
Dienstlogs (Container)	Technische Ereignisse: Start, Anfragen, Fehler, Verbindungen zu IdP/Inferenz/RAG	Platform Operator	`kubectl logs` je Deployment; Ihr Log-Stack
Host-Logs	Kernel, systemd, containerd, kubelet, NVIDIA	Platform Operator	`journalctl`, `/var/log`, syslog

Das Audit-Log ist kein Dienstlog: Aufbewahrung und Detailtiefe legen Administratoren fest (Richtlinien); Sie sichern es mit der Datenbank. Umgekehrt sind Dienstlogs kein Audit: Systemprotokolle werden nach 7 Tagen gelöscht, wenn Sie nichts anderes einstellen.

Dienstlogs lesen

kubectl -n basebox logs -l app.kubernetes.io/name=aisrv --tail=100 -f
kubectl -n basebox logs -l app.kubernetes.io/name=inference --tail=100 -f
kubectl -n basebox logs -l app.kubernetes.io/name=ragsrv --tail=100
kubectl -n basebox logs -l app.kubernetes.io/name=ragsrv-support --tail=100
kubectl -n basebox logs -l app.kubernetes.io/name=idp --tail=100
kubectl -n basebox logs -l app.kubernetes.io/name=frontend --tail=100
kubectl -n basebox logs idp-db-1                          # Datenbank-Pod
kubectl -n basebox logs <pod> --previous                  # vorheriger Container nach Neustart
kubectl -n basebox logs -l app.kubernetes.io/component=mcp --tail=100   # Konnektoren

Bei Störungen zuerst aisrv – dort laufen Login, Inferenz- und RAG-Aufrufe zusammen (Beispiele: INVALID_TOKEN, „iss does not match", „data transmission failed (SSE)" – siehe FAQ).

Log-Level

Dienst	Variable	Standard	Produktion
AISRV	`AISRV_LOG_LEVEL`	`info`	`info`
storesrv	`STORESRV_LOG_LEVEL`	`trace`	`info`
ragsrv	`LOG_LEVEL`	`trace`	`info`
ragsrv-support	`LOG_LEVEL`	`trace`	`info`
Keycloak	Keycloak-Konfiguration	–	`INFO`

Stufen: trace · debug · info · warn · error.

Was auf welchem Level in die Logs gerät

Prompt- und Antwortinhalte werden ausschließlich auf trace protokolliert. Produktiv auf info bleiben – sonst enthalten Ihre Dienstlogs Gesprächsinhalte, mit allen Datenschutzfolgen.
Zugangsdaten von Konnektoren erscheinen nie in Produktionslogs; nur auf debug und nur im Rahmen gezielter Diagnoseläufe. Nach der Diagnose Level zurücksetzen und die Diagnoselogs löschen.
LOG_HEALTH_CHECKS: "false" hält Probe-Anfragen aus den Logs von ragsrv/ragsrv-support.

Debug-Modus (AISRV_DEBUG_MODE) sendet Fehler unverändert an den Client – nur für Diagnose, nicht produktiv.

Audit-Ereignisse

Was das Audit-Log der Anwendung festhält – Aktionsnamen wie user.login, graphql:createGroup, rest:exportAuditLogs, Werkzeugaufrufe mit Organisation, Nutzer, Werkzeug, Anbieter, Ergebnis, Zeitstempel und Client-Adresse, ohne den Text von Websuche-Anfragen; fehlgeschlagene Token-Anfragen mit Adresse – steht unter Audit & Logging. Ob Gesprächsinhalte enthalten sind, entscheidet die von Administratoren gesetzte Detailtiefe; dann sehen Nutzer einen Hinweis im Chat.

Weiterleitung an ein SIEM

Dienst- und Host-Logs: mit Ihrem üblichen Sammler (Fluent Bit, Vector, Promtail) über den Kubernetes-Logpfad und journald nach Loki, Elastic oder Ihr SIEM. basebox-Dienste loggen nach stdout; kein Sonderformat nötig.
Audit-Log: derzeit per CSV-Export aus der Administration (rest:exportAuditLogs); eine laufende Ausleitung ist geplant. Details und Empfehlungen: SIEM.
Keycloak-Ereignisse (Login-Erfolge/-Fehler, Admin-Aktionen) in Keycloak aktivieren und ebenfalls einsammeln.
Metriken sind kein Ersatz für Logs, aber die bessere Alarmquelle – siehe Monitoring.

Aufbewahrung

Systemprotokolle werden nach 7 Tagen gelöscht, wenn Sie nichts anderes einstellen. Sammeln Sie Logs in Ihrem eigenen Log-Stack, richten sich Speicherung und Löschung dort nach Ihren internen Richtlinien (etwa 30–90 Tage für Dienstlogs, länger für Sicherheitsereignisse). Betreiber sind verpflichtet, Logdaten regelmäßig zu prüfen und zu löschen (Sicherheitshinweise). Das Audit-Log der Anwendung hat seine eigene, von Administratoren gesetzte Aufbewahrung.

Was Sie für den Support brauchen

Bei einer Anfrage an support@basebox.ai: aisrv-Logs rund um den Zeitpunkt, Logs der betroffenen Komponente, kubectl get events, Browser-Konsole bei Oberflächenproblemen, das Manifest (Versionen). Ohne Zugangsdaten, Tokens oder Gesprächsinhalte – bei trace-Logs vorher schwärzen.

Nächster Schritt: Backup & Wiederherstellung