11 – Notfallhandbuch

Revisionshistorie

Inhaltsverzeichnis

1. Notfall-Definitionen und Severity-Level
2. Eskalationsmatrix
3. Disaster Recovery Szenarien
4. Backup und Restore Verfahren
5. Wiederanlauf-Prozedur nach Notfall
6. Kommunikationsplan
7. Post-Incident Review Template

1. Notfall-Definitionen und Severity-Level

Die folgenden Severity-Level definieren die Dringlichkeit und den Eskalationspfad bei Betriebsstoerungen der Cribl-Infrastruktur innerhalb des IceDataEmphasise-PoC.

2. Eskalationsmatrix

RACI-Matrix fuer Notfallbehandlung

R = Responsible, A = Accountable, C = Consulted, I = Informed

3. Disaster Recovery Szenarien

3.1 Szenario: Cribl Stream Ausfall

Stufe 1 – Restart:

# Cribl Stream Service neustarten
sudo systemctl restart cribl

# Status pruefen
sudo systemctl status cribl
curl -s http://localhost:9000/api/v1/health | jq .

# Logs auf Fehler pruefen
sudo journalctl -u cribl --since "10 minutes ago" --no-pager | tail -50

Stufe 2 – Failover (falls Restart fehlschlaegt):

# Worker-Prozesse pruefen und ggf. beenden
ps aux | grep cribl
sudo kill -9 $(pgrep -f "cribl server")

# Cribl Home bereinigen und neustarten
sudo rm -f /opt/cribl/data/cribl.pid
sudo systemctl start cribl

# Port-Belegung pruefen
sudo ss -tlnp | grep 9000

Stufe 3 – Neuinstallation:

# Konfiguration sichern (falls noch moeglich)
sudo cp -r /opt/cribl/local /tmp/cribl-backup-local
sudo cp -r /opt/cribl/data /tmp/cribl-backup-data

# Neuinstallation ausfuehren
sudo ./scripts/02-install-cribl-stream.sh

# Konfiguration wiederherstellen
sudo cp -r /tmp/cribl-backup-local/* /opt/cribl/local/
sudo chown -R cribl:cribl /opt/cribl

# Service starten und verifizieren
sudo systemctl start cribl
sudo ./scripts/07-verify-deployment.sh

3.2 Szenario: Cribl Edge Ausfall

Sofortmassnahmen:

# Edge Service neustarten
sudo systemctl restart cribl-edge

# Status pruefen
sudo systemctl status cribl-edge

# Falls der Service nicht startet: Logs pruefen
sudo journalctl -u cribl-edge --since "10 minutes ago" --no-pager

Edge neu deployen:

# Edge neu installieren
sudo ./scripts/03-install-cribl-edge-linux.sh

# Registrierung bei Stream Leader pruefen
curl -s http://localhost:9000/api/v1/master/groups | jq '.items[] | .id'

# Verifizierung
sudo ./scripts/07-verify-deployment.sh

3.3 Szenario: Splunk nicht erreichbar

Diagnose:

# Splunk HEC erreichbar?
curl -sk https://10.10.0.66:8088/services/collector/health

# Splunk S2S Port erreichbar?
nc -zv 10.10.0.66 9997

# Netzwerk-Konnektivitaet pruefen
ping -c 3 10.10.0.66
traceroute 10.10.0.66

# Persistent Queue Status pruefen
ls -lh /opt/cribl/state/queues/
du -sh /opt/cribl/state/queues/*

Massnahmen bei voller Queue:

1. Disk-Kapazitaet fuer Queue-Erweiterung pruefen: df -h /opt/cribl
2. Queue-Limit temporaer erhoehen (Cribl UI → Destinations → Queue Settings)
3. Backpressure aktivieren: Source-Rate drosseln, um Queue-Ueberlauf zu verhindern
4. Alternative Destination konfigurieren (z.B. lokales Dateisystem als Fallback)
5. Nach Splunk-Wiederherstellung: Queue-Drain ueberwachen

3.4 Szenario: NUC Hardware-Ausfall

Wiederherstellungsschritte auf neuem Host:

1. Neuen NUC oder Ersatzserver bereitstellen (Mindestanforderungen: 4 CPU, 8 GB RAM, 100 GB SSD)
2. Betriebssystem installieren (Ubuntu 22.04 LTS empfohlen)
3. Repository klonen:

   git clone <repository-url> /opt/IceDataEmphasise
   cd /opt/IceDataEmphasise

4. Backup wiederherstellen (siehe Abschnitt 4)
5. Installationsskripte ausfuehren:

   sudo ./scripts/00-preflight-check.sh
   sudo ./scripts/01-install-tailscale.sh
   sudo ./scripts/02-install-cribl-stream.sh
   sudo ./scripts/03-install-cribl-edge-linux.sh
   sudo ./scripts/04-configure-sources.sh

6. Konfiguration aus Backup uebernehmen
7. Deployment verifizieren: sudo ./scripts/07-verify-deployment.sh

4. Backup und Restore Verfahren

4.1 Backup-Strategie

4.2 Backup erstellen (Schritt-fuer-Schritt)

#!/usr/bin/env bash
# Backup-Skript fuer IceDataEmphasise Cribl-Konfiguration

BACKUP_DIR="/backup/cribl/$(date +%Y%m%d_%H%M%S)"
mkdir -p "${BACKUP_DIR}"

# 1. Cribl Stream Konfiguration sichern
echo "Sichere Cribl Stream Konfiguration..."
sudo tar czf "${BACKUP_DIR}/cribl-stream-local.tar.gz" -C /opt/cribl local/

# 2. Cribl Edge Konfiguration sichern
echo "Sichere Cribl Edge Konfiguration..."
sudo tar czf "${BACKUP_DIR}/cribl-edge-local.tar.gz" -C /opt/cribl-edge local/

# 3. Cribl Stream State (ohne Queue-Daten)
echo "Sichere Cribl Stream State..."
sudo tar czf "${BACKUP_DIR}/cribl-stream-state.tar.gz" \
    --exclude='queues' -C /opt/cribl state/

# 4. Projekt-Konfigurationsdateien
echo "Sichere Projekt-Konfiguration..."
tar czf "${BACKUP_DIR}/project-configs.tar.gz" -C /opt/IceDataEmphasise \
    configs/ .env scripts/

# 5. Pruefsumme erstellen
cd "${BACKUP_DIR}" && sha256sum *.tar.gz > checksums.sha256

echo "Backup abgeschlossen: ${BACKUP_DIR}"
ls -lh "${BACKUP_DIR}"

4.3 Restore durchfuehren (Schritt-fuer-Schritt)

#!/usr/bin/env bash
# Restore-Skript fuer IceDataEmphasise Cribl-Konfiguration

BACKUP_DIR="$1"  # Pfad zum Backup-Verzeichnis als Parameter

if [[ -z "${BACKUP_DIR}" || ! -d "${BACKUP_DIR}" ]]; then
    echo "Verwendung: $0 /backup/cribl/20260210_120000"
    exit 1
fi

# 1. Pruefsummen verifizieren
echo "Verifiziere Backup-Integritaet..."
cd "${BACKUP_DIR}" && sha256sum -c checksums.sha256 || {
    echo "FEHLER: Pruefsummen stimmen nicht ueberein! Abbruch."
    exit 1
}

# 2. Services stoppen
echo "Stoppe Cribl Services..."
sudo systemctl stop cribl
sudo systemctl stop cribl-edge

# 3. Aktuelle Konfiguration sichern (Rollback-Moeglichkeit)
echo "Sichere aktuelle Konfiguration als Rollback..."
sudo cp -r /opt/cribl/local /opt/cribl/local.pre-restore
sudo cp -r /opt/cribl-edge/local /opt/cribl-edge/local.pre-restore

# 4. Cribl Stream Konfiguration wiederherstellen
echo "Stelle Cribl Stream Konfiguration wieder her..."
sudo tar xzf "${BACKUP_DIR}/cribl-stream-local.tar.gz" -C /opt/cribl/
sudo chown -R cribl:cribl /opt/cribl/local

# 5. Cribl Edge Konfiguration wiederherstellen
echo "Stelle Cribl Edge Konfiguration wieder her..."
sudo tar xzf "${BACKUP_DIR}/cribl-edge-local.tar.gz" -C /opt/cribl-edge/
sudo chown -R cribl:cribl /opt/cribl-edge/local

# 6. Services starten
echo "Starte Cribl Services..."
sudo systemctl start cribl
sleep 5
sudo systemctl start cribl-edge
sleep 3

# 7. Verifizierung
echo "Verifiziere Wiederherstellung..."
sudo ./scripts/07-verify-deployment.sh

echo "Restore abgeschlossen."

5. Wiederanlauf-Prozedur nach Notfall

Die folgende Prozedur beschreibt den geordneten Wiederanlauf nach einem Notfall:

5.1 Checkliste Wiederanlauf

1. Ursache behoben: Sicherstellen, dass die Grundursache des Ausfalls behoben ist
2. Hardware/Infrastruktur:
   • NUC/Host-System laeuft und ist erreichbar
   • Netzwerkverbindung (Tailscale) steht
   • Ausreichend Festplattenspeicher vorhanden (≥ 2 GB frei)
3. Cribl Stream starten:

   sudo systemctl start cribl
   sleep 10
   curl -s http://localhost:9000/api/v1/health | jq .

4. Cribl Edge starten:

   sudo systemctl start cribl-edge
   sleep 5
   sudo systemctl status cribl-edge

5. Destinations pruefen:
   • Splunk HEC erreichbar (curl -sk https://10.10.0.66:8088/services/collector/health)
   • Splunk S2S erreichbar (nc -zv 10.10.0.66 9997)
6. Persistent Queue abarbeiten:
   • Queue-Status pruefen (Cribl UI → Monitoring → Destinations)
   • Drain-Fortschritt ueberwachen
   • Warten, bis Queue leer ist
7. End-to-End Verifikation:

   sudo ./scripts/07-verify-deployment.sh

8. Monitoring pruefen:
   • Events/sec-Rate wieder auf Normalniveau
   • Keine Fehler in Cribl-Logs
   • Splunk empfaengt Daten

5.2 Wiederanlaufreihenfolge

6. Kommunikationsplan

6.1 Kommunikationsmatrix

6.2 Kommunikationsvorlage (Sev1/Sev2)

Betreff: [SEV{X}] IceDataEmphasise - {Kurzbeschreibung}

Zeitpunkt der Erkennung: {YYYY-MM-DD HH:MM}
Betroffene Komponente(n): {Cribl Stream / Edge / Splunk / NUC}
Auswirkung: {Beschreibung der Auswirkung auf Log-Pipeline}

Aktuelle Massnahmen:
- {Massnahme 1}
- {Massnahme 2}

Geschaetzte Wiederherstellungszeit: {HH:MM oder "wird ermittelt"}
Compliance-Relevanz: {Ja/Nein - Begruendung}

Naechstes Update: {Zeitpunkt}

Verantwortlicher Engineer: {Name}
Telefon: {Nummer}

7. Post-Incident Review Template

Post-Incident Review – Vorlage

Lessons Learned und Massnahmen

Verbesserungsfragen

• Haette der Vorfall frueher erkannt werden koennen? Wie?
• War die Eskalation angemessen und rechtzeitig?
• Waren Runbooks/Dokumentation hilfreich und aktuell?
• Welche Monitoring-Luecken bestehen?
• Kann die Wiederherstellungszeit (RTO) verbessert werden?
• Sind Backup-Verfahren ausreichend getestet?