Monitoring der Pipeline

Eine CI/CD-Pipeline ist kein „Set-and-forget"-System. Sie braucht Monitoring – Beobachtung der Pipeline selbst. Wie viele Builds laufen pro Tag? Welche brechen ab? Wo geht Zeit verloren? Sind unsere Deploys schneller geworden? Ohne diese Metriken weißt du nicht, ob deine CI/CD-Investition sich lohnt – oder ob du gerade ineffizient arbeitest.

Diese Lektion zeigt dir Pipeline-Monitoring: welche Metriken zählen, wie man sie visualisiert, die berühmten DORA-Metriken, Alerting bei Problemen, und Tools wie Prometheus + Grafana. Wer als FISI oder DevOps-Engineer arbeitet, muss diese Konzepte verstehen.

1) Warum Pipeline-Monitoring?

Stell dir zwei Teams vor. Beide haben CI/CD-Pipelines. Team A weiß nicht wie es läuft – Builds laufen halt. Team B trackt jede Pipeline, sieht Trends, optimiert ständig. Welches Team wird in 6 Monaten effizienter sein?

Konkrete Probleme die ohne Monitoring versteckt bleiben:

• Pipeline wird langsamer: 5 Min → 8 → 12 Min – kaum jemand merkt's, alle nerven sich
• Flaky Tests: 10% Failure-Rate – Entwickler ignorieren rote Pipelines
• Failed Deployments: nachts crashen Deploys – niemand kriegt's mit bis morgens
• Cost Explosion: 10× CI-Minuten verbraucht im Vergleich zum Vormonat
• Verstopfte Queues: PRs warten 30 Min auf einen Runner
• Cache-Misses: Cache invalidiert ständig, jeder Build neu installiert

Mit Monitoring siehst du diese Probleme früh, kannst sie beheben bevor sie eskalieren.

2) Die wichtigsten Pipeline-Metriken

Was solltest du tracken? Die zentralen Kennzahlen:

3) Pipeline-Dashboard

So sieht ein typisches Pipeline-Dashboard aus – Echtzeit-Übersicht der wichtigsten Kennzahlen. Du brauchst keinen Wahnsinn, ein paar gute Widgets reichen:

4) Build-Trend-Charts

Eine einzelne Zahl ist nett, aber Trends sind wichtiger. Hier ein typischer Build-Time-Trend der letzten 14 Tage:

5) DORA-Metriken: die vier Schlüssel-KPIs

Google's DORA-Forschung (DevOps Research and Assessment) hat vier Schlüsselmetriken identifiziert, die High-Performing-Teams von Low-Performing-Teams unterscheiden. Diese sind heute der Industrie-Standard:

6) Tools für Pipeline-Monitoring

Welche Werkzeuge nutzt man? Es gibt eine Reihe verschiedener Optionen, je nach Budget und Bedürfnissen:

7) Prometheus + Grafana: das Open-Source-Power-Duo

Der Goldstandard für selbstgehostetes Monitoring ist das Duo Prometheus + Grafana. Prometheus sammelt und speichert Metriken, Grafana visualisiert sie:

Prometheus scraped die Endpoints regelmäßig (z.B. alle 15 Sekunden) und speichert die Daten in einer Time-Series-Datenbank. In Grafana erstellst du Dashboards mit PromQL-Queries wie rate(jenkins_builds_total[5m]) – das zeigt Builds pro Sekunde, gemittelt über 5 Minuten.

8) Alerting: wenn Probleme auftreten

Monitoring ohne Alerting ist nur die halbe Miete. Du willst benachrichtigt werden wenn Pipelines kaputt gehen, nicht selbst Dashboards überwachen müssen:

9) Eigene Metriken in Pipelines exportieren

CI-Tools haben oft Default-Metriken, aber du kannst auch eigene Metriken aus Pipelines exportieren. Beispiel: Custom-Metrik in GitHub Actions an Datadog senden:

Solche Custom-Metriken sind Gold wert – z.B. „Test-Coverage über Zeit" oder „Bundle-Size-Trend" oder „Anzahl Sicherheits-Findings pro Release". Mit kreativen Metriken bekommst du Einblicke die kein Standard-Tool liefert.

10) Logs vs. Metrics vs. Traces

Im Observability-Bereich unterscheidet man drei Datentypen, die oft verwechselt werden. Gemeinsam bilden sie die „three pillars of observability":

Für Pipeline-Monitoring brauchst du vor allem Metrics (Trends, Aggregate) und Logs (was ist genau passiert beim fehlgeschlagenen Build). Traces sind eher für die Anwendung, weniger für die Pipeline selbst. Mehr in K46 Debugging.

11) Pipeline-Optimierung anhand der Metriken

Monitoring ist nutzlos ohne Aktion. Was du tun kannst wenn die Metriken Probleme zeigen:

• Hohe Failure Rate: Flaky Tests jagen und fixen, Test-Infrastruktur stabilisieren
• Lange Build Duration: Caching prüfen, Tests parallelisieren, Build-Steps optimieren
• Hohe Queue Time: mehr Runner bereitstellen, Concurrency-Settings prüfen
• Cache Hit Rate niedrig: Cache-Keys überprüfen, Cache-Strategie überarbeiten
• CI-Minuten überschritten: Pipelines triggern verfeinern (nicht alles bei jedem Doku-Update), Self-Hosted Runner erwägen
• Lange Lead Time: Branching-Strategie überdenken, kleinere PRs
• Hohe Change Failure Rate: mehr Tests, bessere Quality Gates, Feature Flags einführen

12) Monitoring für die Anwendung selbst

Pipeline-Monitoring ist nur die halbe Geschichte. Du brauchst auch Application Monitoring – das was nach dem Deploy in Production passiert. Wenn eine neue Version 5% langsamer ist oder 0.5% mehr 5xx-Errors generiert, ist das auch eine CI/CD-relevante Info – nämlich dass dein letzter Deploy ein Problem ist.

Best Practice: Deploy-Marker in Monitoring-Tools. Wenn du deployst, sendet die Pipeline ein „v1.4.2 deployed at 14:30"-Event an Datadog/Grafana. Dann siehst du im Application-Graph genau: ab 14:30 ist Latency hochgegangen → wahrscheinlich der Deploy schuld → Rollback.

Zusammenfassung

Pipeline-Monitoring ist Pflicht für jedes ernstzunehmende CI/CD-Setup. Wichtige Metriken: Build Success Rate, Duration, Queue Time, Failure Rate, Deployment Frequency. DORA-Metriken als Industrie-Standard: Deployment Frequency, Lead Time for Changes, Change Failure Rate, Mean Time to Recovery – Elite-Teams deployen täglich, Lead Time <1h, Failure <5%, Recovery <1h. Tools: Prometheus+Grafana (Open Source), Datadog/New Relic (SaaS), CloudWatch (AWS-nativ), eingebaute Analytics in GitHub/GitLab. Alerting für kritische Probleme – Slack, E-Mail, PagerDuty. Three pillars of observability: Metrics, Logs, Traces – für Pipelines vor allem Metrics + Logs. Custom-Metriken aus Pipelines exportieren für maßgeschneiderte Insights. Monitoring ist sinnlos ohne Aktion – Trends erkennen und Pipelines optimieren. Deploy-Marker verbinden Pipeline-Events mit Application-Metriken für vollständigen Überblick.