Bulutistan: Monitoring- und Observability-Plattform für Cloud-Infrastruktur

Ab einer bestimmten Größe werden kommerzielle APM-Tools entweder unerschwinglich teuer oder unzureichend flexibel. Wenn Ihre Infrastruktur 500+ Knoten über mehrere Availability Zones umfasst und Ihr Team volle Kontrolle über Metrikerfassung, Aufbewahrung und Alerting-Logik benötigt, wird der Open-Source-Monitoring-Stack — Prometheus, Grafana, Alertmanager und Thanos — zur pragmatischen Wahl. Dieser Leitfaden behandelt die Architekturmuster, Alerting-Design-Prinzipien und operativen Praktiken, die diesen Stack im Enterprise-Maßstab funktionsfähig machen.

Warum kommerzielle APM-Tools an ihre Grenzen stoßen

Kommerzielle Observability-Plattformen (Datadog, New Relic, Dynatrace) bieten exzellente Developer Experience für kleine bis mittelgroße Deployments. Sie versagen im Enterprise-Maßstab aus drei Gründen:

• Kosten — Pro-Host- oder Pro-GB-Preismodelle werden jenseits einiger Hundert Knoten unwirtschaftlich. Bei 500+ Knoten mit 15-Sekunden-Scrape-Intervallen können die Ingestion-Kosten die Infrastrukturkosten selbst übersteigen.
• Kardinalitätslimits — kommerzielle Plattformen erzwingen Metrik-Kardinalitätslimits, die die Granularität benutzerdefinierter Metriken einschränken. Infrastruktur-Betreiber benötigen hochkardinalige Dimensionen (pro Mandant, pro Festplatte, pro Container).
• Vendor Lock-in — proprietäre Abfragesprachen und Dashboard-Formate machen die Migration schmerzhaft. PromQL ist ein offener Standard mit breiter Ökosystem-Unterstützung.

Der Open-Source-Stack tauscht operativen Komfort gegen Kontrolle, Kostentransparenz und unbegrenzte Flexibilität. Für Plattformunternehmen und große Unternehmen lohnt sich dieser Trade-off fast immer.

Der Open-Source-Monitoring-Stack

Die Kernkomponenten und ihre Rollen:

• Prometheus — Metrikerfassung und Kurzzeitspeicher (15-30 Tage). Pull-basiertes Modell, PromQL-Abfragesprache, native Service Discovery.
• Grafana — Visualisierung und Dashboarding. Unterstützt Prometheus, Thanos und Dutzende anderer Datenquellen.
• Alertmanager — Alert-Routing, Gruppierung, Stummschaltung und Benachrichtigung. Integration mit PagerDuty, Slack, E-Mail und Webhooks.
• Thanos — Langzeit-Metrikspeicher, globale Abfragesicht über föderierte Prometheus-Instanzen und Downsampling für historische Daten.

Prometheus-Architektur für 500+ Knoten

Eine einzelne Prometheus-Instanz kann 500+ Knoten bei 15-Sekunden-Intervallen nicht zuverlässig scrapen. Die Lösung ist Federation:

1. Regionale Prometheus-Instanzen — eine pro Availability Zone oder Rechenzentrumssegment, die jeweils 100-200 lokale Targets scrapen. Das hält die Scrape-Latenz unter 2 Sekunden und die Kardinalität handhabbar.
2. Globales Prometheus — föderiert hochrangige Aggregate aus regionalen Instanzen für regionsübergreifende Dashboards und SLA-Reporting. Scrapt keine einzelnen Targets.
3. Thanos-Sidecar — läuft neben jedem regionalen Prometheus und lädt Blöcke in Object Storage (S3, GCS oder MinIO) für Langzeitaufbewahrung. Bietet sechs Monate oder mehr Metrik-History mit Hot-Storage-vergleichbarer Abfrageleistung.

In der Praxis reduziert die föderierte Architektur die MTTD (Mean Time to Detect) von 10-15 Minuten auf unter 90 Sekunden. Der Schlüssel liegt darin, Scrape-Intervalle auf regionaler Ebene kurz zu halten (15 Sekunden) und nur Aggregate global zu föderieren.

Grafana-Dashboard-Design-Prinzipien

Effektive Dashboards zeigen nicht jede Metrik — sie machen handlungsrelevante Informationen sichtbar. Design-Prinzipien, die im Maßstab funktionieren:

• Vier Dashboard-Domänen — organisieren Sie Dashboards nach Zielgruppe: Infrastrukturgesundheit (SRE-Team), Netzwerkperformance (Netzwerkingenieure), Mandanten-Metriken (kundenorientierte Teams) und Business-Metriken (Management).
• Progressive Offenlegung — Übersichts-Dashboards verlinken auf detaillierte Drill-downs. Das NOC-Team sollte die Infrastrukturgesundheit auf einen Blick sehen und nur bei Untersuchungen zu knotenweisen Details durchklicken.
• Konsistentes Layout — jedes Dashboard folgt dem gleichen visuellen Muster: Statusindikatoren oben, Zeitreihen in der Mitte, Tabellen unten. Konsistenz reduziert die kognitive Belastung bei Vorfällen.
• Template-Variablen — verwenden Sie Grafana-Variablen für Region-, Cluster- und Knotenauswahl. Erstellen Sie niemals Dashboard-Kopien pro Region oder Cluster.

Alert-Müdigkeit: Handlungsrelevante Alerts designen

Alerting ist der am häufigsten unter-engineerte Aspekt von Monitoring-Plattformen. Das Ziel ist nicht, auf alles zu alerten — sondern nur auf Zustände, die menschliches Handeln erfordern. Strukturieren Sie Alerts über drei Schweregrad-Stufen:

1. P1 — Sofort pagen: Knoten ausgefallen, Storage-Cluster degradiert, Netzwerk-Uplink-Ausfall. PagerDuty-Integration mit 2-Minuten-Eskalation. Diese sollten in einer gut geführten Umgebung weniger als 5 Mal pro Monat auslösen.
2. P2 — Benachrichtigung innerhalb von 15 Minuten: CPU für 10 Minuten dauerhaft über 85 %, Festplatte füllt sich schneller als 72-Stunden-Projektion, Memory Swap aktiv. Slack-Kanal-Benachrichtigung mit Bereitschafts-Bestätigung.
3. P3 — Ticket während Geschäftszeiten: Zertifikatsablauf-Warnungen (30 Tage im Voraus), veraltete API-Nutzung, langsame Abfragenakkumulation. JIRA-Ticket-Erstellung, kein Paging.

Kritische Design-Muster zur Vermeidung von Alert-Müdigkeit:

• Inhibierungsregeln — unterdrücken Sie nachgelagerte Alerts, wenn ein Ursachen-Alert bereits aktiv ist. Ein Knoten-Down-Alert sollte alle Service-Alerts auf diesem Knoten inhibieren.
• Gruppierung — Alertmanager gruppiert zusammenhängende Alerts in eine einzelne Benachrichtigung. Bei einer Netzwerkpartition sollten Sie einen Alert erhalten, nicht 200.
• Stummschaltungsfenster — geplante Wartungsfenster sollten Alerts für betroffene Komponenten automatisch stummschalten.

Kapazitätsplanung mit Monitoring-Daten

Monitoring-Daten dienen nicht nur der Incident Response — sie sind die Grundlage für proaktive Kapazitätsplanung. Die Muster, die funktionieren:

• Trendbasierte Projektionen — verwenden Sie predict_linear() in PromQL, um zu prognostizieren, wann eine Ressource erschöpft sein wird. Eine 30-Tage-Vorwärtsprojektion gibt Beschaffungsteams genug Vorlaufzeit für Hardwarebestellungen.
• Saisonale Zerlegung — Cloud-Infrastruktur-Traffic folgt starken wöchentlichen und täglichen Zyklen. Verwenden Sie Grafanas ML-Plugin oder externe Anomalie-Erkennung, um erwartete Spitzen von echten Ausreißern zu unterscheiden. Rechnen Sie mit einer 4-wöchigen Trainingsperiode, um False-Positive-Raten unter 3 % zu senken.
• Mandantenweise Ressourcenverfolgung — verfolgen Sie den Ressourcenverbrauch pro Kundenmandant. Das ermöglicht nutzungsbasierte Abrechnung, identifiziert Mandanten, die Kapazitätsgrenzen erreichen, und unterstützt SLA-Compliance-Reporting.

Der Open-Source-Monitoring-Stack erfordert mehr operative Investition als kommerzielle Alternativen, bietet aber unbegrenzte Flexibilität, keine Pro-Knoten-Lizenzkosten und volle Kontrolle über Ihre Observability-Daten. Für Infrastruktur im Maßstab amortisiert sich dieser Trade-off innerhalb des ersten Jahres.