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: Sie halten keine Retention durch basebox – Speicherung und Aufbewahrung liegen bei Ihnen.

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 REST-Schnittstelle zur laufenden 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

Für Dienst- und Host-Logs gibt es keine Retention durch basebox; Speicherung und Löschung richten sich 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