Monitoring-Skripte in Bash für Server und Container

1. Bash-Monitoring: Wann es ausreicht und wo die Grenzen liegen

Monitoring-Skripte in Bash sind für kleine bis mittlere Infrastrukturen die pragmatische Wahl: kein Prometheus-Stack, keine Grafana-Instanz, keine TSDB – nur ein Cron-Job, der alle fünf Minuten läuft und bei Problemen sofort alertet. Die Einstiegshürde ist minimal, und auf jedem Linux-Server sind alle benötigten Werkzeuge bereits vorhanden: df, free, top, curl, docker und mail oder curl für Webhook-Alerts. Bash-Monitoring-Skripte können spezifisch für die eigene Infrastruktur gebaut werden, ohne Daten in externe Systeme zu senden.

Die Grenzen von Bash-basiertem Monitoring liegen bei historischen Trends (kein Speichern von Zeitreihen), komplexen Alert-Routing-Regeln und großen Infrastrukturen mit hunderten Servern. Für diese Szenarien sind Prometheus mit Node Exporter oder Datadog besser geeignet. In der Praxis ergänzen Bash-Monitoring-Skripte professionelle Monitoring-Systeme: Sie laufen on-the-box für sofortige lokale Checks, während das externe System den übergeordneten Überblick liefert. Gerade für Docker-Container und Magento-Shops auf einzelnen oder wenigen Servern bieten Bash-basierte Monitoring-Skripte sofortige Erkennungsgeschwindigkeit ohne Setup-Aufwand.

2. CPU- und RAM-Auslastung in Bash überwachen

Das Bash-Monitoring-Skript für CPU-Auslastung liest die Werte aus /proc/stat oder nutzt top -bn1 für eine Momentaufnahme. Das Muster mit /proc/stat ist präziser: Es liest zwei aufeinanderfolgende Messungen mit einer kurzen Pause und berechnet die tatsächliche CPU-Auslastung im Messfenster. top -bn1 ist einfacher zu parsen, liefert aber die Durchschnittsauslastung seit dem letzten Reboot, nicht die aktuelle. Für Monitoring-Skripte, die alle 5 Minuten laufen, ist top -bn1 meist ausreichend und einfacher zu implementieren.

RAM-Überwachung in Bash-Monitoring-Skripten liest aus /proc/meminfo oder nutzt free -m. Das moderne Muster für RAM-Auslastung berücksichtigt den "available"-Wert aus /proc/meminfo statt des traditionellen "free"-Werts: Linux cached aggressiv, und ein System mit 95% RAM-Auslastung ist oft vollkommen gesund, solange "MemAvailable" hoch genug ist. Das Monitoring-Skript berechnet daher die tatsächlich verfügbare Menge als Prozentsatz des Gesamtspeichers und alertet, wenn dieser unter einen definierten Schwellenwert fällt – nicht wenn "used" einen Wert überschreitet.

#!/usr/bin/env bash
# resource-check.sh — CPU, RAM and disk monitoring with threshold alerts
set -euo pipefail

# Thresholds (in percent)
CPU_THRESHOLD="${CPU_THRESHOLD:-85}"
RAM_THRESHOLD="${RAM_THRESHOLD:-90}"
DISK_THRESHOLD="${DISK_THRESHOLD:-85}"
LOAD_THRESHOLD="${LOAD_THRESHOLD:-8.0}"

HOSTNAME_SHORT=$(hostname -s)
ALERT_TRIGGERED=false
ALERT_MSG=""

alert() {
  local level="$1" msg="$2"
  ALERT_MSG+="[${level}] ${msg}\n"
  ALERT_TRIGGERED=true
  echo "[${level}] ${msg}"
}

# CPU: 1-minute load average vs CPU count
CPU_COUNT=$(nproc)
LOAD_1MIN=$(awk '{print $1}' /proc/loadavg)
LOAD_PERCENT=$(awk "BEGIN {printf \"%.0f\", ($LOAD_1MIN / $CPU_COUNT) * 100}")

if (( LOAD_PERCENT > CPU_THRESHOLD )); then
  alert "CRITICAL" "CPU load: ${LOAD_1MIN} (${LOAD_PERCENT}%) on ${CPU_COUNT} cores — threshold: ${CPU_THRESHOLD}%"
fi

# RAM: use MemAvailable (not free) for accurate available memory
MEM_TOTAL=$(awk '/^MemTotal:/ {print $2}' /proc/meminfo)
MEM_AVAIL=$(awk '/^MemAvailable:/ {print $2}' /proc/meminfo)
MEM_USED_PCT=$(awk "BEGIN {printf \"%.0f\", (1 - $MEM_AVAIL/$MEM_TOTAL) * 100}")

if (( MEM_USED_PCT > RAM_THRESHOLD )); then
  MEM_AVAIL_MB=$(( MEM_AVAIL / 1024 ))
  alert "CRITICAL" "RAM usage: ${MEM_USED_PCT}% (only ${MEM_AVAIL_MB}MB available) — threshold: ${RAM_THRESHOLD}%"
fi

# Disk: check all mounted filesystems
while IFS= read -r line; do
  usage=$(echo "$line" | awk '{gsub(/%/,"",$5); print $5}')
  mount=$(echo "$line" | awk '{print $6}')
  if (( usage > DISK_THRESHOLD )); then
    alert "WARNING" "Disk ${mount}: ${usage}% used — threshold: ${DISK_THRESHOLD}%"
  fi
done < <(df -h | grep '^/dev/' | grep -v "tmpfs\|udev")

echo "CPU: ${LOAD_PERCENT}% | RAM: ${MEM_USED_PCT}% | Alerts: ${ALERT_TRIGGERED}"

3. Disk-Auslastung: Schwellenwerte und Inode-Checks

Disk-Monitoring in Bash-Skripten hat zwei Dimensionen: die Blockauslastung (wie viel Speicherplatz ist belegt) und die Inode-Auslastung (wie viele Datei-Einträge sind verbraucht). Ein Server kann 50% der Blockauslastung haben und trotzdem ausfallen, wenn die Inodes erschöpft sind – ein klassisches Problem in Magento-Umgebungen, wo var/cache/ oder var/session/ Millionen kleiner Dateien erzeugen. Das vollständige Disk-Monitoring-Skript prüft beide Dimensionen für jedes relevante Dateisystem.

Für den Inode-Check verwendet df -i statt df -h. Das Monitoring-Muster ist identisch: Auslastung in Prozent berechnen, mit Schwellenwert vergleichen, bei Überschreitung Alert auslösen. In Produktionsumgebungen empfiehlt sich ein gestuftes Alert-System: WARNING bei 75%, CRITICAL bei 90%. Das gibt Zeit zum Handeln, bevor der Server bei 100% ausfällt. Die häufigste Ursache für volle Inodes in Magento: var/session/-Verzeichnis mit alten Sessions – ein Bash-Monitoring-Skript, das täglich die Session-Anzahl meldet, ermöglicht proaktives Cleanup.

4. HTTP-Health-Checks mit curl

HTTP-Health-Checks sind eine der wertvollsten Funktionen von Bash-Monitoring-Skripten: Sie testen nicht nur, ob der Server läuft, sondern ob die Anwendung korrekt antwortet. Das Basismuster mit curl: HTTP-Status-Code prüfen, Response-Zeit messen, optional auf bestimmten Content prüfen. curl -s -o /dev/null -w "%{http_code}:%{time_total}" URL gibt Status-Code und Gesamtzeit in einem Aufruf zurück, ohne den Body zu speichern. Ein Magento-Shop-Health-Check prüft mindestens: Homepage (200), Checkout (keine Weiterleitung zu 503), Admin-Login-Seite (200) und einen API-Endpoint.

Das erweiterte HTTP-Monitoring-Skript prüft nicht nur den Status-Code, sondern auch den Response-Inhalt: Wenn Magento im Maintenance-Mode ist, gibt es HTTP 503 zurück, wenn Varnish eine Fehlerseite cached, gibt es HTTP 200 zurück, aber der Body enthält keinen Shop-Content. Das Muster curl -s URL | grep -q "erwarteter-content" gibt Exit-Code 0 bei vorhandenem Content und 1 bei fehlendem Content. Kombiniert mit Response-Zeit-Messung erkennt dieses Bash-Monitoring-Muster sowohl Ausfälle als auch Performance-Degradation.

#!/usr/bin/env bash
# http-health-check.sh — HTTP endpoint monitoring with timing and content checks
set -euo pipefail

TIMEOUT="${TIMEOUT:-10}"
SLOW_THRESHOLD="${SLOW_THRESHOLD:-3.0}"  # seconds
ALERT_LOG="${ALERT_LOG:-/var/log/monitoring/http-alerts.log}"

mkdir -p "$(dirname "$ALERT_LOG")"

# Define endpoints to check
declare -A ENDPOINTS=(
  ["homepage"]="https://mironsoft.de/"
  ["shop"]="https://mironsoft.de/shop"
  ["checkout"]="https://mironsoft.de/checkout/cart"
  ["health"]="https://mironsoft.de/health_check"
)

# Optional content checks (empty = skip content check)
declare -A CONTENT_CHECK=(
  ["homepage"]="mironsoft"
  ["health"]="OK"
)

check_endpoint() {
  local name="$1" url="$2"
  local response http_code time_total

  response=$(curl -sS \
    --max-time "$TIMEOUT" \
    --write-out "\n%{http_code}:%{time_total}" \
    --output /tmp/http_check_body_$$ \
    "$url" 2>/dev/null) || {
    echo "[CRITICAL] $name: Connection failed (timeout or DNS error)" | tee -a "$ALERT_LOG"
    return 1
  }

  http_code=$(tail -1 /tmp/http_check_body_$$ 2>/dev/null | cut -d: -f1 || echo "000")
  time_total=$(tail -1 /tmp/http_check_body_$$ 2>/dev/null | cut -d: -f2 || echo "0")

  # Re-run properly: output goes to tempfile, stats to last line
  http_code=$(curl -sS --max-time "$TIMEOUT" \
    -o /tmp/http_body_$$ \
    -w "%{http_code}" "$url" 2>/dev/null || echo "000")
  time_total=$(curl -sS --max-time "$TIMEOUT" \
    -o /dev/null \
    -w "%{time_total}" "$url" 2>/dev/null || echo "0")

  # Status code check
  if [[ "$http_code" != "200" ]]; then
    echo "[CRITICAL] $name: HTTP $http_code at $url" | tee -a "$ALERT_LOG"
    rm -f /tmp/http_body_$$
    return 1
  fi

  # Response time check
  if awk "BEGIN {exit !($time_total > $SLOW_THRESHOLD)}"; then
    echo "[WARNING] $name: Slow response ${time_total}s (threshold: ${SLOW_THRESHOLD}s)" \
      | tee -a "$ALERT_LOG"
  fi

  # Content check (if defined)
  if [[ -n "${CONTENT_CHECK[$name]:-}" ]]; then
    if ! grep -qi "${CONTENT_CHECK[$name]}" /tmp/http_body_$$ 2>/dev/null; then
      echo "[CRITICAL] $name: Expected content '${CONTENT_CHECK[$name]}' not found" \
        | tee -a "$ALERT_LOG"
      rm -f /tmp/http_body_$$
      return 1
    fi
  fi

  echo "[OK] $name: HTTP $http_code in ${time_total}s"
  rm -f /tmp/http_body_$$
}

for name in "${!ENDPOINTS[@]}"; do
  check_endpoint "$name" "${ENDPOINTS[$name]}" || true
done

5. Docker-Container-Status und -Health überwachen

Docker-Monitoring in Bash prüft drei Aspekte: Läuft der Container überhaupt? Ist der Health-Check des Containers grün? Und liegen Ressourcen (CPU/RAM) innerhalb der erwarteten Grenzen? Für den ersten Check reicht docker inspect --format '{ {.State.Running} }' container-name. Der zweite Check liest den Health-Status: docker inspect --format '{ {.State.Health.Status} }' container-name gibt healthy, unhealthy, starting oder leer zurück. Das Bash-Monitoring-Skript prüft alle drei Zustände und alertet, wenn ein Container nicht läuft oder als unhealthy markiert ist.

Für das Ressourcen-Monitoring von Docker-Containern liefert docker stats --no-stream --format "table { {.Container} }\t{ {.CPUPerc} }\t{ {.MemUsage} }" eine Momentaufnahme aller laufenden Container. Das Bash-Monitoring-Muster parst diese Ausgabe, extrahiert die Prozentwerte und vergleicht sie mit definierten Schwellenwerten. Für Magento-Docker-Umgebungen (Mark Shust Setup) sind die relevanten Container: PHP-FPM, Nginx, MySQL, Redis und Elasticsearch. Ein Monitoring-Skript, das alle fünf Container prüft und bei Ausfall oder Health-Fehler sofort alertet, ist in unter 50 Zeilen implementiert.

6. Alerting: E-Mail, Webhook und Slack-Integration

Das Alerting in Bash-Monitoring-Skripten hat drei typische Kanäle: E-Mail via mail oder sendmail, HTTP-Webhooks für Slack/Teams/Discord und direkte API-Aufrufe für Monitoring-Plattformen. Das einfachste Muster: echo "Alert-Text" | mail -s "Subject" admin@example.com setzt voraus, dass ein MTA (Postfix, ssmtp, msmtp) auf dem Server konfiguriert ist. Für die meisten Produktionsserver ist das gegeben – der Alert landet sofort in der E-Mail und dem Monitoring-Postfach.

Webhook-basiertes Alerting mit curl ist für Teams-Chats, Slack oder eigene Alert-Endpoints flexibler. Das Bash-Monitoring-Muster baut das JSON-Payload mit Here-Document oder printf und sendet es per curl -X POST -H "Content-Type: application/json" -d "..." WEBHOOK_URL. Für Slack gibt es das einfache Incoming-Webhook-Format, für Teams das Adaptive-Card-Format. Beide können direkt aus einem Bash-Monitoring-Skript ohne externe Libraries gesendet werden. Das Muster hält das JSON-Building einfach: Sonderzeichen im Alert-Text müssen durch jq -r @json escaped werden, um valides JSON zu erzeugen.

#!/usr/bin/env bash
# alerting.sh — Multi-channel alerting for Bash monitoring scripts
set -euo pipefail

# Configuration (set via environment or .env file)
ALERT_EMAIL="${ALERT_EMAIL:-ops@example.com}"
SLACK_WEBHOOK="${SLACK_WEBHOOK:-}"
PAGERDUTY_KEY="${PAGERDUTY_KEY:-}"
HOSTNAME_SHORT=$(hostname -s)

# Alert state directory for deduplication
STATE_DIR="${STATE_DIR:-/var/lib/monitoring}"
mkdir -p "$STATE_DIR"

send_email_alert() {
  local subject="$1" body="$2"
  [[ -z "$ALERT_EMAIL" ]] && return 0

  {
    echo "Subject: [ALERT] ${HOSTNAME_SHORT}: ${subject}"
    echo "From: monitoring@${HOSTNAME_SHORT}"
    echo ""
    echo "$body"
    echo ""
    echo "--- Server: ${HOSTNAME_SHORT} | $(date '+%Y-%m-%d %H:%M:%S') ---"
  } | sendmail "$ALERT_EMAIL" 2>/dev/null || \
    echo "$body" | mail -s "[ALERT] ${subject}" "$ALERT_EMAIL" 2>/dev/null || \
    echo "[WARN] Could not send email alert" >&2
}

send_slack_alert() {
  local message="$1" level="${2:-warning}"
  [[ -z "$SLACK_WEBHOOK" ]] && return 0

  local color
  case "$level" in
    critical) color="#FF0000" ;;
    warning)  color="#FFA500" ;;
    ok)       color="#36A64F" ;;
    *)        color="#808080" ;;
  esac

  local escaped_msg
  escaped_msg=$(printf '%s' "$message" | jq -Rs .)

  curl -sS -X POST \
    -H "Content-Type: application/json" \
    -d "{
      \"attachments\": [{
        \"color\": \"${color}\",
        \"title\": \"Monitoring Alert — ${HOSTNAME_SHORT}\",
        \"text\": ${escaped_msg},
        \"footer\": \"$(date '+%Y-%m-%d %H:%M:%S')\"
      }]
    }" \
    "$SLACK_WEBHOOK" > /dev/null 2>&1 || echo "[WARN] Slack webhook failed" >&2
}

# Unified alert function
send_alert() {
  local level="$1" check_name="$2" message="$3"
  local full_msg="${level}: ${check_name} — ${message}"

  echo "[$(date '+%Y-%m-%d %H:%M:%S')] ${full_msg}"
  send_email_alert "${check_name}: ${level}" "$full_msg"
  send_slack_alert "$full_msg" "$(echo "$level" | tr '[:upper:]' '[:lower:]')"
}

# Example usage:
# send_alert "CRITICAL" "Disk /var" "95% used on ${HOSTNAME_SHORT}"
# send_alert "WARNING" "CPU Load" "Load: 12.5 on 4 cores"

7. Alert-Deduplication: kein Alert-Sturm bei dauerhaften Problemen

Das größte Problem naiver Bash-Monitoring-Skripte ist der Alert-Sturm: Wenn ein Problem dauerhaft besteht (z. B. Disk bei 95%) und das Monitoring alle 5 Minuten läuft, erhält das Operations-Team 288 E-Mails pro Tag für dasselbe Problem. Alert-Deduplication ist daher ein unverzichtbares Muster in jedem produktionstauglichen Bash-Monitoring-Skript. Die einfachste Implementierung nutzt State-Files: Eine Datei pro Check speichert, ob der letzte Lauf einen Alert ausgelöst hat. Ein Alert wird nur gesendet, wenn sich der Status geändert hat (neu: Problem aufgetreten, oder: Problem behoben).

Das State-File-Muster: Vor dem Check prüfen, ob eine Alert-State-Datei für diesen Check existiert. Wenn das Problem auftritt und keine State-Datei existiert: Alert senden, State-Datei erstellen. Wenn das Problem beim nächsten Lauf noch besteht und die State-Datei existiert: kein Alert (bereits gesendet). Wenn das Problem behoben ist und die State-Datei existiert: Recovery-Alert senden, State-Datei löschen. Dieses Muster reduziert den Alert-Sturm auf zwei Nachrichten pro Incident – einen Trigger-Alert und einen Recovery-Alert. Eine optionale Wiederholungslogik sendet einen Reminder alle N Stunden, falls das Problem ungelöst bleibt.

8. Einfaches Monitoring-Dashboard im Terminal

Ein interaktives Bash-Monitoring-Dashboard mit watch oder einer eigenen Refresh-Schleife zeigt alle wichtigen Metriken in einer übersichtlichen Terminal-Ansicht. Das Muster watch -n 5 ./server-status.sh aktualisiert die Ausgabe alle 5 Sekunden und gibt dem Operations-Team einen Echtzeit-Überblick ohne externe Tools. Das Dashboard-Skript kombiniert alle Checks: CPU-Load, RAM-Auslastung, Disk-Nutzung, HTTP-Status aller Endpunkte und Docker-Container-Status in einer strukturierten Ausgabe mit farbigen Statusanzeigen via ANSI-Escape-Codes.

Für Produktionsumgebungen ohne interaktives Terminal ist das Dashboard-Skript als täglicher Status-Report nützlich: einmal am Morgen ausgeführt und per E-Mail verschickt. Das Bash-Monitoring-Muster erzeugt eine strukturierte Textausgabe mit allen Checks, Status-Symbolen und Trends (Vergleich mit dem gestrigen Stand aus State-Files). Dieser Morgen-Report ersetzt das manuelle Prüfen der wichtigsten Metriken und gibt einen schnellen Überblick über die Gesundheit der gesamten Infrastruktur.

9. Monitoring-Methoden im Vergleich

Für kleine bis mittlere Infrastrukturen gibt es mehrere Monitoring-Ansätze von minimaler Bash-Implementierung bis zu vollständigen Monitoring-Stacks. Die Wahl hängt von Komplexität, historischen Daten und Team-Kapazitäten ab.

Für Magento-Produktionsumgebungen auf einzelnen oder wenigen Servern ist die Kombination aus Bash-Monitoring-Skripten und einem externen HTTP-Monitoring-Dienst (UptimeRobot) optimal: Die Bash-Skripte überwachen lokale Ressourcen und Anwendungszustand, der externe Dienst prüft HTTP-Erreichbarkeit von außen und erkennt Probleme auch dann, wenn der Server selbst den Alert nicht mehr senden kann. Diese Kombination deckt die wichtigsten Fehlerszenarien ab, ohne einen vollständigen Monitoring-Stack aufzubauen.

10. Zusammenfassung

Bash-Monitoring-Skripte für Server und Container bieten sofortige, konfigurierbare Überwachung ohne Abhängigkeiten von externen Systemen. Die drei Kernbereiche – Ressourcen-Monitoring (CPU/RAM/Disk mit richtiger MemAvailable-Berechnung), HTTP-Health-Checks (Status-Code, Response-Zeit, Content-Prüfung) und Docker-Container-Status (Running, Health, Ressourcen) – decken die wichtigsten Ausfall-Szenarien ab. Alert-Deduplication über State-Files verhindert Alert-Stürme und reduziert jedes Incident auf zwei Nachrichten: Trigger und Recovery.

Das vollständige Bash-Monitoring-Setup besteht aus einem Ressourcen-Check-Skript, einem HTTP-Health-Check-Skript, einem Docker-Monitor-Skript und einem gemeinsamen Alerting-Modul mit E-Mail- und Webhook-Support. Alle vier Skripte laufen als Cron-Jobs alle 5 Minuten und teilen dasselbe State-Verzeichnis für Deduplication. Ergänzt durch einen externen HTTP-Monitoring-Dienst für Outside-In-Checks entsteht ein vollständiges, robustes Monitoring für Magento-Produktionsumgebungen auf einem oder wenigen Servern – in Betrieb innerhalb von 30 Minuten.

11. FAQ: Monitoring-Skripte in Bash für Server und Container