12 – Monitoring und Alerting

Version: 1.0 Datum: 2026-02-10 Klassifikation: Vertraulich / Intern Projekt: IceDataEmphasise

Revisionshistorie

VersionDatumAutorBeschreibung
1.02026-02-10Marcus PauliErstversion des Monitoring- und Alerting-Konzepts

Inhaltsverzeichnis

  1. Cribl-internes Monitoring
  2. Externe Health Checks
  3. Key Performance Indicators (KPIs)
  4. Monitoring-Integration (Prometheus/Grafana)
  5. Alerting-Konzept
  6. Dashboard-Empfehlungen
  7. Cron-basiertes Monitoring Setup

1. Cribl-internes Monitoring

Cribl Stream bietet ein integriertes Monitoring-Dashboard, das ueber die Web-UI unter http://<stream-host>:9000 erreichbar ist. Die folgenden Bereiche werden ueberwacht:

1.1 System Metrics

MetrikBeschreibungZugriff
CPU-AuslastungCPU-Verbrauch der Cribl Worker-ProzesseMonitoring → System → CPU
Speicherverbrauch (RAM)Heap- und RSS-Speicher pro WorkerMonitoring → System → Memory
Disk I/OLese-/Schreiboperationen (insb. Persistent Queue)Monitoring → System → Disk
Netzwerk I/OEingehende/ausgehende Bytes pro SekundeMonitoring → System → Network
Open File DescriptorsAnzahl offener DateideskriptorenMonitoring → System → Resources

1.2 Worker Health

MetrikBeschreibungNormaler Bereich
Worker-StatusRunning / Stopped / ErrorAlle Worker: Running
Worker UptimeLaufzeit seit letztem Restart> 24h (stabil)
Backpressure StatusOb eine Destination Backpressure signalisiertNone
Event Processing RateEvents/sec pro WorkerAbhaengig von Last

1.3 Monitoring-API Endpunkte

# Health Check
curl -s http://localhost:9000/api/v1/health | jq .

# System Info
curl -s -H "Authorization: Bearer ${TOKEN}" \
    http://localhost:9000/api/v1/system/info | jq .

# Worker Status
curl -s -H "Authorization: Bearer ${TOKEN}" \
    http://localhost:9000/api/v1/master/workers | jq .

# Aktive Inputs/Outputs
curl -s -H "Authorization: Bearer ${TOKEN}" \
    http://localhost:9000/api/v1/m/default/system/inputs | jq '.items | length'

# Metriken (internes Metriken-Endpoint)
curl -s -H "Authorization: Bearer ${TOKEN}" \
    http://localhost:9000/api/v1/system/metrics | jq .

2. Externe Health Checks

2.1 Verifikationsskript (07-verify-deployment.sh)

Das Projekt beinhaltet eine umfassende Verifikationssuite unter scripts/07-verify-deployment.sh, die ca. 20 Tests durchfuehrt:

TestgruppeTestsPrueft
Service Checks3Cribl Stream/Edge Service aktiv, Port 9000 erreichbar
API Checks2Health Endpoint, Login-Authentifizierung
Konfiguration5Edge-Registrierung, Sources (≥12), Destinations (HEC+S2S), Pipelines (≥5), Routes
Splunk-Konnektivitaet3HEC-Port, S2S-Port, Test-Event via HEC
Datensammlung1Systemd-Journal-Quelle aktiv
System5Berechtigungen, PQ-Verzeichnisse, Service-Restart, Tailscale, Festplatte
# Verifikationssuite ausfuehren
sudo ./scripts/07-verify-deployment.sh

# Ergebnis: Tabelle mit PASS/FAIL je Test
# Exit-Code: 0 = alle Tests bestanden, 1 = mindestens ein Test fehlgeschlagen

2.2 Einfacher Health Check (curl-basiert)

#!/usr/bin/env bash
# Einfacher Health Check fuer Cron oder externe Monitoring-Systeme

STREAM_URL="http://localhost:9000/api/v1/health"
SPLUNK_HEC="https://10.10.0.66:8088/services/collector/health"

# Cribl Stream Health
stream_status=$(curl -s -o /dev/null -w "%{http_code}" "${STREAM_URL}" 2>/dev/null)
if [[ "${stream_status}" != "200" ]]; then
    echo "CRITICAL: Cribl Stream nicht erreichbar (HTTP ${stream_status})"
    exit 2
fi

# Cribl Edge Service
if ! systemctl is-active cribl-edge &>/dev/null; then
    echo "WARNING: Cribl Edge Service nicht aktiv"
    exit 1
fi

# Splunk HEC
splunk_status=$(curl -sk -o /dev/null -w "%{http_code}" "${SPLUNK_HEC}" 2>/dev/null)
if [[ "${splunk_status}" != "200" ]]; then
    echo "WARNING: Splunk HEC nicht erreichbar (HTTP ${splunk_status})"
    exit 1
fi

echo "OK: Alle Komponenten erreichbar"
exit 0

3. Key Performance Indicators (KPIs)

3.1 KPI-Definitionen

KPI Beschreibung Messintervall Zielwert (PoC) Warnschwelle Kritisch
Events/sec (In) Eingehende Events pro Sekunde an Cribl Stream 10 Sekunden > 0 (kontinuierlich) 0 fuer > 5 Min. 0 fuer > 15 Min.
Events/sec (Out) Ausgehende Events pro Sekunde an Destinations 10 Sekunden ≈ Events/sec (In) Differenz > 20% Differenz > 50%
Bytes/sec (In) Eingehende Datenmenge pro Sekunde 10 Sekunden Baseline abhaengig > 200% Baseline > 500% Baseline
Bytes/sec (Out) Ausgehende Datenmenge pro Sekunde 10 Sekunden ≤ Bytes/sec (In) > Bytes/sec (In)
Queue Depth Anzahl Events in der Persistent Queue 30 Sekunden 0 (keine Stauung) > 10.000 Events > 100.000 Events
Queue Disk Usage Festplattenverbrauch der Persistent Queue 1 Minute < 100 MB > 500 MB > 2 GB
Error Rate Fehlerhafte Events / Gesamte Events (Prozent) 1 Minute < 0,1% > 1% > 5%
Latenz (E2E) Zeit von Quelle bis Splunk-Indizierung 5 Minuten < 30 Sekunden > 60 Sekunden > 5 Minuten
Drop Rate Verworfene Events pro Minute 1 Minute 0 > 0 fuer > 5 Min. > 100/Min. kontinuierlich
CPU-Auslastung CPU-Verbrauch der Cribl-Prozesse 30 Sekunden < 50% > 70% > 90%
RAM-Verbrauch Speicherverbrauch der Cribl-Prozesse 30 Sekunden < 2 GB > 4 GB > 6 GB

3.2 Datenreduktions-KPIs

Hinweis: Ein Hauptziel des PoC ist die Validierung der Datenreduktion durch Cribl-Pipelines. Die folgenden KPIs messen den Erfolg dieser Optimierungen.
KPIBerechnungZielwert
Datenreduktionsrate(Bytes_In − Bytes_Out) / Bytes_In × 100≥ 30% (PoC-Ziel)
Event-Reduktionsrate(Events_In − Events_Out) / Events_In × 100Abhaengig von Pipeline
Lizenzverbrauch (geschaetzt)Bytes_Out / Tag umgerechnet in GB/TagInnerhalb Splunk-Lizenz

4. Monitoring-Integration (Prometheus/Grafana)

4.1 Prometheus-Endpunkt

Cribl Stream kann Metriken im Prometheus-Format bereitstellen. Hierzu wird ein interner Metrics-Endpunkt genutzt oder alternativ ein Exporter konfiguriert.

# Cribl Stream Metriken abrufen (Prometheus-Format)
curl -s -H "Authorization: Bearer ${TOKEN}" \
    http://localhost:9000/api/v1/system/metrics/prometheus

# Alternativ: Eigener Exporter via Script
# Siehe Abschnitt 7 (Cron-basiertes Monitoring)

4.2 Prometheus Scrape-Konfiguration

# prometheus.yml - Scrape-Konfiguration fuer Cribl
scrape_configs:
  - job_name: 'cribl-stream'
    scrape_interval: 30s
    metrics_path: '/api/v1/system/metrics/prometheus'
    bearer_token: '${CRIBL_API_TOKEN}'
    static_configs:
      - targets: ['localhost:9000']
        labels:
          environment: 'poc'
          component: 'cribl-stream'

  - job_name: 'cribl-health'
    scrape_interval: 60s
    metrics_path: '/api/v1/health'
    static_configs:
      - targets: ['localhost:9000']
        labels:
          environment: 'poc'

4.3 Grafana-Integration

Fuer eine visuelle Darstellung der Metriken wird Grafana empfohlen. Konfiguration:

  1. Prometheus als Datenquelle in Grafana hinzufuegen
  2. Dashboard importieren oder manuell erstellen (siehe Abschnitt 6)
  3. Alerting-Regeln in Grafana konfigurieren (als Ergaenzung zu Cribl-eigenen Alerts)
PoC-Hinweis: Im PoC-Betrieb ist eine Prometheus/Grafana-Integration optional. Das Cron-basierte Monitoring (Abschnitt 7) und die eingebauten Cribl-Dashboards sind fuer den initialen Betrieb ausreichend.

5. Alerting-Konzept

5.1 Schwellwerte und Benachrichtigungen

Alert Bedingung Severity Benachrichtigung Aktion
Stream Service Down Health-Endpoint nicht erreichbar fuer > 2 Min. Sev1 E-Mail + SMS Sofortige Untersuchung, ggf. Restart
Edge Service Down systemctl is-active cribl-edge != active Sev2 E-Mail Service neustarten, Logs pruefen
Splunk nicht erreichbar HEC oder S2S Port nicht erreichbar fuer > 5 Min. Sev1 E-Mail + SMS Netzwerk/Splunk pruefen, Queue monitoren
Keine eingehenden Events Events/sec (In) = 0 fuer > 5 Min. Sev2 E-Mail Sources und Edge-Agenten pruefen
Persistent Queue waechst Queue Depth > 10.000 Events Sev2 E-Mail Destination-Konnektivitaet pruefen
Queue kritisch voll Queue Disk > 2 GB oder > 80% des Limits Sev1 E-Mail + SMS Sofortige Untersuchung, Datenverlust droht
Hohe CPU-Auslastung CPU > 90% fuer > 10 Min. Sev3 E-Mail Worker-Tuning, Pipeline-Optimierung
Hoher RAM-Verbrauch RSS > 6 GB Sev3 E-Mail Memory-Leak pruefen, Restart erwaegen
Event Drop Rate erhoet Drop Rate > 0 fuer > 5 Min. Sev2 E-Mail Routes/Pipelines pruefen, Kapazitaet erhoehen
Hohe Latenz E2E-Latenz > 60 Sekunden Sev3 E-Mail Pipeline-Performance analysieren
Disk Space niedrig Freier Speicher < 2 GB auf /opt Sev2 E-Mail Queue bereinigen, alte Logs loeschen
Zertifikat laeuft ab TLS-Zertifikat laeuft in < 14 Tagen ab Sev3 E-Mail Zertifikat erneuern

5.2 Benachrichtigungskanaele

KanalVerwendungKonfiguration
E-MailAlle Alerts (Sev1-Sev4)SMTP-Relay der Bank, Verteiler: cribl-alerts@bank.example
SMS/PagerSev1 und ausgewaehlte Sev2Ueber Alerting-Gateway der Bank
TicketsystemAutomatische Ticket-Erstellung bei Sev1-Sev3API-Integration mit ITSM-Tool
Chat (Teams/Slack)Informationell fuer Sev2-Sev4Webhook-Integration

6. Dashboard-Empfehlungen

6.1 Operations Dashboard (Hauptansicht)

Das Operations Dashboard bietet eine Gesamtuebersicht ueber den Zustand der Log-Pipeline:

PanelVisualisierungDatenquelle
Pipeline Health StatusAmpel (Gruen/Gelb/Rot)Health-API + Service-Status
Events/sec (In vs. Out)Liniendiagramm (zeitbasiert)Cribl Metrics API
Bytes/sec (In vs. Out)Liniendiagramm (zeitbasiert)Cribl Metrics API
DatenreduktionsrateGauge (Prozent)Berechnet aus In/Out
Queue DepthBalkendiagrammQueue Metrics
CPU / RAM AuslastungGauge + VerlaufSystem Metrics
Active SourcesZaehler + ListeInputs API
Error RateLiniendiagrammCribl Metrics API
Letzte AlertsTabelleAlert-Log

6.2 Source-Detail Dashboard

PanelBeschreibung
Events/sec pro SourceAufgeschluesselt nach den 12 konfigurierten Quellen
Source HealthStatus je Quelle (Active/Inactive/Error)
Top Sources by VolumeRangfolge nach Datenvolumen
Source Error LogLetzte Fehler pro Quelle

6.3 Destination-Detail Dashboard

PanelBeschreibung
Destination HealthHEC und S2S Status (Connected/Disconnected/Error)
Events/sec pro DestinationAufgeschluesselt nach HEC und S2S
Queue Status pro DestinationQueue Depth und Disk Usage
Delivery LatenzZeitverzoegerung bis zur Zustellung

7. Cron-basiertes Monitoring Setup

7.1 Monitoring-Skript

#!/usr/bin/env bash
# /opt/IceDataEmphasise/scripts/monitoring/health-check.sh
# Cron-basierter Health Check fuer IceDataEmphasise
# Ausfuehrung: alle 5 Minuten via Cron

LOG_FILE="/var/log/cribl-health-check.log"
ALERT_EMAIL="cribl-alerts@bank.example"
TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')

STATUS="OK"
MESSAGES=()

# 1. Cribl Stream Health
stream_http=$(curl -s -o /dev/null -w "%{http_code}" \
    http://localhost:9000/api/v1/health 2>/dev/null || echo "000")
if [[ "${stream_http}" != "200" ]]; then
    STATUS="CRITICAL"
    MESSAGES+=("Cribl Stream Health Check fehlgeschlagen (HTTP ${stream_http})")
fi

# 2. Cribl Edge Service
if ! systemctl is-active cribl-edge &>/dev/null; then
    [[ "${STATUS}" != "CRITICAL" ]] && STATUS="WARNING"
    MESSAGES+=("Cribl Edge Service nicht aktiv")
fi

# 3. Splunk HEC Erreichbarkeit
splunk_http=$(curl -sk -o /dev/null -w "%{http_code}" \
    https://10.10.0.66:8088/services/collector/health 2>/dev/null || echo "000")
if [[ "${splunk_http}" != "200" ]]; then
    STATUS="CRITICAL"
    MESSAGES+=("Splunk HEC nicht erreichbar (HTTP ${splunk_http})")
fi

# 4. Festplattenplatz
free_gb=$(df -BG --output=avail /opt 2>/dev/null | tail -1 | tr -d ' G')
if [[ "${free_gb}" -lt 2 ]]; then
    STATUS="CRITICAL"
    MESSAGES+=("Festplattenspeicher kritisch niedrig: ${free_gb} GB frei")
elif [[ "${free_gb}" -lt 5 ]]; then
    [[ "${STATUS}" != "CRITICAL" ]] && STATUS="WARNING"
    MESSAGES+=("Festplattenspeicher niedrig: ${free_gb} GB frei")
fi

# 5. Persistent Queue Groesse
if [[ -d /opt/cribl/state/queues ]]; then
    queue_mb=$(du -sm /opt/cribl/state/queues 2>/dev/null | cut -f1)
    if [[ "${queue_mb}" -gt 2048 ]]; then
        STATUS="CRITICAL"
        MESSAGES+=("Persistent Queue kritisch gross: ${queue_mb} MB")
    elif [[ "${queue_mb}" -gt 512 ]]; then
        [[ "${STATUS}" != "CRITICAL" ]] && STATUS="WARNING"
        MESSAGES+=("Persistent Queue waechst: ${queue_mb} MB")
    fi
fi

# Ergebnis loggen
if [[ ${#MESSAGES[@]} -eq 0 ]]; then
    echo "${TIMESTAMP} [${STATUS}] Alle Checks bestanden" >> "${LOG_FILE}"
else
    for msg in "${MESSAGES[@]}"; do
        echo "${TIMESTAMP} [${STATUS}] ${msg}" >> "${LOG_FILE}"
    done
fi

# Bei WARNING oder CRITICAL: E-Mail senden
if [[ "${STATUS}" != "OK" ]]; then
    {
        echo "IceDataEmphasise Health Check - ${STATUS}"
        echo "Zeitpunkt: ${TIMESTAMP}"
        echo ""
        for msg in "${MESSAGES[@]}"; do
            echo "- ${msg}"
        done
    } | mail -s "[${STATUS}] IceDataEmphasise Health Check" "${ALERT_EMAIL}"
fi

exit 0

7.2 Cron-Konfiguration

# Crontab-Eintraege (sudo crontab -e)

# Health Check alle 5 Minuten
*/5 * * * * /opt/IceDataEmphasise/scripts/monitoring/health-check.sh

# Vollstaendige Verifikation taeglich um 06:00
0 6 * * * /opt/IceDataEmphasise/scripts/07-verify-deployment.sh \
    >> /var/log/cribl-verify.log 2>&1

# Log-Rotation woechentlich
0 0 * * 0 find /var/log/cribl-health-check.log -size +10M \
    -exec mv {} {}.old \; 2>/dev/null

7.3 Log-Rotation

# /etc/logrotate.d/cribl-monitoring
/var/log/cribl-health-check.log
/var/log/cribl-verify.log {
    weekly
    rotate 12
    compress
    delaycompress
    missingok
    notifempty
    create 0640 root root
}
Empfehlung: Im PoC-Betrieb sollte das Cron-basierte Monitoring als Minimum eingerichtet werden. Fuer den Produktivbetrieb wird zusaetzlich eine Prometheus/Grafana-Integration empfohlen.