From d336e135258b21ea94642c670651dd46c3bab7ee Mon Sep 17 00:00:00 2001 From: Thomas Dannenberg Date: Sat, 18 Oct 2025 13:51:15 +0000 Subject: [PATCH] =?UTF-8?q?Kapitel=2015/Premium=20Rohtext.md=20hinzugef?= =?UTF-8?q?=C3=BCgt?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Kapitel 15/Premium Rohtext.md | 350 ++++++++++++++++++++++++++++++++++ 1 file changed, 350 insertions(+) create mode 100644 Kapitel 15/Premium Rohtext.md diff --git a/Kapitel 15/Premium Rohtext.md b/Kapitel 15/Premium Rohtext.md new file mode 100644 index 0000000..9219d98 --- /dev/null +++ b/Kapitel 15/Premium Rohtext.md @@ -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 --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//" +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. + +