Störungen eingrenzen

Übersicht

Bei einer Störung führt eine feste Reihenfolge am schnellsten zur Ursache: Zustand ansehen, Server prüfen, Dienste ansehen, letztes Protokoll lesen, Diagnosepaket schnüren. Die häufigsten Fehlerbilder lassen sich damit in wenigen Minuten eingrenzen.

Voraussetzungen

Zugang zum Server mit Root-Rechten
Die genaue Uhrzeit, seit wann die Störung auftritt

Schritt-für-Schritt-Anleitung

Zustand und Server prüfen
```
sudo wsp status
sudo wsp doctor
```

Dienste ansehen

sudo docker stack services wsp
sudo docker stack ps wsp --no-trunc

Letztes Protokoll lesen

ls -lt /var/log/wsp/ | head -3
sudo less /var/log/wsp/<neueste-datei>

Die Anwendung von innen und außen prüfen
```
curl -sS http://127.0.0.1:3001/health
sudo systemctl status nginx
sudo nginx -t
sudo tail -50 /var/log/nginx/error.log
```
- Antwortet Schritt 1, von außen aber nichts: nginx, Firewall oder DNS prüfen
- Antwortet Schritt 1 nicht, obwohl Dienste laufen: die Anwendung startet noch oder hängt in einer Neustartschleife
- Zeigt ein Dienst 0/1: sudo docker service logs wsp_<name> --tail 100
Diagnosepaket schnüren und den Support einschalten

Niemand kann sich anmelden

Ursache	Prüfung
Systemuhr falsch	`timedatectl`
Signaturschlüssel erneuert	`/var/log/wsp/` nach `rotate`
Lizenz abgelaufen	Einstellungen → Lizenz
Datenbank nicht erreichbar	`docker service ps wsp_postgres-workspace`

Bei falscher Systemuhr hilft sudo timedatectl set-ntp true. Wurde ein Signaturschlüssel erneuert, ist die Neuanmeldung aller Nutzer erwartet.

Es kommen keine E-Mails an

Absender und Zugang prüfen: EMAIL_FROM, SMTP_HOST, SMTP_PORT, SMTP_USER in /etc/wsp/env
Passwort prüfen: es steht in /etc/wsp/secrets/smtp_password, nicht in /etc/wsp/env
Erreichbarkeit prüfen: nc -zv mail.beispiel.de 587
Protokoll ansehen: sudo docker service logs wsp_workspaceapi --tail 200 | grep -i mail
Beim Empfänger in den Spam-Ordner sehen und SPF und DKIM prüfen

Häufigster Fall: Die Zugangsdaten wurden nach der Installation geändert, aber die Dienste laufen noch mit den alten Werten.

Die Anwendung ist langsam

df -h /var
free -h
uptime
sudo docker stats --no-stream

Häufigste Ursachen: zu wenig Arbeitsspeicher bei fehlender Auslagerungsdatei, volle Festplatte, zu wenig Prozessorkerne für die Zahl der Nutzer.

Häufige Fehler und Tipps

Hinweis: Docker-Ablagen, die mit wsp_ beginnen, nie löschen.
- Dort liegen Ihre Daten.
Hinweis: Nach einem Fehlschlag bei der Migration nicht erneut updaten.
- Die Datenbank kann in einem Zwischenzustand sein. Erst der Support.
Hinweis: Die Sperrdatei /var/lib/wsp/wsp.lock nicht löschen, während ein Lauf arbeitet.
- Nach einem Absturz übernimmt wsp die verwaiste Sperre beim nächsten Start von selbst.
Hinweis: /var/lib/wsp/state.json nicht von Hand bearbeiten.
- Sie ist die Grundlage für Update, Rückroll und Sicherung.
Hinweis: Den Stack nicht von Hand mit docker stack deploy ausrollen.
- Es fehlen dann Werte, die wsp zusammenstellt, und der Stack startet unvollständig.

Was tue ich, wenn meine Instanz nicht erreichbar ist?