Homelab--Bratonein-Kontrollzentrum--Tutorial/Kapitel 15/Premium Rohtext.md

# 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.

---

## 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**.