Inhaltsverzeichnis26 Abschnitte
- Der Observability-Stack für Databricks
- Layer 1: Job- und Workflow-Alerts
- Native Databricks-Job-Alerts
- Webhook-Notifications für Slack und PagerDuty
- Layer 2: Cluster-Health-Monitoring
- Ganglia-Metriken
- CloudWatch- / Azure-Monitor-Integration
- Auto-Termination und Cost-Alerts
- Layer 3: Spark-Metriken und Application-Level-Monitoring
- Den Spark-Metrics-Sink aktivieren
- Custom-Application-Metriken mit Spark-Listenern
- Datadog-Integration
- Layer 4: Datenqualitäts-Monitoring
- Row-Count-Monitoring
- Schema-Drift-Detection
- Alerting-Runbook bauen
- Alert: Job Failed
- Alert: Job Duration > Threshold
- Zusammen: Eine Monitoring-Checkliste
- FAQ
- Was monitore ich zuerst, wenn ich gar nichts habe?
- Reicht Ganglia oder brauche ich Datadog?
- Wie alertet man bei Datenqualitäts-Failures, ohne Alert-Fatigue zu produzieren?
- Wie behandle ich DSGVO-Audit-Trails?
- Was ist der Unterschied zwischen Monitoring und Observability?
- Schluss
TL;DR: Produktives Databricks-Observability spannt vier Layer: Job-/Workflow-Alerts, Cluster-Health (Ganglia/CloudWatch), Spark-Metriken (Prometheus/Datadog) und Datenqualität (Row Counts, Schema-Drift). Die meisten Teams instrumentieren nur den ersten — die anderen drei sind der Unterschied zwischen verlässlicher Plattform und ständigem Feuerlöschen.
Databricks in Produktion ohne ordentliches Monitoring zu fahren, ist wie Blindflug. Jobs scheitern still, Cluster gehen um 3 Uhr morgens das Memory aus, Pipelines stallen stundenlang, bevor jemand merkt. Eine solide Observability-Schicht zu bauen ist nicht optional — sie ist der Unterschied zwischen einer verlässlichen Datenplattform und ständigem Feuerlöschen.
Dieser Guide deckt alles ab, was du brauchst, um Databricks-Workloads zu instrumentieren, zu monitoren und Alerts zu setzen: von nativen Job-Alerts über Spark-Metriken, Cluster-Health bis hin zur Integration mit externen Plattformen wie Datadog, PagerDuty und Slack.
Der Observability-Stack für Databricks
Ein produktionsreifes Observability-Setup für Databricks spannt vier Layer:
| Layer | Was monitoren | Tools |
|---|---|---|
| Job/Workflow | Run-Status, Dauer, Failure-Rate | Databricks-Alerts, Workflows-UI |
| Cluster | CPU, Memory, Disk, GC-Pressure | Ganglia, Spark-UI, CloudWatch / Azure Monitor |
| Spark-Metriken | Task-Failures, Shuffle Read/Write, Spill | Spark-Metrics-Sink, Datadog |
| Datenqualität | Row Counts, Null-Rates, Schema-Drift | Great Expectations, dbt-Tests, Custom-Checks |
Die meisten Teams instrumentieren nur den ersten Layer und wundern sich, warum sie trotzdem von Failures überrascht werden. Echte Observability braucht alle vier.
Layer 1: Job- und Workflow-Alerts
Native Databricks-Job-Alerts
Databricks Workflows hat eingebautes Alerting für Job-Runs. Du konfigurierst Alerts via UI oder Jobs-API:
# Create a job with email alerts via CLI
databricks jobs create --json '{
"name": "daily_etl",
"email_notifications": {
"on_failure": ["oncall@company.com"],
"on_success": [],
"on_start": [],
"no_alert_for_skipped_runs": true
},
"webhook_notifications": {
"on_failure": [{"id": "your-webhook-id"}]
}
}'
Verfügbare Alert-Trigger:
| Trigger | Wann nutzen |
|---|---|
on_failure | Immer — das ist der Baseline |
on_success | Nützlich für SLA-Bestätigung |
on_start | High-Value-Long-Running-Jobs |
on_duration_warning_threshold_exceeded | Langsame Jobs vor dem Failure fangen |
Der Duration-Threshold-Alert wird unterschätzt, aber ist extrem wertvoll. Auf 20 % über deiner p95-Runtime setzen:
# Set duration alert via Python SDK
from databricks.sdk import WorkspaceClient
w = WorkspaceClient()
w.jobs.update(
job_id=12345,
new_settings={
"health": {
"rules": [
{
"metric": "RUN_DURATION_SECONDS",
"op": "GREATER_THAN",
"value": 3600 # Alert if job runs longer than 1 hour
}
]
}
}
)
Webhook-Notifications für Slack und PagerDuty
Für produktive Systeme reicht E-Mail nicht. Job-Failures an Slack und PagerDuty drahten:
# Create a Webhook destination (Databricks Notification Destinations API)
import requests
headers = {
"Authorization": f"Bearer {DATABRICKS_TOKEN}",
"Content-Type": "application/json"
}
# Create Slack webhook destination
payload = {
"display_name": "Data Engineering Slack",
"slack": {
"url": "https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK"
}
}
response = requests.post(
f"{DATABRICKS_HOST}/api/2.0/notification-destinations",
headers=headers,
json=payload
)
destination_id = response.json()["id"]
print(f"Webhook destination created: {destination_id}")
Layer 2: Cluster-Health-Monitoring
Ganglia-Metriken
Jeder Databricks-Cluster bringt Ganglia mit, erreichbar aus der Cluster-UI → Metrics-Tab. Wichtige Metriken:
| Metrik | Normalbereich | Aktion bei Überschreitung |
|---|---|---|
| CPU-Auslastung | 60–85 % | Scale-out oder Instance-Typ upgraden |
| Memory-Auslastung | < 80 % | Memory erhöhen oder Spark-Config tunen |
| Disk-I/O-Wait | < 20 % | Shuffle-Spill reduzieren, lokales SSD ergänzen |
| Network bytes in/out | Baseline-abhängig | Shuffle-heavy Stages prüfen |
CloudWatch- / Azure-Monitor-Integration
Für persistente Metriken-Speicherung und Alerting Cluster-Metriken in den Cloud-Provider-Monitoring-Service schicken:
# init_script.sh — install and configure collectd to ship to CloudWatch
# Add this as a cluster init script in Databricks
cat > /etc/collectd/collectd.conf << EOF
LoadPlugin ganglia
LoadPlugin write_cloudwatch
<Plugin ganglia>
Host "localhost"
Port "8649"
</Plugin>
<Plugin write_cloudwatch>
Region "us-east-1"
Namespace "Databricks/Clusters"
</Plugin>
EOF
service collectd restart
Auto-Termination und Cost-Alerts
Auto-Termination auf interaktiven Clustern immer setzen — sie sind die #1-Quelle für überraschende Cloud-Rechnungen:
# Set auto-termination via CLI
databricks clusters edit --json '{
"cluster_id": "0123-456789-abc123",
"autotermination_minutes": 30
}'
Layer 3: Spark-Metriken und Application-Level-Monitoring
Den Spark-Metrics-Sink aktivieren
Spark gibt einen reichen Set an Metriken über sein Metrics-System aus. Den Prometheus-Sink aktivieren, um sie zu scrapen:
# spark_metrics_config.py — add to your cluster Spark config
spark_conf = {
"spark.metrics.conf.*.sink.prometheussink.class":
"org.apache.spark.metrics.sink.PrometheusServlet",
"spark.metrics.conf.*.sink.prometheussink.path": "/metrics/prometheus",
"spark.ui.prometheus.enabled": "true"
}
Wichtige Spark-Metriken, die jeder Data Engineer tracken sollte:
| Metrik | Was sie signalisiert |
|---|---|
executor.taskFailures | Datenqualitäts-Probleme oder OOM-Errors |
executor.shuffleReadBytes | Wide Transformations, potentieller Bottleneck |
executor.memoryUsed | Annäherung an OOM-Schwelle |
executor.diskBytesSpilled | Memory-Pressure — Executor-Memory erhöhen |
driver.BlockManager.memory.remainingMem_MB | Driver-Memory-Health |
Custom-Application-Metriken mit Spark-Listenern
Für feingranulare Job-Level-Metriken einen Custom-Spark-Listener implementieren:
from pyspark import SparkContext
from pyspark.listener import SparkListener
class JobMetricsListener(SparkListener):
def __init__(self):
self.job_start_times = {}
self.job_durations = {}
def onJobStart(self, job_start):
job_id = job_start.jobId()
self.job_start_times[job_id] = job_start.time()
print(f"Job {job_id} started at {job_start.time()}")
def onJobEnd(self, job_end):
job_id = job_end.jobId()
duration_ms = job_end.time() - self.job_start_times.get(job_id, job_end.time())
self.job_durations[job_id] = duration_ms
status = "succeeded" if job_end.jobResult().toString() == "JobSucceeded" else "failed"
print(f"Job {job_id} {status} in {duration_ms}ms")
# Ship to your metrics backend here
listener = JobMetricsListener()
sc = spark.sparkContext
sc._jsc.sc().addSparkListener(listener._jlistener)
Datadog-Integration
Datadog ist die beliebteste externe Observability-Plattform für Databricks-Shops. Die offizielle Integration liefert Cluster-Metriken, Job-Metriken und Logs:
# datadog_init_script.sh — Databricks cluster init script
DD_AGENT_MAJOR_VERSION=7 DD_API_KEY=$DD_API_KEY DD_SITE="datadoghq.com" \
bash -c "$(curl -L https://s3.amazonaws.com/dd-agent/scripts/install_script_agent7.sh)"
# Configure Spark integration
cat > /etc/datadog-agent/conf.d/spark.d/conf.yaml << EOF
init_config:
instances:
- spark_url: http://localhost:4040
spark_cluster_mode: spark_standalone_mode
cluster_name: databricks_cluster
streaming_metrics: true
histogram_metrics: true
EOF
service datadog-agent restart
Layer 4: Datenqualitäts-Monitoring
Infrastruktur-Health ist nur die halbe Wahrheit. Deine Pipelines können "grün" sein und still Müll-Daten produzieren.
Row-Count-Monitoring
# data_quality_checks.py
from pyspark.sql import functions as F
def check_row_count(table_name: str, min_rows: int, date_col: str = "date",
date_val: str = None):
df = spark.table(table_name)
if date_val:
df = df.filter(F.col(date_col) == date_val)
count = df.count()
if count < min_rows:
raise ValueError(
f"Data quality FAIL: {table_name} has {count} rows "
f"(expected >= {min_rows}) for {date_val}"
)
print(f" OK {table_name}: {count} rows")
# Run as part of your pipeline
check_row_count("catalog.schema.events", min_rows=100_000, date_val="2024-01-15")
check_row_count("catalog.schema.users", min_rows=1_000, date_val="2024-01-15")
Schema-Drift-Detection
import json
from datetime import date
def detect_schema_drift(table_name: str, expected_schema_path: str):
current_schema = spark.table(table_name).schema.jsonValue()
with open(expected_schema_path) as f:
expected_schema = json.load(f)
current_fields = {f["name"]: f["type"] for f in current_schema["fields"]}
expected_fields = {f["name"]: f["type"] for f in expected_schema["fields"]}
added = set(current_fields) - set(expected_fields)
removed = set(expected_fields) - set(current_fields)
if added or removed:
raise ValueError(
f"Schema drift detected in {table_name}:\n"
f" Added: {added}\n"
f" Removed: {removed}"
)
print(f" Schema OK: {table_name}")
Alerting-Runbook bauen
Jeder Alert sollte ein Runbook haben. Template für die häufigsten Databricks-Alerts:
Alert: Job Failed
Severity: P2
Runbook:
1. Databricks-Workflow-Run-Details prüfen (UI -> Workflows -> Run History)
2. Driver-Logs nach Stack-Trace inspizieren
3. Prüfen, ob Upstream-Tabellen aktualisiert wurden (DESCRIBE HISTORY)
4. Cluster-Metriken zum Failure-Zeitpunkt prüfen (Ganglia -> Cluster Events)
5. Re-Run mit --repair-run, wenn Daten intakt
Alert: Job Duration > Threshold
Severity: P3
Runbook:
1. Spark-UI öffnen -> Stages -> langsamste Stage identifizieren
2. Shuffle Read/Write Bytes prüfen (exzessiv = Data Skew oder fehlendes Partition Pruning)
3. Prüfen, ob Input-Datenvolumen gewachsen ist (Row Count vs Historie)
4. Recent Code Changes reviewen (git log)
5. Cluster-Preemption prüfen (Cluster Events -> Spot-Interruptions)
Zusammen: Eine Monitoring-Checkliste
Beim Launch einer neuen Databricks-Pipeline in Produktion abhaken:
- Job-Failure-Alert nach Slack/PagerDuty verdrahtet
- Duration-Threshold-Alert gesetzt (p95-Runtime + 20 %)
- Auto-Termination auf interaktiven Clustern
- Datenqualitäts-Checks (Row Count, Nulls, Schema) in Pipeline eingebaut
- Spark-Metrics-Sink aktiv, schickt nach Datadog/CloudWatch
- DESCRIBE HISTORY der letzten 30 Tage zugänglich
- Runbook dokumentiert und in Alert-Message verlinkt
FAQ
Was monitore ich zuerst, wenn ich gar nichts habe?
Job-Failure-Alerts an Slack. Duration-Threshold-Alerts. Auto-Termination. Alles weitere kommt schichtweise.
Reicht Ganglia oder brauche ich Datadog?
Ganglia ist gut für Live-Cluster-Health. Datadog/CloudWatch für historische Trends, Alerting und Cross-Tool-Korrelation. Pragmatisch: Ganglia + CloudWatch/Azure-Monitor reicht für viele Teams.
Wie alertet man bei Datenqualitäts-Failures, ohne Alert-Fatigue zu produzieren?
Tiered Severity (P0/P1/P2/P3), Anomalie-Detection statt fester Schwellen, Konsolidierung pro Pipeline-Run statt pro Failure.
Wie behandle ich DSGVO-Audit-Trails?
Job-Run-Historie, Audit-Logs (Account-Level + Workspace-Level) und Unity-Catalog-Lineage zusammen ergeben einen vollständigen DSGVO-Audit-Trail. Mindestens 1 Jahr Retention.
Was ist der Unterschied zwischen Monitoring und Observability?
Monitoring = vordefinierte Metriken/Alerts. Observability = Möglichkeit, jede Frage über das System zu beantworten, ohne neue Instrumentierung. In der Praxis: gutes Logging + verteiltes Tracing + Metriken-Korrelation.
Schluss
Databricks-Workloads zu monitoren ist eine Reise, kein Ziel. Mit den Basics starten (Job-Failure-Alerts + Slack), dann progressiv Spark-Metriken, Datenqualitäts-Checks und Cluster-Health instrumentieren, während deine Plattform reift.
Diese Komplexität bei Scale zu managen — über Dutzende Jobs, mehrere Cluster und Terabytes an Delta-Tabellen — ist genau die Herausforderung, für die Harbinger Explorer gebaut wurde. Es macht Job-Health, Cluster-Trends und Datenqualitäts-Signale über deinen gesamten Workspace sichtbar, damit dein Team schnell agieren kann, ohne blind zu fliegen.
Stand: 14. Mai 2026.
Geschrieben von
Harbinger Team
Cloud-, Data- und AI-Engineer in DACH. Schreibt seit 2018 über infrastrukturkritische Tech-Entscheidungen — keine Marketing- Folien, sondern echte Trade-offs aus Production-Workloads.
Hat dir das geholfen?
Jede Woche ein neuer Artikel über DACH-Cloud, Data und AI — direkt in dein Postfach. Kein Spam, kein Marketing-Sprech.
Kein Spam. 1-Klick-Abmeldung. Datenschutz bei Loops.so.