# Monitoring — externer PHP-Webspace (0012.de)
Der vServer **`boka`** (`89.163.231.180`) wird von **`0012.de`** (wint.global Classic 1.0, Plesk-Cron) aus überwacht. Der Webspace sieht den Server von außen — interne Metriken (Disk, Docker) brauchen ein Push-Skript auf boka oder eine Status-API.
**Webspace:** unabhängig von boka gehostet — fällt der VPS aus, kann 0012.de noch alarmieren.
Siehe auch: [`todo/03-monitoring-pull-phase1.md`](todo/03-monitoring-pull-phase1.md), [`todo/04-monitoring-push-boka.md`](todo/04-monitoring-push-boka.md), [`HOSTING.md`](HOSTING.md)
---
## Architektur (empfohlen)
### Ebene 1 — Pull (PHP-Cron auf Webspace, alle 5–15 Min)
- HTTPS-Checks auf öffentliche URLs
- SSL-Zertifikat-Ablauf
- Optional: TCP-Checks (Gitea SSH, RustDesk)
- Bei Fehler: E-Mail / Telegram (nach 2. Versuch, 2 Min Abstand → weniger Fehlalarme)
### Ebene 2 — Push (Cron auf boka, alle 5 Min)
- Kleines Skript postet JSON an `ingest.php` auf dem Webspace (Token-geschützt)
- Payload z. B.: `load`, `disk_percent`, `mem_available`, `containers_running`, `containers_unhealthy`
- Webspace-Cron: **kein Push seit 15 Min** → Server oder Netzwerk tot
- Optional: `disk > 85%`, `unhealthy > 0`, Backup-Heartbeat
---
## Prio **high** — zuerst umsetzen
| Was | Wie (extern) | Warum |
|-----|----------------|-------|
| HTTPS-Erreichbarkeit kritischer Domains | `curl` / `file_get_contents`, Timeout ~10s, Status 200/301 | Einzelne Apps können down sein, ohne dass es auffällt (z. B. bringtake) |
| Traefik / Edge | `https://schwenk.online` + eine App-Domain + `https://gitea.schwenk.online` | Fällt Traefik oder Let's Encrypt aus, sind viele Sites betroffen |
| Gitea | HTTPS, optional Login-Seite erreichbar | Zentrale Git-/CI-Basis |
| Immich | `https://pics.schwenk.online` | Fotos, großer Datenbestand |
| SSL-Zertifikat-Ablauf | TLS-Handshake prüfen, Warnung bei < 14 Tagen | Ablauf oder verlorenes `acme.json` = Ausfall vieler Dienste |
| Backup-Heartbeat | Server pingt nach erfolgreichem Backup den Webspace; Cron alarmiert bei **keinem Ping seit 25h** | Sobald Backups existieren: kritisch |
| Alarm bei Ausfall | E-Mail oder Telegram vom PHP-Cron | Externer Beobachter ohne Zugang zu boka |
### Mindest-URL-Liste (Start)
- `https://schwenk.online`
- `https://gitea.schwenk.online`
- `https://pics.schwenk.online`
- `https://medis.schwenk.online`
- `https://portainer.schwenk.online`
- Eine `bsc-gp.de`-Subdomain (z. B. `https://score.bsc-gp.de`)
- `https://vfb.red`
---
## Prio **medium** — bald sinnvoll
| Was | Wie (extern) | Warum |
|-----|----------------|-------|
| Weitere App-Domains | HTTP-Check pro Stack | Viele kleine Sites; einzelne Container können sterben |
| API-Health | z. B. `https://api.bringtake.schwenk.online/health` | Frontend kann 200 liefern, Backend tot |
| Antwortzeit | Dauer messen, Warnung bei > 5s | Frühwarnung bei Last (Immich ML, viele Container) |
| Inhalt prüfen | Marker-String im HTML (`
`, fester Text) | Erkennt „200 aber leere/falsche Seite“ |
| HTTP→HTTPS-Redirect | `http://domain` → 301/308 | Kaputter Redirect = Browser-Warnungen |
| DNS-Auflösung | `gethostbyname` / DNS-API | Domain zeigt plötzlich woanders hin |
| Gitea SSH | TCP-Check Port **2222** (`fsockopen`) | Git per SSH unabhängig von der Web-UI |
| RustDesk | TCP **21115–21117** (falls genutzt) | Kein HTTP möglich |
| SSL pro Subdomain | Einzelcheck je Host | Nicht jeder Host nutzt dasselbe Zertifikat |
| Push-Status vom Server | `POST` an Webspace mit Token + JSON | Disk/RAM/Container sonst von außen unsichtbar |
### Weitere URLs (medium, nach und nach)
- `https://affen.schwenk.online`
- `https://bringtake.schwenk.online`
- `https://api.bringtake.schwenk.online`
- `https://link.schwenk.online`
- `https://traefik.schwenk.online` (nur wenn Dashboard öffentlich bleiben soll)
- Weitere `*.schwenk.online` und `*.bsc-gp.de` laut Inventory
---
## Prio **low** — nice to have
| Was | Wie (extern) | Warum |
|-----|----------------|-------|
| Alle ~25 Domains einzeln | Lange Checkliste | Hoher Pflegeaufwand; Stichproben reichen oft |
| Security Headers | HSTS, `X-Frame-Options` | Sicherheit, kein Verfügbarkeitsproblem |
| TLS-Version / Cipher | Nur TLS 1.2+ | Selten akut |
| Port-Scan light | 22, 80, 443, 2222 erwartet; **5432 nicht** offen | Postgres soll nicht öffentlich sein |
| Blacklist / Malware-Scan | Externe API | Für Homelab meist overkill |
| WHOIS / Domain-Ablauf | Registrar-API | Oft ohnehin Mail vom Registrar |
| Öffentliche Feeds | RSS/iCal-Outputs | Nur wenn businesskritisch |
| Synthetic Login | Formular-POST mit Test-User | Aufwendig, bricht bei UI-Änderungen |
| Response-Größe | Plötzlich sehr kleine Antwort | Selten nötig |
| Uptime-Dashboard / SLA | DB auf Webspace | Nach echten Checks |
---
## Von außen schlecht prüfbar (ohne Hilfsskript auf boka)
| Intern | Lösung |
|--------|--------|
| Disk voll, RAM, Load | Push-Endpoint (Ebene 2) |
| `docker ps`, exited containers | Status-JSON von boka pushen |
| Log-Fehler, OOM | Push oder zentraler Log-Dienst |
| Dangling volumes, Backup-Größe | Nur auf dem Host |
| fail2ban / SSH-Bruteforce | Auth-Log per Push oder separater Dienst |
**Pragmatisch:** `monitor-push.sh` auf boka (Cron alle 5 Min) → POST an Webspace:
```json
{
"token": "...",
"load": [1.2, 0.8, 0.5],
"disk_percent": 55,
"mem_available_mb": 4700,
"containers_running": 38,
"containers_unhealthy": 0,
"backup_last_success": "2026-06-10T03:00:00+02:00"
}
```
---
## Umsetzung in Phasen
### Phase 1 (high, ~1h)
- 8–12 HTTPS-URLs aus der Mindestliste
- SSL-Ablauf < 14 Tage → Warnung
- E-Mail bei Fehler, Retry nach 2 Minuten
### Phase 2 (medium)
- API-Health für Stacks mit Backend (bringtake, medis, affen, …)
- Latenz-Schwelle
- Backup-Heartbeat (sobald `todo/05-automated-backups.md` erledigt)
- Push-Status von boka
### Phase 3 (low)
- Restliche Domains, Header-Checks, Dashboard
---
## Dateien (geplant)
| Ort | Datei | Zweck |
|-----|-------|--------|
| Webspace | `monitor.php` | Cron: Pull-Checks, Alarm |
| Webspace | `ingest.php` | Empfang Push von boka |
| boka | `~/server/scripts/push-status.sh` | Sammelt Metriken, POST an Webspace |
| boka | Crontab | `*/5 * * * *` push-status + ggf. nach Backup |
---
## Hinweise
- **Portainer** und **Traefik-Dashboard** öffentlich monitoren = öffentlich bestätigen, dass sie erreichbar sind. Basic Auth beibehalten; Monitoring prüft nur Erreichbarkeit (und ggf. 401 als „ok“).
- **Exit 401/403** kann bei geschützten Diensten **erwünscht** sein — Checks pro Host konfigurieren.
- Externer Monitor ersetzt kein **fail2ban** oder **UFW-Audit** auf boka (separates boka-Repo).