Kapitel 15/Premium Rohtext.md aktualisiert
This commit is contained in:
Thomas committed
1 parent
d336e13525
commit
680a2e6f00
1 file changed
+194
@@ -347,4 +347,198 @@ für kleine bis mittlere Homelab-Umgebungen (1–4 vCPUs, 2–8 GB RAM):
|
||||
Damit ist dein System vorbereitet, um Ereignisse automatisch zu erkennen und weiterzugeben.
|
||||
Im nächsten Abschnitt verbinden wir Netdata mit **n8n**, um auf diese Ereignisse gezielt zu reagieren.
|
||||
|
||||
---
|
||||
|
||||
## Integration in n8n (automatisierte Aktionen)
|
||||
|
||||
Mit der Integration in n8n wird Netdata vom Überwachungswerkzeug zum aktiven Reaktionssystem.
|
||||
Kritische Alarme führen automatisch zu Maßnahmen – etwa dem Neustart eines Containers oder einer Benachrichtigung im Discord-Kanal.
|
||||
Damit kannst du Systemfehler erkennen, protokollieren und gleichzeitig automatisiert beheben lassen.
|
||||
|
||||
👉 **Screenshot geeignet:** Übersicht – Netdata (LXC 1) → HTTPS → n8n (LXC 2) → Proxmox API → Discord
|
||||
|
||||
### Voraussetzungen
|
||||
|
||||
Für die Verbindung von Netdata und n8n sind einige technische Vorbereitungen nötig.
|
||||
|
||||
1. **n8n-Container** ist eingerichtet und über HTTPS erreichbar, z. B. unter
|
||||
`https://n8n.deinedomain.tld`
|
||||
2. **Beide Container** (Netdata und n8n) liegen im gleichen internen Netzwerk und können sich gegenseitig erreichen.
|
||||
Test im Netdata-Container:
|
||||
```bash
|
||||
curl -k https://n8n.deinedomain.tld
|
||||
```
|
||||
Wenn eine gültige HTTP-Antwort erscheint, funktioniert die Verbindung.
|
||||
3. **Nginx Proxy Manager** leitet Anfragen auf den n8n-Container weiter (Port 443).
|
||||
4. Für den automatischen Neustart von Containern wird ein **Proxmox-API-Token** benötigt.
|
||||
|
||||
#### Proxmox-API-Token erstellen
|
||||
|
||||
Damit n8n Container über die Proxmox-API steuern darf, muss zuerst ein Zugriffstoken angelegt werden.
|
||||
|
||||
1. Im Proxmox-Webinterface (`https://pve.deinedomain.tld:8006`) anmelden.
|
||||
2. Menü öffnen: **Datacenter → Permissions → API Tokens**
|
||||
3. **Add → API Token** wählen
|
||||
4. Werte:
|
||||
- **User:** `root@pam` oder ein dedizierter Automatisierungs-User
|
||||
- **Token ID:** `n8n-auto`
|
||||
- **Expire:** leer lassen (dauerhaft gültig)
|
||||
- **Privilege Separation:** aktivieren
|
||||
5. Unter **Datacenter → Permissions → Add → User Permission**:
|
||||
- **Path:** `/`
|
||||
- **User/Token:** `<USER>@pam!n8n-auto`
|
||||
- **Role:** `PVEAdmin` (alternativ eigene Rolle mit `VM.Audit` und `VM.PowerMgmt`)
|
||||
6. Den generierten Token notieren:
|
||||
```
|
||||
PVEAPIToken=<USER>@pam!n8n-auto=<APIKEY>
|
||||
```
|
||||
|
||||
👉 **Screenshot geeignet:** Proxmox – API-Token-Erstellungsfenster mit aktivierter Privilege Separation
|
||||
|
||||
> [!TIP]
|
||||
> Bewahre den Token sicher auf, z. B. in Vaultwarden.
|
||||
> Er ersetzt ein Passwort und erlaubt API-Zugriffe.
|
||||
|
||||
### 1 – Webhook: Alarm von Netdata empfangen
|
||||
|
||||
**Zweck:**
|
||||
Der Webhook empfängt Netdata-Alarme als JSON-Payload und startet den Workflow.
|
||||
|
||||
**Node-Typ:** Webhook
|
||||
**Name:** Eingang – Netdata Alert
|
||||
|
||||
**Einstellungen:**
|
||||
- **HTTP Method:** POST
|
||||
- **Path:** `/netdata/alert`
|
||||
- **Response Mode:** On Received
|
||||
- **Response Code:** 200
|
||||
- **Response Data:** JSON
|
||||
- **Webhook URL:** `https://n8n.deinedomain.tld/webhook/netdata/alert`
|
||||
|
||||
👉 **Screenshot geeignet:** n8n – Webhook-Node mit sichtbarer Production-URL und aktivem Workflow
|
||||
|
||||
> [!NOTE]
|
||||
> Diese URL wird später im Netdata-Container im Benachrichtigungsscript eingetragen,
|
||||
> damit Alarme automatisch an n8n gesendet werden.
|
||||
|
||||
### 2 – IF: Nur bei kritischen Alarmen reagieren
|
||||
|
||||
**Zweck:**
|
||||
Filtert eingehende Alarme. Nur wenn der Status `"CRITICAL"` lautet, werden Folgeaktionen ausgeführt.
|
||||
|
||||
**Node-Typ:** IF
|
||||
**Name:** Bedingung – Kritischer Alarm?
|
||||
|
||||
**Einstellungen:**
|
||||
- **Parameter 1:** `{{$json["status"]}}`
|
||||
- **Operation:** Equal
|
||||
- **Value:** `CRITICAL`
|
||||
|
||||
**TRUE-Pfad:** führt zur Reaktion (Container-Neustart)
|
||||
**FALSE-Pfad:** beendet den Workflow ohne Aktion
|
||||
|
||||
👉 **Screenshot geeignet:** n8n – IF-Node mit Vergleich `status == CRITICAL`
|
||||
|
||||
> [!TIP]
|
||||
> Weitere Bedingungen sind möglich, z. B. Hostname enthält „Nextcloud“ oder „Proxy“.
|
||||
|
||||
### 3 – HTTP Request: Container über Proxmox API neu starten (TRUE-Pfad)
|
||||
|
||||
**Zweck:**
|
||||
Startet automatisch den betroffenen Container neu, sobald Netdata einen kritischen Alarm meldet.
|
||||
|
||||
**Node-Typ:** HTTP Request
|
||||
**Name:** HTTP – Proxmox Neustart
|
||||
|
||||
**Einstellungen:**
|
||||
- **Method:** POST
|
||||
- **URL:** `https://pve.deinedomain.tld:8006/api2/json/nodes/pve/lxc/<CTID>/status/restart`
|
||||
- **Authentication:** Header
|
||||
- **Header Parameter:**
|
||||
- `Authorization`: `PVEAPIToken=<USER>@pam!n8n-auto=<APIKEY>`
|
||||
- `Content-Type`: `application/json`
|
||||
|
||||
👉 **Screenshot geeignet:** n8n – HTTP Request-Node mit Proxmox-URL und eingetragenen Headern
|
||||
|
||||
> [!NOTE]
|
||||
> `<CTID>` ist die ID des Containers, der neu gestartet werden soll.
|
||||
> Diese kannst du dynamisch aus der Alarmmeldung übernehmen oder fest im Node hinterlegen.
|
||||
|
||||
> [!TIP]
|
||||
> Für häufig genutzte Container (z. B. Pi-hole, Nextcloud) lohnt sich ein eigener Workflow mit fester ID.
|
||||
|
||||
### 4 – HTTP Request: Discord-Benachrichtigung senden (TRUE-Pfad)
|
||||
|
||||
**Zweck:**
|
||||
Sendet nach erfolgreicher Aktion eine Meldung an deinen Discord-Kanal,
|
||||
damit alle automatisierten Maßnahmen dokumentiert sind.
|
||||
|
||||
**Node-Typ:** HTTP Request
|
||||
**Name:** HTTP – Discord Notification
|
||||
|
||||
**Einstellungen:**
|
||||
- **Method:** POST
|
||||
- **URL:** `https://discord.com/api/webhooks/<DEINE_WEBHOOK_ID>/<DEIN_TOKEN>`
|
||||
- **Send Body:** aktivieren
|
||||
- **Content Type:** JSON
|
||||
- **Body Parameters:**
|
||||
- `content`:
|
||||
```
|
||||
🔔 **Netdata Alarm:** {{$json["alarm"]}}
|
||||
🖥 Host: {{$json["host"]}}
|
||||
⚠️ Status: {{$json["status"]}}
|
||||
✅ Maßnahme: Container wurde automatisch neu gestartet.
|
||||
```
|
||||
|
||||
👉 **Screenshot geeignet:** n8n – HTTP Request-Node mit sichtbarer Discord-Webhook-URL und JSON-Body
|
||||
|
||||
> [!TIP]
|
||||
> Verwende für Systemmeldungen einen separaten Kanal wie `#alerts`.
|
||||
> So bleiben technische Benachrichtigungen klar vom restlichen Serververkehr getrennt.
|
||||
|
||||
### 5 – Workflow testen
|
||||
|
||||
1. Workflow in n8n aktivieren
|
||||
2. Im Netdata-Container Test ausführen:
|
||||
```bash
|
||||
sudo su -s /bin/bash netdata
|
||||
export NETDATA_ALARM_NOTIFY_DEBUG=1
|
||||
/usr/libexec/netdata/plugins.d/alarm-notify.sh test
|
||||
```
|
||||
3. Prüfen:
|
||||
- Discord zeigt Testnachricht
|
||||
- n8n meldet erfolgreichen HTTP-Aufruf
|
||||
- Proxmox-Container hat den Neustart ausgeführt
|
||||
|
||||
👉 **Screenshot geeignet:** Discord-Kanal `#alerts` mit Testmeldung „Netdata Notification – This is a test“
|
||||
|
||||
> [!TIP]
|
||||
> Wenn keine Reaktion erfolgt, überprüfe:
|
||||
> - Erreicht Netdata die n8n-URL (Firewall, DNS)
|
||||
> - Ist der Pfad `/netdata/alert` korrekt?
|
||||
> - Enthält das Netdata-Script die vollständige Webhook-Adresse?
|
||||
> - Ist das Proxmox-API-Token aktiv und mit passenden Rechten versehen?
|
||||
|
||||
---
|
||||
|
||||
## Ergebnis
|
||||
|
||||
Nach der Einrichtung kommunizieren Netdata und n8n direkt miteinander.
|
||||
Sobald Netdata einen kritischen Zustand erkennt, übergibt es die Daten automatisch an den n8n-Workflow.
|
||||
Dieser bewertet das Ereignis, startet den betroffenen Container neu und dokumentiert den Vorgang im Discord-Kanal.
|
||||
|
||||
Damit ist dein Monitoring nicht mehr nur ein passives Anzeigesystem, sondern ein **aktives Kontrollzentrum**, das selbstständig auf Ausfälle reagiert.
|
||||
Alle Abläufe bleiben dabei vollständig in deiner Infrastruktur – ohne Cloud-Abhängigkeiten, ohne externe APIs.
|
||||
|
||||
Deine Automatisierung besteht nun aus:
|
||||
|
||||
- **Netdata (LXC 1):** überwacht, erkennt und meldet Systemzustände
|
||||
- **n8n (LXC 2):** empfängt Alarme, analysiert und führt Aktionen aus
|
||||
- **Proxmox API:** ermöglicht den Neustart betroffener Container
|
||||
- **Discord (optional):** dient als transparente Status- und Benachrichtigungsoberfläche
|
||||
|
||||
👉 **Screenshot geeignet:** Diagramm – Zusammenspiel von Netdata, n8n, Proxmox und Discord mit markierten Datenflüssen
|
||||
|
||||
> [!TIP]
|
||||
> Wenn du weitergehende Automatisierungen nutzen möchtest, etwa das Anlegen von Tickets, das Schreiben in Logdatenbanken oder das Erfassen von Ausfallzeiten,
|
||||
> empfehlen wir dir die **kostenpflichtige Erweiterung zu diesem Kapitel** oder unseren **Premium-Kurs zur UCC-Automatisierung**.
|
||||
Reference in new issue
Block a user