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

// installation

Logging

Applies to

Product: Server · Audience: Platform Operator · IT security

Where logs live, what the audit log records compared to application logs, which log levels contain what, and how to forward to a SIEM. Three kinds of logs must be kept apart: the application's functional audit log (for administrators), the containers' service logs (for you) and the server's host logs.

The three levels

Level	What it contains	Who reads	Where
Audit log (application)	Who did what when: sign-ins, changes to users/groups/messages of the day, exports, tool calls (metadata), optionally conversation content	Administrators	Administration → Audit log; CSV export; in aisrv-db
Service logs (containers)	Technical events: start, requests, errors, connections to IdP/inference/RAG	Platform Operator	kubectl logs per deployment; your log stack
Host logs	Kernel, systemd, containerd, kubelet, NVIDIA	Platform Operator	journalctl, /var/log, syslog

The audit log is not a service log: retention and detail level are set by administrators (Policies); you back it up with the database. Conversely, service logs are not audit: they have no retention by basebox – storage and retention are up to you.

Reading service logs

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                          # database pod
kubectl -n basebox logs <pod> --previous                  # previous container after restart
kubectl -n basebox logs -l app.kubernetes.io/component=mcp --tail=100   # connectors

During incidents check aisrv first – login, inference and RAG calls converge there (examples: INVALID_TOKEN, "iss does not match", "data transmission failed (SSE)" – see FAQ).

Log levels

Service	Variable	Default	Production
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 configuration	–	INFO

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

What ends up in the logs at which level

• Prompt and response content is logged exclusively at trace. Stay at info in production – otherwise your service logs contain conversation content, with all data protection consequences.
• Connector credentials never appear in production logs; only at debug and only during targeted diagnostic runs. Reset the level after diagnosis and delete the diagnostic logs.
• LOG_HEALTH_CHECKS: "false" keeps probe requests out of the ragsrv/ragsrv-support logs.

Debug mode (AISRV_DEBUG_MODE) sends errors to the client unchanged – for diagnosis only, not for production.

Audit events

What the application's audit log records – action names such as user.login, graphql:createGroup, rest:exportAuditLogs, tool calls with organisation, user, tool, provider, result, timestamp and client address, without the text of web search queries; failing token requests with address – is described under Audit & logging. Whether conversation content is included is decided by the detail level set by administrators; users then see a notice in the chat.

Forwarding to a SIEM

• Service and host logs: with your usual collector (Fluent Bit, Vector, Promtail) via the Kubernetes log path and journald into Loki, Elastic or your SIEM. basebox services log to stdout; no special format needed.
• Audit log: currently via CSV export from the administration (rest:exportAuditLogs); a REST interface for continuous export is planned. Details and recommendations: SIEM.
• Keycloak events (login successes/failures, admin actions): enable in Keycloak and collect as well.
• Metrics are no substitute for logs but the better alert source – see Monitoring.

Retention

For service and host logs there is no retention by basebox; storage and deletion follow your internal policies (e.g. 30–90 days for service logs, longer for security events). Operators are obliged to review and delete log data regularly (Safety Notice). The application's audit log has its own retention set by administrators.

What you need for support

For a request to support@basebox.ai: aisrv logs around the time, logs of the affected component, kubectl get events, browser console for interface problems, the manifest (versions). Without credentials, tokens or conversation content – redact trace logs beforehand.

Next step: Backup & restore