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