# Monitoring Lab: Proaktive Überwachung mit Bordmitteln

TL;DR / Management Summary Große Systeme wie Zabbix oder Prometheus sind mächtig, aber für einen schnellen Check auf einem Standalone-Server oder eine spezifische Applikations-Metrik reicht oft ein Bash-Skript. In diesem Lab bauen wir einen Health-Monitor, der Schwellenwerte für Disk-Space und CPU-Load prüft und bei Überschreitung einen Alarm an einen Slack- oder Telegram-Channel sendet. Minimaler Aufwand, maximale Transparenz.

# 1. Das Konzept: Der Watchdog-Workflow

Immer einen Schritt voraus.

Unser Skript soll:

1. Check: Kritische Metriken abfragen (df, uptime, curl).
2. Threshold: Die Werte gegen ein Limit prüfen.
3. Alert: Nur bei Problemen eine Nachricht absetzen.

# 2. Das Skript: system_watchdog.sh

Leichtgewichtig und smart.

#!/bin/bash
# ---------------------------------------------------------------------------
# MINIMAL SYSTEM WATCHDOG
# ---------------------------------------------------------------------------

# --- 1. CONFIGURATION ---
readonly DISK_THRESHOLD=90
readonly LOAD_THRESHOLD=5.0
readonly WEB_URL="https://myapp.intern/health"
readonly SLACK_WEBHOOK="https://hooks.slack.com/services/Txxx/Bxxx/Xxxx"

# --- 2. ALERT FUNCTION ---
send_alert() {
    local message="[$(hostname)] ALERT: $*"
    echo "$message" >&2
    
    # Slack Webhook (curl nutzen)
    curl -X POST -H 'Content-type: application/json' \
         --data "{\"text\": \"${message}\"}" "$SLACK_WEBHOOK"
}

# --- 3. THE CHECKS ---

# A. Disk Usage Check
DISK_USAGE=$(df / | grep / | awk '{ print $5 }' | sed 's/%//g')
if [[ $DISK_USAGE -gt $DISK_THRESHOLD ]]; then
    send_alert "Root partition almost full (${DISK_USAGE}%)"
fi

# B. CPU Load Check
CURRENT_LOAD=$(uptime | awk -F'load average:' '{ print $2 }' | cut -d, -f1 | xargs)
# Bash kann keine Kommas in Vergleichen, daher 'bc' oder String-Vergleich
if (( $(echo "$CURRENT_LOAD > $LOAD_THRESHOLD" | bc -l) )); then
    send_alert "High CPU Load detected: ${CURRENT_LOAD}"
fi

# C. Web Service Check
HTTP_STATUS=$(curl -o /dev/null -s -w "%{http_code}" "$WEB_URL")
if [[ $HTTP_STATUS -ne 200 ]]; then
    send_alert "Web service $WEB_URL returned status $HTTP_STATUS"
fi

# 3. Day-2 Operations: Automatisierung und Intervalle

Den Wächter aktivieren.

Lassen Sie das Skript alle 5 Minuten laufen.

# via Cron

*/5 * * * * /usr/local/bin/system_watchdog.sh

# via Systemd (Empfohlen für Logging)

Erstellen Sie einen Timer (siehe Artikel 007), um den Monitor im System-Log sichtbar zu machen.

# 4. Troubleshooting & “War Stories”

Wenn der Alarm stummbeschaltet wird.

# Story 1: “Die Alert-Flut”

Symptom: Ein Server hat ein Problem, und der Admin bekommt 500 Telegram-Nachrichten in 10 Minuten. Das Handy vibriert ununterbrochen. Ursache: Das Monitoring-Skript läuft in einer engen Schleife ohne “Cooldown”. Lösung: Nutzen Sie eine Lock-Datei mit Zeitstempel. Senden Sie einen Alarm nur, wenn seit dem letzten Alarm mindestens 60 Minuten vergangen sind.

# Story 2: “Der falsche Alarm (Spikes)”

Symptom: Jede Nacht um 03:00 Uhr kommt ein Load-Alarm, obwohl das System gesund ist. Ursache: Das Backup-Skript (Artikel 295) startet und verursacht einen kurzzeitigen CPU-Peak von 10 Sekunden. Lösung: Prüfen Sie den 15-Minuten-Durchschnitt der Load (awk '{print $3}') statt den 1-Minute-Durchschnitt, um kurzfristige Lastspitzen zu ignorieren.

# 5. Fazit & Empfehlung

• Wahl: Nutzen Sie Bash-Monitoring für spezifische Business-Logik (z.B. “Ist die Datei X vorhanden und jünger als 1h?”), die Standard-Tools oft nicht kennen.
• Abhängigkeit: Installieren Sie das Paket bc (für Mathe-Vergleiche), da Bash nativ keine Fließkommazahlen beherrscht.
• Wartung: Testen Sie Ihre Webhooks regelmäßig mit einer Test-Nachricht.

# Anhang: Cheatsheet für Metriken