Monitoring

Dokumenttyp: Developer Playbook
Status: Draft v0.2
Stand: 2026-06-30
Prinzip: Allgemeine Anleitung mit Praxisbeispiel aus Immohai

Ziel

Dieses Dokument erklärt, was Monitoring ist, warum es für Webprojekte wichtig ist und welche einfachen Prüfungen für private und kleinere professionelle Projekte ausreichen.

Monitoring bedeutet: regelmäßig prüfen, ob Server, Dienste und öffentliche URLs funktionieren.

Kurz erklärt

Monitoring beantwortet die Frage:

Läuft mein System gerade so, wie es laufen soll?

Dabei geht es zum Beispiel um:

• Ist der Server erreichbar?
• Läuft Docker?
• Laufen die Container?
• Läuft Nginx?
• Funktionieren die öffentlichen URLs?
• Funktioniert HTTPS?
• Ist genug Speicherplatz frei?
• Gibt es auffällige Fehler?

Warum Monitoring wichtig ist

Ohne Monitoring merkt man Fehler oft erst, wenn eine App nicht mehr erreichbar ist.

Monitoring hilft dabei:

• Ausfälle früher zu erkennen
• Fehler einzugrenzen
• Speicherprobleme zu vermeiden
• abgelaufene Zertifikate zu erkennen
• Container-Probleme zu finden
• Serverzustand nachvollziehbar zu prüfen

Für kleine Projekte muss Monitoring nicht sofort kompliziert sein. Am Anfang reicht eine einfache manuelle oder halbautomatische Prüfstruktur.

Monitoring und Logging

Monitoring und Logging sind verwandt, aber nicht dasselbe.

Begriff	Bedeutung
Monitoring	Prüft Zustand und Erreichbarkeit
Logging	Speichert Ereignisse und Fehlermeldungen

Einfach gesagt:

Monitoring sagt: Etwas ist kaputt.
Logging hilft zu verstehen: Warum ist es kaputt?

Beispiel:

Monitoring:
https://immohai.ohaisoft.com antwortet nicht.

Logging:
Nginx-Log zeigt 502 Bad Gateway.
Docker-Log zeigt Containerfehler.

Ebenen des Monitorings

Ein Webprojekt sollte auf mehreren Ebenen geprüft werden.

öffentliche URL
↓
HTTPS
↓
Nginx
↓
lokaler Port
↓
Docker-Container
↓
Server

Wenn eine Ebene nicht funktioniert, wird von außen nach innen geprüft.

1. Server-Erreichbarkeit prüfen

Vom lokalen Rechner:

ping <server-ip>

Beispiel:

ping 46.225.28.194

Hinweis:

Nicht jeder Server beantwortet Ping. Wenn Ping nicht funktioniert, heißt das nicht automatisch, dass der Server offline ist.

Besser ist zusätzlich ein SSH-Test:

ssh <server-alias>

Oder direkt:

ssh fober@46.225.28.194

2. Systemstatus prüfen

Auf dem Server:

uptime

Zeigt:

• wie lange der Server läuft
• wie viele Benutzer angemeldet sind
• grobe Systemlast

Speicher prüfen:

free -h

Festplatte prüfen:

df -h

Prozesse anzeigen:

top

Alternativ, falls installiert:

htop

3. Docker prüfen

Docker-Dienst prüfen:

sudo systemctl status docker

Container prüfen:

docker ps

Übersichtlicher:

docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"

Docker Compose im Projekt prüfen:

docker compose ps

4. Lokale Dienste prüfen

Bevor die öffentliche URL geprüft wird, sollte der lokale Dienst auf dem Server getestet werden.

Beispiele:

curl -I http://127.0.0.1:8100
curl -I http://127.0.0.1:8200
curl -I http://127.0.0.1:8201

Erwartung:

HTTP/1.1 200 OK

oder ein anderer erfolgreicher Status.

Wenn der lokale Dienst nicht funktioniert, liegt das Problem wahrscheinlich bei Docker oder der App.

5. Nginx prüfen

Status prüfen:

sudo systemctl status nginx

Konfiguration prüfen:

sudo nginx -t

Erwartung:

syntax is ok
test is successful

Nginx neu laden:

sudo systemctl reload nginx

Nur nach erfolgreichem nginx -t neu laden.

6. Öffentliche URLs prüfen

Öffentliche App prüfen:

curl -I https://app.example.com

Praxisbeispiel:

curl -I https://playbook.ohaisoft.com
curl -I https://immohai.ohaisoft.com
curl -I https://docs.immohai.ohaisoft.com

Erwartung:

HTTP/2 200

oder:

HTTP/1.1 200 OK

Eine Weiterleitung von HTTP auf HTTPS prüfen:

curl -I http://immohai.ohaisoft.com

Erwartung:

301 Moved Permanently

oder eine vergleichbare Weiterleitung auf HTTPS.

7. HTTPS-Zertifikate prüfen

Certbot-Zertifikate anzeigen:

sudo certbot certificates

Automatische Erneuerung testen:

sudo certbot renew --dry-run

Erwartung:

Congratulations, all simulated renewals succeeded

Dieser Test sollte nach der Einrichtung und nach größeren Nginx-Änderungen durchgeführt werden.

8. Speicherplatz prüfen

Speicherplatz ist bei kleinen Servern ein häufiger Engpass.

Prüfen:

df -h

Docker-Speicher prüfen:

docker system df

Wenn Docker viel Speicher belegt:

docker images
docker ps -a

Aufräumen nur bewusst durchführen.

Nicht blind ausführen, wenn produktive Daten oder Volumes betroffen sein könnten.

9. Logs prüfen

Monitoring zeigt den Zustand. Logs helfen bei der Ursache.

Wichtige Befehle:

docker compose logs --tail=100
sudo journalctl -u nginx --no-pager -n 100
sudo tail -n 100 /var/log/nginx/error.log

Das Thema Logging wird im nächsten Kapitel separat beschrieben.

Einfacher Prüfblock

Für kleine Projekte reicht am Anfang ein manueller Prüfblock.

Praxisbeispiel:

cd /home/fober/workspace/developer-playbook
git status
docker compose ps
curl -I http://127.0.0.1:8100
curl -I https://playbook.ohaisoft.com

cd /home/fober/projects/immohai
git status
docker compose ps
curl -I http://127.0.0.1:8200
curl -I http://127.0.0.1:8201
curl -I https://immohai.ohaisoft.com
curl -I https://docs.immohai.ohaisoft.com

sudo nginx -t
sudo systemctl status nginx
sudo certbot renew --dry-run
df -h
docker system df

Praxisbeispiel Immohai

Aktuell zu prüfende Dienste:

Dienst	Öffentliche URL	Lokaler Port	Container
Developer Playbook	https://playbook.ohaisoft.com	127.0.0.1:8100	developer-playbook-docs
Immohai App	https://immohai.ohaisoft.com	127.0.0.1:8200	immohai-web
Immohai Dokumentation	https://docs.immohai.ohaisoft.com	127.0.0.1:8201	immohai-docs

Prüfen:

curl -I https://playbook.ohaisoft.com
curl -I https://immohai.ohaisoft.com
curl -I https://docs.immohai.ohaisoft.com

Einfache Monitoring-Routine

Für kleine Projekte reicht am Anfang eine regelmäßige manuelle Prüfung.

Empfehlung:

Häufigkeit	Prüfung
nach jeder Änderung	docker compose ps, curl -I, nginx -t
wöchentlich	Speicherplatz, Docker-Status, Zertifikate
monatlich	Updates, Backups, Logs grob prüfen
nach Nginx-/DNS-Änderungen	öffentliche URLs und Certbot Renewal testen

Später mögliche Monitoring-Werkzeuge

Für größere oder professionellere Setups können später Werkzeuge ergänzt werden.

Beispiele:

Werkzeug	Zweck
Uptime Kuma	einfache Weboberfläche für Uptime-Monitoring
Netdata	Servermetriken in Echtzeit
Prometheus	Metriken sammeln
Grafana	Metriken visualisieren
Healthchecks.io	geplante Tasks überwachen
Better Stack	Uptime, Logs und Alerts als Dienst

Für den Anfang ist ein manuelles Prüfkonzept ausreichend.

Typische Fehler

Fehler	Ursache	Lösung
öffentliche URL nicht erreichbar	DNS, Nginx oder Containerproblem	von außen nach innen prüfen
lokaler Port nicht erreichbar	Container läuft nicht	docker compose ps und Logs prüfen
HTTPS funktioniert nicht	Zertifikat oder Nginx falsch	Certbot und Nginx prüfen
Nginx zeigt 502	lokaler Dienst nicht erreichbar	proxy_pass und Container prüfen
Server langsam	CPU, RAM oder Disk voll	top, free -h, df -h prüfen
Docker belegt viel Speicher	alte Images oder Container	Docker-Speicher prüfen
Zertifikat läuft ab	Renewal funktioniert nicht	certbot renew --dry-run prüfen

Best Practices

• Monitoring immer von außen nach innen denken.
• Nach jeder Änderung öffentliche URLs testen.
• Lokale Ports separat testen.
• Docker-Status regelmäßig prüfen.
• Speicherplatz regelmäßig prüfen.
• Certbot Renewal testen.
• Logs nicht ignorieren.
• Monitoring-Befehle dokumentieren.
• Für kleine Projekte einfach starten.
• Später bei Bedarf automatisiertes Monitoring ergänzen.

Checkliste

• [ ] Server erreichbar
• [ ] Docker läuft
• [ ] Container laufen
• [ ] lokale Ports erreichbar
• [ ] Nginx läuft
• [ ] sudo nginx -t erfolgreich
• [ ] öffentliche HTTP/HTTPS-URLs geprüft
• [ ] Certbot Renewal getestet
• [ ] Speicherplatz geprüft
• [ ] Docker-Speicher geprüft
• [ ] Logs bei Fehlern geprüft
• [ ] Monitoring-Routine festgelegt