Monitoring mit n8n
n8n als primaeres Monitoring-Tool: Checks, Alerts UND automatische Problemloesung in einem System.
🤔 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
📋 Schritt 2: Grundprinzip: Check → Fix → Alert
Der moderne Monitoring-Workflow geht einen Schritt weiter:
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
- Schedule Trigger: Taeglich um 09:00
- HTTP Request: GET https://deine-domain.de (mit SSL-Info)
- Code Node: Berechne Tage bis Ablauf
- IF Node: Wenn weniger als 14 Tage
- Telegram/Email: Warnung senden
// 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
💾 Schritt 4: Beispiel 2: Backup-Verifizierung
Pruefen ob das letzte Backup erfolgreich war:
Workflow-Aufbau
- Schedule Trigger: Taeglich um 07:00 (nach Backup)
- SSH Node: Verbinde zum Server
- Execute Command: Pruefe Backup-Datei
- IF Node: Datei vorhanden und aktuell?
- Telegram: Bei Fehler: Alert
# 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
💽 Schritt 5: Beispiel 3: Festplatten-Fuellstand
Warnung wenn Festplatte ueber 80% voll:
Workflow-Aufbau
- Schedule Trigger: Alle 6 Stunden
- SSH Node: Verbinde zum Server
- Execute Command:
df -h / | tail -1 | awk '{print $5}' - Code Node: Parse Prozentwert
- IF Node: Wenn ueber 80%
- Telegram: Warnung mit Details
// 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
- Schedule Trigger: Alle 5 Minuten
- HTTP Request: GET /api/health
- IF Node: Status 200 UND Response enthält {'"status": "ok"'}
- Bei Fehler: Telegram Alert
- Optional: Retry-Logik mit Wait Node
Method: GET
URL: https://api.deine-domain.de/health
Headers:
Authorization: Bearer {'{$credentials.apiToken}'} Erweiterte Checks
🐳 Schritt 7: Beispiel 5: Docker Container Status
Pruefe ob alle wichtigen Container laufen:
Workflow-Aufbau
- Schedule Trigger: Alle 10 Minuten
- SSH Node: Verbinde zum Docker-Host
- Execute Command: docker ps --format json
- Code Node: Parse und pruefe erwartete Container
- IF Node: Container fehlt oder unhealthy?
- Telegram: Alert mit Container-Details
// 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
- Schedule Trigger: Alle 5 Minuten
- SSH Node: Speichernutzung abfragen
- Code Node: Schwellwerte pruefen
- IF Node: Ueber 90%?
- SSH Node: Container automatisch neustarten
- Telegram: Info ueber durchgefuehrten Fix
// 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' } }]; # Container neustarten und Ergebnis pruefen
docker restart app-container && \
sleep 5 && \
docker ps --filter name=app-container --format "{{.Status}}" Ergebnis
🎯 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
- Zuerst pruefen: Laeuft der Container ueberhaupt?
- Wenn gestoppt → Kein Alert (bewusste Entscheidung)
- Wenn laeuft UND Problem → Alert
# 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 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
🔔 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
💡 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