Kapitel 15/Premium Rohtext.md hinzugefügt
This commit is contained in:
350
Kapitel 15/Premium Rohtext.md
Normal file
350
Kapitel 15/Premium Rohtext.md
Normal file
@@ -0,0 +1,350 @@
|
|||||||
|
# Premium – Netdata: Automatisierung, Alarmierung & Benutzerverwaltung
|
||||||
|
|
||||||
|
Netdata ist im UCC weit mehr als ein reines Monitoring-Werkzeug.
|
||||||
|
Im Free-Kapitel wurde die Grundlage gelegt – ein zentraler Container mit Echtzeit-Dashboard und Streaming-Verbindungen zu allen LXC-Systemen.
|
||||||
|
Dieser Premium-Teil erweitert die Installation zu einem **aktiven Kontrollsystem**, das Zustände nicht nur überwacht,
|
||||||
|
sondern automatisch auf Fehler, Engpässe oder Ausfälle reagiert.
|
||||||
|
|
||||||
|
Ziel ist ein **intelligentes Monitoring-Cluster**, das Warnmeldungen generiert, Log-Daten auswertet und über **n8n-Workflows** Aktionen auslöst –
|
||||||
|
etwa Neustarts, Benachrichtigungen per Mail oder Discord, oder das Sperren fehlerhafter Container.
|
||||||
|
Zusätzlich lernst du, wie du im Netdata-Dashboard **Benutzerkonten und Rollen** anlegst, um den Zugriff im Team klar zu regeln.
|
||||||
|
|
||||||
|
👉 **Screenshot geeignet:** Architekturdiagramm mit Datenfluss zwischen Netdata (Parent), n8n und den überwachten LXC-Containern
|
||||||
|
|
||||||
|
> [!NOTE]
|
||||||
|
> Dieses Kapitel baut auf einer vollständig funktionierenden Free-Installation auf.
|
||||||
|
> Stelle sicher, dass dein zentraler Netdata-Container läuft und bereits mit allen relevanten LXC-Containern verbunden ist.
|
||||||
|
|
||||||
|
Im Ergebnis entsteht ein automatisiertes Frühwarnsystem, das Probleme erkennt, bevor sie kritisch werden –
|
||||||
|
ideal für Content-Creator, Streamer und kleine Teams, die ihr Homelab effizient und sicher betreiben möchten.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Benutzer- und Rollenverwaltung
|
||||||
|
|
||||||
|
Damit du Netdata sicher auch im Team oder in größeren Setups einsetzen kannst, bietet das Dashboard eine integrierte Benutzerverwaltung.
|
||||||
|
So kannst du den Zugriff gezielt einschränken, bestimmte Ansichten freigeben oder administrativen Zugriff trennen.
|
||||||
|
|
||||||
|
👉 **Screenshot geeignet:** Netdata-Dashboard mit geöffnetem Einstellungsmenü „User Management“
|
||||||
|
|
||||||
|
### Benutzerverwaltung aktivieren
|
||||||
|
|
||||||
|
1. Öffne die **Netdata-Weboberfläche** deines zentralen Containers:
|
||||||
|
```
|
||||||
|
https://monitor.deinedomain.tld
|
||||||
|
```
|
||||||
|
2. Klicke oben rechts auf das **Benutzersymbol → Settings → User Management**.
|
||||||
|
Wenn die Benutzerverwaltung noch nicht aktiviert ist, erscheint ein Hinweis, sie zu konfigurieren.
|
||||||
|
|
||||||
|
3. Aktiviere **Local User Management**.
|
||||||
|
Diese Option erlaubt das Anlegen lokaler Benutzer direkt im Container, ohne externe Authentifizierungsquelle.
|
||||||
|
|
||||||
|
> [!NOTE]
|
||||||
|
> Eine Integration über externe OAuth- oder LDAP-Server ist ebenfalls möglich,
|
||||||
|
> wird aber nur für größere Teams empfohlen.
|
||||||
|
> Für das Homelab reicht das lokale Benutzerkonzept vollkommen aus.
|
||||||
|
|
||||||
|
### Rollen anlegen
|
||||||
|
|
||||||
|
Netdata kennt drei Standardrollen, die du individuell anpassen kannst:
|
||||||
|
|
||||||
|
| Rolle | Beschreibung |
|
||||||
|
|--------|---------------|
|
||||||
|
| **Viewer** | Nur lesender Zugriff auf Dashboards und Statistiken. |
|
||||||
|
| **Editor** | Zugriff auf Dashboards und Benachrichtigungen, darf jedoch keine Systemeinstellungen ändern. |
|
||||||
|
| **Admin** | Vollzugriff auf alle Konfigurationen, Benachrichtigungen und Integrationen. |
|
||||||
|
|
||||||
|
Für dein UCC-System empfiehlt sich die folgende Struktur:
|
||||||
|
|
||||||
|
- **viewer** → allgemeiner Zugriff, z. B. zur Kontrolle von Systemauslastung
|
||||||
|
- **editor** → technischer Zugriff für Wartung, aber ohne Konfigurationsrechte
|
||||||
|
- **admin** → nur du bzw. Systembetreuer mit vollem Zugriff
|
||||||
|
|
||||||
|
👉 **Screenshot geeignet:** Rollenübersicht mit markierten Rechten für „viewer“, „editor“ und „admin“
|
||||||
|
|
||||||
|
> [!TIP]
|
||||||
|
> Lokale Benutzerkonten werden im Container unter `/var/lib/netdata/registry` verwaltet.
|
||||||
|
> Sichere diesen Ordner regelmäßig, wenn du mehrere Benutzer angelegt hast.
|
||||||
|
|
||||||
|
### Zugang für Team-Mitglieder
|
||||||
|
|
||||||
|
Neue Benutzer können über die Weboberfläche angelegt oder direkt per CLI erstellt werden:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
netdata-claim.sh --id <BENUTZERNAME> --role viewer
|
||||||
|
```
|
||||||
|
|
||||||
|
Anschließend erhält der Benutzer per Browserzugang die entsprechenden Rechte.
|
||||||
|
|
||||||
|
> [!NOTE]
|
||||||
|
> Lokale Benutzerkonten sind ausschließlich für den Zugriff auf das Dashboard relevant.
|
||||||
|
> API- oder Alarm-Integrationen laufen weiterhin über dedizierte Tokens,
|
||||||
|
> die im nächsten Abschnitt behandelt werden.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Alarmierung & Ereignisüberwachung
|
||||||
|
|
||||||
|
Netdata kann nicht nur messen, sondern aktiv auf Ereignisse reagieren.
|
||||||
|
Durch das integrierte Alarmsystem erkennst du Engpässe, Überlast oder Ausfälle in Echtzeit und wirst automatisch informiert – per E-Mail, Discord oder später über n8n.
|
||||||
|
So reagiert dein System frühzeitig, bevor kleine Probleme zu echten Ausfällen werden.
|
||||||
|
|
||||||
|
👉 **Screenshot geeignet:** Netdata-Dashboard mit geöffneter Alarmübersicht (CPU-, RAM- und Disk-Warnungen)
|
||||||
|
|
||||||
|
### Grundprinzip
|
||||||
|
|
||||||
|
Netdata überwacht hunderte Systemmetriken und prüft sie in kurzen Intervallen gegen definierte Grenzwerte („Health-Rules“).
|
||||||
|
Wenn eine Regel überschritten wird, erzeugt Netdata ein Alarm-Event, das an die hinterlegten Empfänger geschickt wird.
|
||||||
|
Damit das funktioniert, müssen zwei Dinge eingerichtet werden:
|
||||||
|
|
||||||
|
1. **Health-Rules** – bestimmen, wann ein Alarm ausgelöst wird
|
||||||
|
2. **Benachrichtigungskanäle** – legen fest, wohin Netdata die Warnung schickt
|
||||||
|
|
||||||
|
### Health-Rules anlegen
|
||||||
|
|
||||||
|
Die Standardregeln decken viele Szenarien ab (CPU, RAM, Festplatte, Netzwerk).
|
||||||
|
Für eigene Regeln werden lokale Dateien unter `/etc/netdata/health.d/` verwendet, damit Updates sie nicht überschreiben.
|
||||||
|
|
||||||
|
Beispiel:
|
||||||
|
Hohe CPU-Last soll ab 85 % eine Warnung und ab 95 % einen kritischen Alarm erzeugen.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
mkdir -p /etc/netdata/health.d
|
||||||
|
nano /etc/netdata/health.d/system_custom.conf
|
||||||
|
```
|
||||||
|
|
||||||
|
Inhalt:
|
||||||
|
|
||||||
|
```
|
||||||
|
alarm: high_cpu_usage
|
||||||
|
on: system.cpu
|
||||||
|
lookup: average -1m unaligned of user + system
|
||||||
|
units: %
|
||||||
|
every: 30s
|
||||||
|
warn: $this > 85
|
||||||
|
crit: $this > 95
|
||||||
|
to: sysadmin
|
||||||
|
info: CPU usage is too high
|
||||||
|
```
|
||||||
|
|
||||||
|
Speichern, schließen und Dienst neu starten:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
systemctl restart netdata
|
||||||
|
```
|
||||||
|
|
||||||
|
Nach dem Neustart findest du den neuen Eintrag in der Oberfläche unter **Health → Alarms**.
|
||||||
|
Dort kannst du Regeln aktivieren, deaktivieren oder live anpassen.
|
||||||
|
|
||||||
|
> [!TIP]
|
||||||
|
> Es ist empfehlenswert, für kritische Komponenten wie Datenbanken, Proxy-Container oder Nextcloud eigene Schwellenwerte zu definieren.
|
||||||
|
> So erkennst du Überlastungen frühzeitig und gezielt.
|
||||||
|
|
||||||
|
👉 **Screenshot geeignet:** Dashboard → Health → Alarms (eigene Regel „high_cpu_usage“ sichtbar)
|
||||||
|
|
||||||
|
### Benachrichtigungskanäle einrichten
|
||||||
|
|
||||||
|
Damit Alarme dich auch erreichen, müssen Kommunikationswege definiert werden.
|
||||||
|
Netdata unterstützt Dutzende Dienste – wir konzentrieren uns auf **E-Mail** und **Discord**, da sie sich leicht in bestehende Systeme einfügen.
|
||||||
|
|
||||||
|
#### Konfigurationsdatei öffnen
|
||||||
|
|
||||||
|
```bash
|
||||||
|
cd /etc/netdata 2>/dev/null || cd /opt/netdata/etc/netdata
|
||||||
|
./edit-config health_alarm_notify.conf
|
||||||
|
```
|
||||||
|
|
||||||
|
Diese Datei enthält alle Benachrichtigungsoptionen.
|
||||||
|
Suche den passenden Abschnitt für deinen Kanal und entferne das führende `#`, um ihn zu aktivieren.
|
||||||
|
|
||||||
|
#### E-Mail-Benachrichtigung (optional)
|
||||||
|
|
||||||
|
Ein funktionierendes Mailsystem ist in einer frischen Netdata-Installation **nicht vorhanden**.
|
||||||
|
Damit Netdata überhaupt E-Mails versenden kann, musst du zuerst ein leichtgewichtiges SMTP-Tool installieren.
|
||||||
|
Empfohlen wird `msmtp`, weil es einfach zu konfigurieren ist und direkt mit Netdata funktioniert.
|
||||||
|
|
||||||
|
##### Schritt 1 – Mailer installieren
|
||||||
|
|
||||||
|
```bash
|
||||||
|
apt install -y msmtp bsd-mailx
|
||||||
|
```
|
||||||
|
|
||||||
|
- `msmtp` sendet E-Mails über dein Mailkonto (ähnlich wie ein Mailprogramm)
|
||||||
|
- `bsd-mailx` stellt den Befehl `mail` bereit, den Netdata intern verwendet
|
||||||
|
|
||||||
|
##### Schritt 2 – Zugangsdaten einrichten
|
||||||
|
|
||||||
|
Erstelle oder bearbeite die Datei `/etc/msmtprc`:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
nano /etc/msmtprc
|
||||||
|
```
|
||||||
|
|
||||||
|
Beispielkonfiguration für gängige Mailanbieter (Platzhalter ersetzen):
|
||||||
|
|
||||||
|
```
|
||||||
|
defaults
|
||||||
|
auth on
|
||||||
|
tls on
|
||||||
|
tls_trust_file /etc/ssl/certs/ca-certificates.crt
|
||||||
|
|
||||||
|
account default
|
||||||
|
host smtp.mailprovider.tld
|
||||||
|
port 587
|
||||||
|
from netdata@deinedomain.tld
|
||||||
|
user DEIN_LOGINNAME
|
||||||
|
password DEIN_PASSWORT
|
||||||
|
logfile /var/log/msmtp.log
|
||||||
|
```
|
||||||
|
|
||||||
|
Speichern, schließen und Berechtigungen anpassen:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
chmod 600 /etc/msmtprc
|
||||||
|
```
|
||||||
|
|
||||||
|
##### Schritt 3 – Mailversand testen
|
||||||
|
|
||||||
|
Führe einen kurzen Test aus:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
echo "Testmail vom Netdata-System" | mail -s "Netdata Test" admin@deinedomain.tld
|
||||||
|
```
|
||||||
|
|
||||||
|
Wenn die E-Mail ankommt, funktioniert der Versand.
|
||||||
|
Erst **jetzt** kann Netdata Mails verschicken.
|
||||||
|
|
||||||
|
##### Schritt 4 – Netdata auf E-Mail konfigurieren
|
||||||
|
|
||||||
|
Öffne anschließend die Netdata-Konfiguration:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
cd /etc/netdata
|
||||||
|
./edit-config health_alarm_notify.conf
|
||||||
|
```
|
||||||
|
|
||||||
|
Setze folgende Variablen:
|
||||||
|
|
||||||
|
```
|
||||||
|
SEND_EMAIL="YES"
|
||||||
|
DEFAULT_RECIPIENT_EMAIL="admin@deinedomain.tld"
|
||||||
|
```
|
||||||
|
|
||||||
|
Speichern, schließen und Netdata neu starten:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
systemctl restart netdata
|
||||||
|
```
|
||||||
|
|
||||||
|
👉 **Screenshot geeignet:** Terminal mit erfolgreichem `mail`-Test und sichtbarer Netdata-Mailkonfiguration
|
||||||
|
|
||||||
|
> [!TIP]
|
||||||
|
> Wenn du eine dedizierte Mailadresse für Systemmeldungen hast (z. B. `alerts@deinedomain.tld`),
|
||||||
|
> kannst du sie hier direkt als Absender konfigurieren.
|
||||||
|
> Mehrere Empfänger werden durch Kommata getrennt angegeben.
|
||||||
|
|
||||||
|
|
||||||
|
#### Discord-Benachrichtigung (empfohlen)
|
||||||
|
|
||||||
|
Discord eignet sich hervorragend für schnelle Systemmeldungen – ideal für kleine Teams oder Streamer-Umgebungen.
|
||||||
|
|
||||||
|
**1. Webhook im Discord-Server erstellen**
|
||||||
|
|
||||||
|
1. Öffne deinen Discord-Server.
|
||||||
|
2. Gehe zu **Servereinstellungen → Integrationen → Webhooks**.
|
||||||
|
3. Klicke auf **Neuer Webhook**.
|
||||||
|
- Name: `netdata-alerts`
|
||||||
|
- Kanal: `#alerts` (empfohlen: ein dedizierter Kanal nur für Systemmeldungen)
|
||||||
|
4. Klicke auf **Webhook kopieren**. Diese URL ist dein Zugangs-Token.
|
||||||
|
|
||||||
|
> [!IMPORTANT]
|
||||||
|
> Diese Webhook-URL ist vertraulich. Wer sie kennt, kann in deinen Kanal schreiben.
|
||||||
|
> Falls sie kompromittiert wurde, in Discord löschen und neu erstellen.
|
||||||
|
|
||||||
|
**2. Webhook in Netdata eintragen**
|
||||||
|
|
||||||
|
In der geöffneten Datei `health_alarm_notify.conf` folgende Variablen einfügen (Webhook-URL ersetzen):
|
||||||
|
|
||||||
|
```
|
||||||
|
SEND_DISCORD="YES"
|
||||||
|
DISCORD_WEBHOOK_URL="https://discord.com/api/webhooks/<DEINE_WEBHOOK_ID>/<DEIN_TOKEN>"
|
||||||
|
DEFAULT_RECIPIENT_DISCORD="alerts"
|
||||||
|
```
|
||||||
|
|
||||||
|
Optional kannst du pro Rolle eigene Zielkanäle definieren:
|
||||||
|
|
||||||
|
```
|
||||||
|
role_recipients_discord[sysadmin]="alerts"
|
||||||
|
role_recipients_discord[editor]="operations"
|
||||||
|
```
|
||||||
|
|
||||||
|
Datei speichern und Netdata neu starten:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
systemctl restart netdata
|
||||||
|
```
|
||||||
|
|
||||||
|
**3. Benachrichtigung testen**
|
||||||
|
|
||||||
|
Führe einen Testlauf aus, um zu prüfen, ob der Versand funktioniert:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
sudo su -s /bin/bash netdata
|
||||||
|
export NETDATA_ALARM_NOTIFY_DEBUG=1
|
||||||
|
/usr/libexec/netdata/plugins.d/alarm-notify.sh test
|
||||||
|
```
|
||||||
|
|
||||||
|
Wenn alles korrekt eingerichtet ist, erscheint eine Testmeldung im ausgewählten Discord-Kanal.
|
||||||
|
|
||||||
|
👉 **Screenshot geeignet:** Discord-Kanal `#alerts` mit Testnachricht „Netdata Notification – This is a test“
|
||||||
|
|
||||||
|
> [!TIP]
|
||||||
|
> Kommt keine Nachricht an? Prüfe:
|
||||||
|
> - **Webhook-URL** auf Zeilenumbrüche oder Tippfehler
|
||||||
|
> - **Kanalname** ohne `#` in `DEFAULT_RECIPIENT_DISCORD`
|
||||||
|
> - Logausgabe:
|
||||||
|
> ```bash
|
||||||
|
> tail -n 50 /var/log/netdata/error.log
|
||||||
|
> ```
|
||||||
|
|
||||||
|
### Alarmkategorien und Schwellenwerte anpassen
|
||||||
|
|
||||||
|
Die bestehenden Regeln kannst du jederzeit direkt im Dashboard verändern:
|
||||||
|
|
||||||
|
1. **Health → Alarms** öffnen
|
||||||
|
2. Alarm auswählen (z. B. CPU, Disk, Memory)
|
||||||
|
3. Auf **Edit** klicken
|
||||||
|
4. Warn- und Kritisch-Werte anpassen
|
||||||
|
5. Änderungen speichern
|
||||||
|
|
||||||
|
👉 **Screenshot geeignet:** Edit-Fenster eines Alarms mit angepassten Schwellenwerten
|
||||||
|
|
||||||
|
Damit du ein Gefühl bekommst, welche Werte sich bewährt haben, findest du hier eine Übersicht typischer Empfehlungen
|
||||||
|
für kleine bis mittlere Homelab-Umgebungen (1–4 vCPUs, 2–8 GB RAM):
|
||||||
|
|
||||||
|
| Kategorie | Warnwert | Kritisch | Empfehlung / Hinweis |
|
||||||
|
|------------|-----------|----------|------------------------|
|
||||||
|
| **CPU-Auslastung** | > 80 % | > 95 % | Dauerhaft hohe Last deutet auf zu wenig Kerne oder hängende Prozesse hin. |
|
||||||
|
| **RAM-Auslastung** | > 75 % | > 90 % | Werte oberhalb von 90 % führen oft zu Swap-Nutzung und deutlichen Verzögerungen. |
|
||||||
|
| **Swap-Nutzung** | > 10 % | > 25 % | Swap sollte in LXC-Containern nur kurzzeitig genutzt werden. |
|
||||||
|
| **Root-Filesystem** | > 85 % | > 95 % | Frühzeitig Speicher erweitern, um Datenbankfehler zu vermeiden. |
|
||||||
|
| **Netzwerklatenz (Ping)** | > 50 ms | > 100 ms | Relevant bei externen APIs oder Streaming-Servern. |
|
||||||
|
| **Load Average (1 min)** | > 1 × CPU-Kerne | > 2 × CPU-Kerne | Dauerhaft hohe Load-Werte weisen auf Engpässe oder Hintergrundjobs hin. |
|
||||||
|
| **Prozessanzahl** | > 300 | > 500 | Nur als Trendindikator – wichtig bei Hosts mit vielen Containern. |
|
||||||
|
| **Temperatur (falls Sensoren aktiv)** | > 70 °C | > 85 °C | Besonders bei älteren CPU-Hosts relevant. |
|
||||||
|
|
||||||
|
> [!TIP]
|
||||||
|
> Passe die Schwellen so an, dass du bei erwartbarer Last keine Fehlalarme bekommst,
|
||||||
|
> aber ungewöhnliche Zustände früh genug erkennst.
|
||||||
|
> Teste jeden Alarm einmal manuell, um sicherzustellen, dass Benachrichtigungen korrekt ausgelöst werden.
|
||||||
|
|
||||||
|
> [!NOTE]
|
||||||
|
> Diese Änderungen gelten sofort und betreffen nur die lokale Instanz.
|
||||||
|
> Sie überschreiben keine globalen Konfigurationsdateien.
|
||||||
|
|
||||||
|
👉 **Screenshot geeignet:** Edit-Fenster eines Alarms mit geänderten Schwellenwerten
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
|
||||||
Reference in New Issue
Block a user