80 Protokollierung / Logging
Protokollierung / Logging
Was wird protokolliert, wo landen die Logs, und was ist geplant.
Aktueller Stand
Logs im Container
Jeder Sub-Container schreibt lokal:
| Log | Pfad im Container | Inhalt | Rotation |
|---|---|---|---|
| Apache Access | /var/log/apache2/access.log (+ vhost-spezifisch) |
HTTP-Requests | Docker-Default (10 MB, 3 Files) |
| Apache Error | /var/log/apache2/error.log |
Apache-Fehler + PHP-Fehler (via log_errors = On) |
Docker-Default |
| PHP Errors | in Apache Error (nicht separat) | fatal/warning/notice — steuerbar per error_reporting in Custom-INI |
siehe Apache Error |
| Container stdout/stderr | via docker logs |
Apache + Supervisor-Events + PHP error_log() ohne Datei |
Docker-Default |
| msmtp | /var/log/msmtp.log |
ausgehende Mails (Sender, Empfaenger, Ergebnis) | keine (waechst unbegrenzt) |
| SSH | /var/log/auth.log (Container-lokal, kurzlebig) |
SSH-Logins in den Container | keine — beim Recreate weg |
Wichtig: Der Container-Filesystem ist nicht persistent. Nach einem
docker rm oder Image-Rebuild sind die Logs im Container weg. Nur
Verzeichnisse unter /var/www/ (Volume) ueberleben.
Logs auf der Node (ausserhalb Container)
| Log | Pfad | Inhalt |
|---|---|---|
| Hosting-API | journalctl -u hosting-api |
Node-API-Requests, Rebuilds, Sync-Runs |
| Backup | /srv/hosting/backup-state.json + /var/log/hosting-backup-*.log |
Zeitpunkte, Erfolg/Fehler, Dauer, letzte 50 Events pro Sub |
| SSH-Piper | Container-Logs ssh-proxy |
SSH-Routing-Entscheidungen (welcher User, welcher Sub) |
| Rebuild-Images | /var/log/hosting-rebuild-images.log |
Image-Build-Output, Sub-Recreate |
| Self-Update | /var/log/hosting-self-update.log |
Node zieht Binary + Templates vom Admin |
Logs im Admin-Panel
| Log | Ort | Inhalt |
|---|---|---|
| Aktivitaets-Log pro Sub | subscription_events-Tabelle, sichtbar auf Subscription-Show |
Create/Update/Delete, Hostname/DB/Mail-Aenderungen, Backup-Trigger, Install, Restore — wer, wann, was |
| Access-Tokens fuer Kunden | pro Sub sichtbar | Erzeugung + Verwendung von Zugangs-Links |
| Logs-Viewer pro Sub | subscriptions/{id}/logs |
Live-Tail Apache Access / Error / Container stdout (letzte 50 Zeilen) |
| Monitoring | pro Sub + pro Node | 5-Min-Samples: CPU/RAM/Storage/Load, letzte 31 Tage |
Zugriff fuer den Kunden
- SSH in den Container — direktes
tail -f /var/log/apache2/error.logetc. - Log-Viewer im Admin-Panel — Reseller/Admin sieht letzte 50 Zeilen jedes Log-Typs (Apache Access, Error, Container-stdout) per Web ohne SSH.
- Aktivitaets-Log — Wer hat wann was im Panel gemacht (nur fuer eigene Subs).
Geplant / in Arbeit
- Persistenz der Container-Logs ueber Recreate hinweg — Volume-Mount fuer
/var/log/apache2/und/var/log/msmtp.log, damit sie beim Image-Rebuild ueberleben. (Heute: Log-Historie geht bei jedem Update verloren.) - Log-Rotation aktiv steuerbar — heute Docker-Default; geplant konfigurierbare Werte pro Sub (Groesse + Anzahl Backups).
- Zentrale Log-Aggregation — vermutlich Loki/Grafana als Node-uebergreifende Sammelstelle mit Retention, Suche und Alerts. Prioritaet mittel.
- DB-Slow-Query-Log — heute nicht aktiv; per Custom-DB-Config einzeln
aktivierbar (
slow_query_log = 1,long_query_time = 1). - Auditierbare Backup-/Restore-Events als CSV/JSON-Export — heute nur im Admin sichtbar, nicht exportierbar.
- Web-Log-Viewer fuer Endkunden — heute nur Reseller sieht Logs im Panel; geplant eigene Kunden-Ansicht mit den letzten N Zeilen der eigenen Sub.
Datenschutz-Hinweis
Access-Logs enthalten IP-Adressen der Website-Besucher. Diese werden nach DSGVO-Standard 30 Tage aufbewahrt (per Docker-Log-Rotation faktisch weniger). Wenn Sie kuerzere Aufbewahrung brauchen: sagen Sie Bescheid, wir konfigurieren Log-Rotation entsprechend.
Fragen?
Bei Fragen zu Log-Zugriff / Retention / Exports einfach melden — die meisten Punkte oben sind Config-Aenderungen, keine Software-Aenderungen.