Revisionshistorie
| Version | Datum | Autor | Beschreibung |
| 1.0 | 2026-02-10 | Marcus Pauli | Erstversion des Monitoring- und Alerting-Konzepts |
Inhaltsverzeichnis
- Cribl-internes Monitoring
- Externe Health Checks
- Key Performance Indicators (KPIs)
- Monitoring-Integration (Prometheus/Grafana)
- Alerting-Konzept
- Dashboard-Empfehlungen
- 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
| Metrik | Beschreibung | Zugriff |
| CPU-Auslastung | CPU-Verbrauch der Cribl Worker-Prozesse | Monitoring → System → CPU |
| Speicherverbrauch (RAM) | Heap- und RSS-Speicher pro Worker | Monitoring → System → Memory |
| Disk I/O | Lese-/Schreiboperationen (insb. Persistent Queue) | Monitoring → System → Disk |
| Netzwerk I/O | Eingehende/ausgehende Bytes pro Sekunde | Monitoring → System → Network |
| Open File Descriptors | Anzahl offener Dateideskriptoren | Monitoring → System → Resources |
1.2 Worker Health
| Metrik | Beschreibung | Normaler Bereich |
| Worker-Status | Running / Stopped / Error | Alle Worker: Running |
| Worker Uptime | Laufzeit seit letztem Restart | > 24h (stabil) |
| Backpressure Status | Ob eine Destination Backpressure signalisiert | None |
| Event Processing Rate | Events/sec pro Worker | Abhaengig 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:
| Testgruppe | Tests | Prueft |
| Service Checks | 3 | Cribl Stream/Edge Service aktiv, Port 9000 erreichbar |
| API Checks | 2 | Health Endpoint, Login-Authentifizierung |
| Konfiguration | 5 | Edge-Registrierung, Sources (≥12), Destinations (HEC+S2S), Pipelines (≥5), Routes |
| Splunk-Konnektivitaet | 3 | HEC-Port, S2S-Port, Test-Event via HEC |
| Datensammlung | 1 | Systemd-Journal-Quelle aktiv |
| System | 5 | Berechtigungen, 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.
| KPI | Berechnung | Zielwert |
| Datenreduktionsrate | (Bytes_In − Bytes_Out) / Bytes_In × 100 | ≥ 30% (PoC-Ziel) |
| Event-Reduktionsrate | (Events_In − Events_Out) / Events_In × 100 | Abhaengig von Pipeline |
| Lizenzverbrauch (geschaetzt) | Bytes_Out / Tag umgerechnet in GB/Tag | Innerhalb 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:
- Prometheus als Datenquelle in Grafana hinzufuegen
- Dashboard importieren oder manuell erstellen (siehe Abschnitt 6)
- 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
| Kanal | Verwendung | Konfiguration |
| E-Mail | Alle Alerts (Sev1-Sev4) | SMTP-Relay der Bank, Verteiler: cribl-alerts@bank.example |
| SMS/Pager | Sev1 und ausgewaehlte Sev2 | Ueber Alerting-Gateway der Bank |
| Ticketsystem | Automatische Ticket-Erstellung bei Sev1-Sev3 | API-Integration mit ITSM-Tool |
| Chat (Teams/Slack) | Informationell fuer Sev2-Sev4 | Webhook-Integration |
6. Dashboard-Empfehlungen
6.1 Operations Dashboard (Hauptansicht)
Das Operations Dashboard bietet eine Gesamtuebersicht ueber den Zustand der Log-Pipeline:
| Panel | Visualisierung | Datenquelle |
| Pipeline Health Status | Ampel (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 |
| Datenreduktionsrate | Gauge (Prozent) | Berechnet aus In/Out |
| Queue Depth | Balkendiagramm | Queue Metrics |
| CPU / RAM Auslastung | Gauge + Verlauf | System Metrics |
| Active Sources | Zaehler + Liste | Inputs API |
| Error Rate | Liniendiagramm | Cribl Metrics API |
| Letzte Alerts | Tabelle | Alert-Log |
6.2 Source-Detail Dashboard
| Panel | Beschreibung |
| Events/sec pro Source | Aufgeschluesselt nach den 12 konfigurierten Quellen |
| Source Health | Status je Quelle (Active/Inactive/Error) |
| Top Sources by Volume | Rangfolge nach Datenvolumen |
| Source Error Log | Letzte Fehler pro Quelle |
6.3 Destination-Detail Dashboard
| Panel | Beschreibung |
| Destination Health | HEC und S2S Status (Connected/Disconnected/Error) |
| Events/sec pro Destination | Aufgeschluesselt nach HEC und S2S |
| Queue Status pro Destination | Queue Depth und Disk Usage |
| Delivery Latenz | Zeitverzoegerung 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.