← Zurueck zu Monitoring
🔄

Monitoring mit n8n

n8n als primaeres Monitoring-Tool: Checks, Alerts UND automatische Problemloesung in einem System.

⏱️ 45 Minuten 📊 Mittel
🤔 Schritt 1: Warum n8n fuer Monitoring? +

n8n geht ueber klassisches Monitoring hinaus: Erkennen, Alarmieren UND automatisch beheben - alles in einem Workflow.

🔍 Erkennen

  • • API-Abfragen
  • • SSH-Befehle
  • • Log-Analyse
  • • Metriken sammeln

🔔 Alarmieren

  • • Telegram, Slack, Discord
  • • E-Mail mit Details
  • • Nur bei Problemen
  • • Mit Loesungshinweisen

🔧 Auto-Fix

  • • Service neustarten
  • • Container rebooten
  • • Cache leeren
  • • Logs rotieren

Der Unterschied

Klassisches Monitoring sagt dir "es brennt". n8n loescht das Feuer automatisch - und informiert dich danach.
📋 Schritt 2: Grundprinzip: Check → Fix → Alert +

Der moderne Monitoring-Workflow geht einen Schritt weiter:

Schedule
🔍 Check
⚖️ Bedingung
🔧 Auto-Fix
🔔 Alert

Klassisch (nur Alert)

Problem erkannt → Alarm → Du wachst um 3 Uhr auf → Manueller Fix

Mit Auto-Fix

Problem erkannt → Automatisch behoben → Info-Mail am Morgen

🔒 Schritt 3: Beispiel 1: SSL-Zertifikat pruefen +

Warnung X Tage vor Ablauf des SSL-Zertifikats:

Workflow-Aufbau

  1. Schedule Trigger: Taeglich um 09:00
  2. HTTP Request: GET https://deine-domain.de (mit SSL-Info)
  3. Code Node: Berechne Tage bis Ablauf
  4. IF Node: Wenn weniger als 14 Tage
  5. Telegram/Email: Warnung senden
Code Node (JavaScript)
bash
// SSL-Ablaufdatum aus Response extrahieren
const sslExpiry = new Date($input.first().json.ssl.valid_to);
const today = new Date();
const daysLeft = Math.floor((sslExpiry - today) / (1000 * 60 * 60 * 24));

return [{
  json: {
    domain: "deine-domain.de",
    expiryDate: sslExpiry.toISOString(),
    daysLeft: daysLeft,
    isExpiringSoon: daysLeft < 14
  }
}];
💡

Alternative

Uptime Kuma kann das auch - aber n8n erlaubt mehr Flexibilitaet, z.B. mehrere Domains in einer Liste pruefen.
💾 Schritt 4: Beispiel 2: Backup-Verifizierung +

Pruefen ob das letzte Backup erfolgreich war:

Workflow-Aufbau

  1. Schedule Trigger: Taeglich um 07:00 (nach Backup)
  2. SSH Node: Verbinde zum Server
  3. Execute Command: Pruefe Backup-Datei
  4. IF Node: Datei vorhanden und aktuell?
  5. Telegram: Bei Fehler: Alert
SSH Befehl
bash
# Pruefe ob Backup von heute existiert und groesser als 1MB ist
BACKUP_FILE="/backup/daily-$(date +%Y-%m-%d).tar.gz"
if [ -f "$BACKUP_FILE" ] && [ $(stat -f%z "$BACKUP_FILE") -gt 1000000 ]; then
  echo "OK"
else
  echo "FAILED"
fi
⚠️

SSH-Zugang

Der n8n-Server braucht SSH-Zugang zum Backup-Server. Nutze SSH-Keys und beschraenke den User auf notwendige Befehle.
💽 Schritt 5: Beispiel 3: Festplatten-Fuellstand +

Warnung wenn Festplatte ueber 80% voll:

Workflow-Aufbau

  1. Schedule Trigger: Alle 6 Stunden
  2. SSH Node: Verbinde zum Server
  3. Execute Command: df -h / | tail -1 | awk '{print $5}'
  4. Code Node: Parse Prozentwert
  5. IF Node: Wenn ueber 80%
  6. Telegram: Warnung mit Details
Code Node (JavaScript)
bash
// Parse "85%" zu Zahl
const usageStr = $input.first().json.stdout.trim();
const usagePercent = parseInt(usageStr.replace('%', ''));

return [{
  json: {
    server: "production-server",
    diskUsage: usagePercent,
    isCritical: usagePercent > 80,
    isWarning: usagePercent > 70
  }
}];
🌐 Schritt 6: Beispiel 4: API Health Check +

Pruefe ob eine API korrekt antwortet:

Workflow-Aufbau

  1. Schedule Trigger: Alle 5 Minuten
  2. HTTP Request: GET /api/health
  3. IF Node: Status 200 UND Response enthält {'"status": "ok"'}
  4. Bei Fehler: Telegram Alert
  5. Optional: Retry-Logik mit Wait Node
HTTP Request Konfiguration
bash
Method: GET
URL: https://api.deine-domain.de/health
Headers:
  Authorization: Bearer {'{$credentials.apiToken}'}

Erweiterte Checks

Du kannst auch komplexere Pruefungen machen: Login testen, Datensatz anlegen/loeschen, Response-Zeit messen, etc.
🐳 Schritt 7: Beispiel 5: Docker Container Status +

Pruefe ob alle wichtigen Container laufen:

Workflow-Aufbau

  1. Schedule Trigger: Alle 10 Minuten
  2. SSH Node: Verbinde zum Docker-Host
  3. Execute Command: docker ps --format json
  4. Code Node: Parse und pruefe erwartete Container
  5. IF Node: Container fehlt oder unhealthy?
  6. Telegram: Alert mit Container-Details
Code Node (JavaScript)
bash
// Erwartete Container
const expected = ['nextcloud', 'nginx', 'postgres', 'redis'];

// Laufende Container aus docker ps
const running = $input.first().json.stdout
  .split('\n')
  .filter(line => line)
  .map(line => JSON.parse(line).Names);

// Fehlende finden
const missing = expected.filter(c => !running.includes(c));

return [{
  json: {
    runningContainers: running,
    missingContainers: missing,
    hasMissing: missing.length > 0
  }
}];
🔧 Schritt 8: Beispiel 6: Auto-Fix bei Speicherproblemen +

Automatisch reagieren wenn ein Container zu viel Speicher nutzt:

Workflow-Aufbau

  1. Schedule Trigger: Alle 5 Minuten
  2. SSH Node: Speichernutzung abfragen
  3. Code Node: Schwellwerte pruefen
  4. IF Node: Ueber 90%?
  5. SSH Node: Container automatisch neustarten
  6. Telegram: Info ueber durchgefuehrten Fix
Check + Auto-Fix (JavaScript)
bash
// Speichernutzung aus SSH-Output parsen
const memUsage = parseInt($input.first().json.stdout);
const threshold = 90;

if (memUsage > threshold) {
  return [{
    json: {
      action: 'restart',
      reason: 'Speicher bei ' + memUsage + '%',
      command: 'docker restart app-container',
      notify: true
    }
  }];
}

return [{ json: { action: 'none' } }];
SSH Auto-Fix Befehl
bash
# Container neustarten und Ergebnis pruefen
docker restart app-container && \
sleep 5 && \
docker ps --filter name=app-container --format "{{.Status}}"

Ergebnis

Der Container wird automatisch neugestartet. Du bekommst eine Nachricht: "Container neugestartet wegen Speicherueberlauf (92%). Status: Up 5 seconds."
🎯 Schritt 9: Beispiel 7: Intelligente Service-Erkennung +

Nur alerten wenn ein Service wirklich laeuft - gestoppte Services ignorieren:

Problem

Du stoppst einen Container bewusst (Wartung, Ressourcen sparen). Klassisches Monitoring schlaegt trotzdem Alarm.

Loesung: Status-Check vorschalten

  1. Zuerst pruefen: Laeuft der Container ueberhaupt?
  2. Wenn gestoppt → Kein Alert (bewusste Entscheidung)
  3. Wenn laeuft UND Problem → Alert
Intelligenter Check (Bash)
bash
# Nur pruefen wenn Container laeuft
if docker ps --format '{{.Names}}' | grep -q "^app-container$"; then
  # Container laeuft - jetzt Health pruefen
  docker exec app-container healthcheck.sh
else
  # Container gestoppt - kein Alert
  echo "CONTAINER_STOPPED"
fi
Auswertung (JavaScript)
bash
const output = $input.first().json.stdout.trim();

// Gestoppte Container nicht alerten
if (output === 'CONTAINER_STOPPED') {
  return [{ json: { status: 'stopped', alert: false } }];
}

// Container laeuft - Health-Status auswerten
const isHealthy = output.includes('OK');
return [{
  json: {
    status: isHealthy ? 'healthy' : 'unhealthy',
    alert: !isHealthy,
    message: output
  }
}];
💡

Vorteil

Keine False-Positives mehr bei geplanten Wartungsarbeiten. Du kannst Services stoppen ohne den Alert-Kanal zu fluten.
🔔 Schritt 10: Alert-Strategien +

So vermeidest du Alert-Muedigkeit:

Deduplizierung

Speichere den letzten Status (z.B. in einer Datenbank oder Variable). Sende nur bei Status-Aenderung einen Alert.

Eskalation

Erste Warnung per E-Mail, bei anhaltendem Problem nach 30 Min Telegram, nach 1 Stunde SMS/Anruf.

Zusammenfassung

Statt 10 einzelner Alerts: Ein Daily Digest mit allen Warnungen. Kritisches sofort, Rest gesammelt.

💡

n8n Vorteil

Diese komplexe Logik ist mit n8n einfach umsetzbar - mit klassischen Monitoring-Tools oft nicht moeglich.
💡 Schritt 11: Best Practices +

Tipps fuer robustes n8n Monitoring:

Do's

  • ✓ Error Handling in jeden Workflow einbauen
  • ✓ Timeouts fuer HTTP/SSH Requests setzen
  • ✓ Workflows mit sprechendem Namen versehen
  • ✓ Credentials sicher in n8n speichern
  • ✓ Logging fuer Fehleranalyse aktivieren

Don'ts

  • ✗ Passwörter direkt im Workflow speichern
  • ✗ Zu kurze Intervalle (Last auf Services)
  • ✗ Alerts ohne klare Handlungsanweisung
  • ✗ Komplexe Workflows ohne Dokumentation
⚠️

n8n selbst ueberwachen

Wenn n8n ausfaellt, fallen auch deine Monitoring-Workflows aus. Nutze Uptime Kuma um n8n zu ueberwachen!

Haeufige Fragen

Kann n8n Uptime Kuma ersetzen?
Fuer reine Uptime-Checks: Beide funktionieren. Der Unterschied: n8n kann auf Probleme reagieren - Services automatisch neustarten, Cache leeren, Logs rotieren. n8n fuer intelligentes Monitoring mit Auto-Fix, Uptime Kuma fuer Status-Seiten.
Wie speichere ich den letzten Status zwischen Runs?
Optionen: n8n Variables, externe Datenbank (Postgres, Redis), oder eine einfache JSON-Datei auf dem Server. Fuer einfache Faelle reicht auch eine Airtable/Notion Integration.
Wie oft sollten Workflows laufen?
Abhaengig vom Check: SSL-Ablauf reicht taeglich, API-Health alle 5 Minuten, Festplatte alle paar Stunden. Nicht zu oft - das erzeugt nur Last.
Kann ich Monitoring-Workflows teilen?
Ja! n8n Workflows koennen als JSON exportiert und geteilt werden. Es gibt auch eine Community-Bibliothek mit fertigen Workflows.
$ focus-music --play
Hacker Atmosphere 1 / 5
0:00 --:--