Cloud Performance Monitoring: Tools, Metriken & Best Practices

Cloud Performance Monitoring ist die Praxis, kontinuierlich Metriken aus Cloud-Infrastruktur, Anwendungen und Netzwerken zu sammeln, zu korrelieren und darauf zu alertieren – mit dem Ziel, Verfügbarkeit, Geschwindigkeit und Kosteneffizienz sicherzustellen. Richtig umgesetzt, verkürzt es die Mean Time to Detect (MTTD) von Stunden auf Sekunden, verhindert SLA-Verletzungen bevor Nutzer sie bemerken, und liefert Engineering-Teams die Datengrundlage für Right-Sizing statt Über-Provisionierung. Dieser Leitfaden behandelt die Metriken, die in Produktion wirklich zählen, die Tooling-Auswahl über AWS, Azure und GCP hinweg sowie die operativen Muster, auf die ein 24/7-NOC täglich vertraut.

Zentrale Erkenntnisse

• Cloud Performance Monitoring basiert auf drei Säulen – Infrastruktur-Metriken, Application Performance und Network Observability – die in einer zentralen Oberfläche zusammenlaufen.
• Native Tools (CloudWatch, Azure Monitor, GCP Cloud Monitoring) sind notwendig, reichen aber selten für Multi-Cloud-Umgebungen aus; ergänzen Sie sie durch eine plattformübergreifende Schicht.
• Die produktionsrelevanten Metriken sind p95/p99 Latency, Error Rate, Saturation und Time-to-Detect (TTD) – nicht CPU-Durchschnittswerte.
• Organisationen in der EU müssen NIS2-Meldepflichten, DSGVO-Datenresidenz und BSI-C5-Anforderungen von Anfang an in ihre Monitoring-Architektur einplanen.
• FinOps und Performance Monitoring wachsen zusammen: Idle-Resource-Erkennung und Right-Sizing-Empfehlungen gehören in dieselbe Observability-Pipeline.

Warum Cloud Performance Monitoring unverzichtbar ist

On-Premises-Infrastruktur hatte einen begrenzten Blast Radius. Ein Rack fiel aus, aber Sie konnten hinlaufen. Cloud-Infrastruktur ist per Design verteilt – über Availability Zones, Regionen und häufig mehrere Provider hinweg –, was bedeutet, dass Ausfälle partiell, intermittierend und ohne Instrumentierung deutlich schwerer zu korrelieren sind.

Was unser NOC wiederholt beobachtet: Die Anwendungslatenz eines Kunden verschlechtert sich um 300 ms, aber keine einzelne Metrik ist rot. Die Root Cause entpuppt sich als Cross-AZ-Traffic, der eine Bandbreitengrenze erreicht, die erst sichtbar wird, wenn Sie VPC Flow Logs mit Application Traces korrelieren. Ohne Monitoring, das die Grenze zwischen Infrastruktur und Anwendung überbrückt, sieht das Problem aus wie „die App ist langsam" – und das falsche Team wird alarmiert.

Cloud Performance Monitoring ist kein optionaler Overhead. Es ist das operative Nervensystem. Ohne es debuggen Sie in Produktion mit kubectl logs und Hoffnung.

Die Kosten fehlenden Monitorings

Die direkten Kosten von Downtime werden endlos diskutiert. Die indirekten Kosten wiegen schwerer: Engineering-Teams, die 40 % ihrer Woche mit Firefighting statt Feature-Entwicklung verbringen, SLA-Credits, die Margen auffressen, und – in der EU unter NIS2 – potenzielle regulatorische Sanktionen, wenn Vorfälle nicht innerhalb der vorgegebenen Fristen erkannt und gemeldet werden. NIS2 verlangt von Einrichtungen in wesentlichen und wichtigen Sektoren, ihr nationales CSIRT (in Deutschland das BSI) innerhalb von 24 Stunden nach Kenntnis eines erheblichen Sicherheitsvorfalls zu benachrichtigen. Sie können nicht erkennen, was Sie nicht sehen.

Die drei Säulen des Cloud-Monitorings

Infrastructure Monitoring

Das Fundament: Compute (CPU, Memory, Disk I/O), Storage (Throughput, IOPS, Latenz) und die darunterliegende Plattform-Health (Hypervisor, Container Runtime, Serverless Execution Environment). Jeder Cloud-Provider stellt diese Daten nativ bereit:

• AWS CloudWatch – Metriken für EC2, RDS, EBS, Lambda sowie Custom Metrics über den CloudWatch Agent oder StatsD
• Azure Monitor – Plattform-Metriken werden automatisch für alle Azure-Ressourcen erfasst, mit Log Analytics Workspace für tiefergehende Abfragen (KQL)
• GCP Cloud Monitoring (ehemals Stackdriver) – erfasst automatisch Metriken für Compute Engine, GKE, Cloud SQL und Cloud Functions

Die Falle hier: Durchschnittswerte betrachten. Eine CPU mit durchschnittlich 45 % sieht gesund aus, aber wenn sie alle 60 Sekunden für 10 Sekunden auf 98 % steigt, erleben Ihre Nutzer Queuing-Verzögerungen, die der Durchschnitt verschleiert. Überwachen Sie immer Perzentile (p95, p99) für Latenz- und Saturation-bezogene Metriken.

Application Performance Monitoring (APM)

APM instrumentiert Ihren Code, um Requests End-to-End über Microservices, Datenbanken, Caches und externe APIs zu tracen. Die Standard-Signale sind die RED-Metriken: Request Rate, Error Rate und Duration (Latenzverteilung).

OpenTelemetry hat sich als De-facto-Standard für Instrumentation etabliert. Es ist herstellerneutral, unterstützt Auto-Instrumentation in Java, Python, .NET, Go, Node.js und weiteren Sprachen und exportiert in jedes Backend – Datadog, Dynatrace, Grafana Tempo, AWS X-Ray, Azure Application Insights oder GCP Cloud Trace. Wenn Sie 2026 neu starten, instrumentieren Sie mit OpenTelemetry SDKs und wählen Ihr Backend separat. Das vermeidet Vendor Lock-in auf der Instrumentierungsebene – dem Teil, der am schwierigsten wieder zu entfernen ist.

Was operativ zählt: Distributed Traces, die zeigen, dass ein Checkout-Request 12 ms im API Gateway verbracht hat, 45 ms im Order-Service, 800 ms wartend auf eine Third-Party-Payment-API und 3 ms beim Schreiben in DynamoDB. Ohne diese Aufschlüsselung wissen Sie nur: „Der Checkout ist langsam."

Network Monitoring

Network Observability ist der blinde Fleck der meisten Cloud-Monitoring-Strategien. Innerhalb einer VPC stützen Sie sich auf Flow Logs (VPC Flow Logs bei AWS, NSG Flow Logs bei Azure, VPC Flow Logs bei GCP), um Traffic-Muster, verworfene Pakete und Cross-AZ-/Cross-Region-Datenvolumen zu erkennen.

Für Hybrid-Setups – Direct Connect, ExpressRoute, Cloud Interconnect – ist die Überwachung des Tunnel-Health, BGP-Session-Status sowie Jitter/Packet Loss über die Verbindung entscheidend. Ein degradierter Direct Connect Circuit taucht in Ihren Application Metrics nicht auf, bis sich die Latenz verdoppelt und Kunden anrufen.

Tools wie Kentik, ThousandEyes (jetzt Teil von Cisco) und die nativen Cloud-Network-Monitoring-Services decken dies gut ab. Wenn Ihre Umgebung Single-Cloud und einfach ist, genügen native Tools. Multi-Cloud oder Hybrid? Dann benötigen Sie eine dedizierte Network-Observability-Schicht.

Metriken, die in Produktion wirklich zählen

Nicht jede Metrik verdient einen Alert. Hier ist, was unser NOC priorisiert, geordnet nach operativem Wert:

Die USE-Methode (Utilization, Saturation, Errors) eignet sich hervorragend für Infrastruktur-Ressourcen. Die RED-Methode (Rate, Errors, Duration) eignet sich hervorragend für Services. Nutzen Sie beide. Sie ergänzen sich – USE sagt Ihnen etwas über die Maschine, RED über die Arbeit, die die Maschine verrichtet.

Tooling-Vergleich: Native vs. Third-Party

Native Cloud-Monitoring-Tools

Opsio-Einschätzung: Native Tools sind der richtige Startpunkt und bleiben unentbehrlich für ressourcenspezifische Metriken, die Third-Party-Tools nicht erfassen können (z. B. Lambda Concurrent Executions, Azure Service Bus Dead-Letter Counts). Wenn Sie jedoch Workloads über zwei oder mehr Provider betreiben – was laut Flexera's State of the Cloud die überwältigende Mehrheit der Unternehmen inzwischen tut –, benötigen Sie eine Cross-Cloud-Schicht.

Third-Party-Observability-Plattformen

• Datadog – Stärkste All-in-one-Lösung: Infrastructure, APM, Logs, Synthetic Monitoring, Security Signals und FinOps-Dashboards. Breiter Integrationskatalog. Nachteil: Die Kosten skalieren aggressiv mit Host-Anzahl und Custom-Metrics-Kardinalität.
• Dynatrace – KI-gestützte Root-Cause-Analyse (Davis AI) ist genuinely nützlich für komplexe Umgebungen. Starke Auto-Instrumentation für Java/.NET. Nachteil: Das Lizenzmodell kann intransparent sein.
• Grafana Cloud (LGTM Stack) – Grafana + Loki (Logs) + Tempo (Traces) + Mimir (Metriken). Open-Source-Kern mit Managed-Hosting-Option. Optimal für Teams, die Kontrolle wollen und Vendor Lock-in vermeiden möchten. Nachteil: Erfordert mehr operatives Know-how für Tuning und Betrieb.
• New Relic – Großzügiger Free Tier, verbrauchsbasierte Preisgestaltung. Gutes APM. Nachteil: Network Monitoring und Infrastruktur-Tiefe liegen hinter Datadog zurück.
• Elastic Observability – Basiert auf Elasticsearch. Stark, wenn Sie bereits ELK für Logging betreiben. Nachteil: Die Skalierung von Elasticsearch-Clustern für High-Cardinality-Metriken ist nicht trivial.

Für kostensensitive Teams bietet der Grafana-LGTM-Stack mit OpenTelemetry-Instrumentation das beste Verhältnis von Kontrolle zu Kosten. Für Teams, die Managed Everything wollen und bereit sind, dafür zu zahlen, sind Datadog oder Dynatrace die pragmatische Wahl.

Managed Cloud Services

Best Practices aus einem 24/7-NOC

Dies sind keine theoretischen Empfehlungen. Sie stammen aus Mustern, die wir über Hunderte überwachter Workloads hinweg beobachten.

1. SLOs definieren, bevor Sie Alerts definieren

Ein Alert ohne Service Level Objective ist Rauschen. Beginnen Sie damit, zu definieren, was „gesund" für jeden Service bedeutet – z. B. „99,9 % der Checkout-Requests werden innerhalb von 800 ms mit <0,1 % Error Rate abgeschlossen." Setzen Sie dann Alerts auf die Burn Rate dieses Error Budgets. Das SRE-Buch von Google hat diesen Ansatz formalisiert, und er funktioniert. Multi-Window-, Multi-Burn-Rate-Alerting (Fast Burn für Pages, Slow Burn für Tickets) reduziert Alert Fatigue drastisch.

2. Zentralisierung in eine einzige Observability-Pipeline

In Multi-Cloud-Umgebungen ist der größte Zeitfresser das Context-Switching zwischen drei verschiedenen Konsolen. Setzen Sie den OpenTelemetry Collector als herstellerneutralen Telemetry-Router ein: Er empfängt Metriken, Traces und Logs aus jeder Quelle und exportiert in Ihr gewähltes Backend. Das entkoppelt Instrumentierung von Storage und hält Ihnen alle Optionen offen.

3. Das Monitoring überwachen

Ihre Observability-Pipeline ist selbst Infrastruktur. Wenn Ihr Prometheus-Server keinen Speicherplatz mehr hat oder Ihr Datadog Agent still abstürzt, haben Sie einen blinden Fleck genau in dem Moment, in dem Sie Sichtbarkeit brauchen. Betreiben Sie einen leichtgewichtigen Heartbeat-/Canary-Check, der validiert, dass Ihr Monitoring-Stack Daten ingestiert. Wir führen alle 60 Sekunden Synthetic Checks durch, die eine bekannte Metrik pushen, und alertieren, wenn diese nicht innerhalb von 120 Sekunden ankommt.

4. Kosten mit Performance-Metriken korrelieren

Hier treffen Cloud FinOps und Performance Monitoring aufeinander. Eine Instanz mit 8 % CPU-Auslastung ist kein Performance-Problem – sie ist ein Kostenproblem. Eine Instanz mit 92 % CPU-Auslastung ist kein Kostenproblem – sie ist ein Zuverlässigkeitsrisiko. Beides im selben Dashboard sichtbar zu machen, ermöglicht Teams Right-Sizing-Entscheidungen mit vollständigem Kontext. AWS Compute Optimizer, Azure Advisor und GCP Recommender liefern native Right-Sizing-Vorschläge, aber ihnen fehlt der Application-Level-Kontext. Überlagern Sie sie mit Ihren APM-Daten für wirklich brauchbare Empfehlungen.

5. Logs strategisch aufbewahren

Jeden Debug-Log aus jedem Container auf ewig zu speichern, ist der schnelle Weg zu einer sechsstelligen Observability-Rechnung. Staffeln Sie Ihre Retention: Hot Storage (7–14 Tage) für operatives Troubleshooting, Warm Storage (30–90 Tage) für Trendanalysen und Cold-/Archiv-Storage für Compliance. Die DSGVO verlangt, dass personenbezogene Daten in Logs mit derselben Sorgfalt behandelt werden wie Daten in Datenbanken – maskieren oder pseudonymisieren Sie PII auf der Collection-Ebene, nicht erst nach der Ingestion. Die NIS2-Logging-Anforderungen für wesentliche Einrichtungen bedeuten zugleich, dass Sie nicht einfach alles nach 7 Tagen löschen können. Darüber hinaus sollten Sie die BSI-C5-Anforderungen berücksichtigen, die für Cloud-Dienste im öffentlichen Sektor und bei kritischen Infrastrukturen konkrete Vorgaben zur Protokollierung und Nachvollziehbarkeit machen. Entwerfen Sie Retention-Policies, die sowohl operativen als auch regulatorischen Anforderungen genügen.

6. Regional instrumentieren

Wenn Sie Nutzer sowohl in der EU als auch in Indien bedienen, überwachen Sie auch aus beiden Regionen. Ein Service, der gemessen aus eu-central-1 (Frankfurt) einwandfrei performt, kann beim Zugriff aus ap-south-1 (Mumbai) 400 ms zusätzliche Latenz aufweisen. Synthetic Monitoring mit Checkpoints in Frankfurt, Zürich, Mumbai und Bangalore liefert Ihnen die Wahrheit aus Nutzerperspektive. Opsios NOC führt Synthetic Checks aus mehreren Geographien durch, gerade weil regionale Degradation von einem einzelnen Standort aus unsichtbar ist.

Cloud Security

Monitoring in Hybrid- und Multi-Cloud-Umgebungen

Die meisten Unternehmen sind nicht Single-Cloud, unabhängig davon, was ihre offizielle Strategie besagt. Laut Flexera's State of the Cloud ist Multi-Cloud-Adoption seit mehreren aufeinanderfolgenden Jahren das dominierende Muster. Die Monitoring-Herausforderung vervielfacht sich: Metriken haben unterschiedliche Bezeichnungen, unterschiedliche Granularitäten und unterschiedliche APIs über die Provider hinweg.

Praktische Multi-Cloud-Monitoring-Architektur

1. Collection Layer: Deployen Sie OpenTelemetry Collectors in jeder Umgebung (AWS, Azure, GCP, On-Premises). Konfigurieren Sie sie zur Normalisierung von Metrik-Namen und zum Hinzufügen von Cloud-Provider-Tags.

2. Aggregation Layer: Routen Sie alle Telemetriedaten in ein zentrales Backend – Datadog, Grafana Cloud oder einen selbst gehosteten Mimir/Loki/Tempo-Stack.

3. Correlation Layer: Nutzen Sie Service Maps und Dependency Graphs, die Provider-übergreifend arbeiten. Ein Request kann bei einem Azure Front Door CDN starten, eine API auf AWS EKS ansprechen und eine Datenbank auf GCP Cloud SQL abfragen. Ohne einen Cross-Cloud-Trace finden Sie den Bottleneck nie.

4. Alerting Layer: Zentralisiertes Alerting mit PagerDuty, Opsgenie oder Grafana OnCall als einzigem Routing-Punkt. Vermeiden Sie Cloud-native Alerting-Silos – eine Azure Action Group, die ein Team paged, während ein CloudWatch Alarm ein anderes paged, führt zu doppeltem Aufwand und verpassten Korrelationen.

Hybrid-Cloud-Spezifika

Für Workloads, die On-Premises und Cloud umspannen (verbreitet in Fertigung, Gesundheitswesen und öffentlicher Verwaltung), überwachen Sie den Interconnect als erstklassige Komponente. Direct Connect, ExpressRoute und Cloud Interconnect haben SLAs, aber diese SLAs decken nicht die Empfindlichkeit Ihrer Anwendung gegenüber Jitter ab. Implementieren Sie bidirektionale Latenz-Probes über die Verbindung und alertieren Sie bei Degradation, bevor sie realen Traffic beeinträchtigt.

Cloud Migration

Compliance und Datenresidenz

EU: NIS2, DSGVO und BSI C5

Die NIS2-Richtlinie, durchsetzbar seit Oktober 2024 und in Deutschland durch das NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) in nationales Recht überführt, verpflichtet Einrichtungen in wesentlichen und wichtigen Sektoren zur Umsetzung angemessener Risikomanagement-Maßnahmen – wozu ausdrücklich Monitoring- und Incident-Detection-Fähigkeiten gehören. Ihre Monitoring-Architektur ist auditierbar. Wenn Sie nicht nachweisen können, dass Sie Sichtbarkeit in den Vorfall hatten, wird das regulatorische Gespräch deutlich schwieriger.

Die DSGVO schränkt ein, wo Monitoring-Daten gespeichert und verarbeitet werden dürfen. Wenn Ihre Anwendungslogs IP-Adressen, User-IDs oder Session-Tokens enthalten, handelt es sich um personenbezogene Daten im Sinne der DSGVO. Der Versand an einen in den USA gehosteten SaaS-Dienst ohne geeignete Transfermechanismen (SCCs, Angemessenheitsbeschlüsse) ist ein Compliance-Risiko – insbesondere im Lichte der Schrems-II-Rechtsprechung des EuGH. Wählen Sie Monitoring-Backends, die EU-basierte Datenverarbeitung anbieten, oder betreiben Sie Self-Hosting innerhalb von EU-Regionen. Grafana Cloud bietet EU-dedizierte Cluster; Datadog bietet den EU1-Standort (Frankfurt).

Für Organisationen, die Cloud-Dienste im öffentlichen Sektor oder für kritische Infrastrukturen in Deutschland nutzen, ist darüber hinaus der BSI C5 (Cloud Computing Compliance Criteria Catalogue) relevant. C5 definiert konkrete Anforderungen an Logging, Monitoring und Nachvollziehbarkeit, die Ihr Observability-Stack erfüllen muss. Stellen Sie sicher, dass Ihre Monitoring-Architektur die C5-Kriterien für Protokollierung und Auditierbarkeit berücksichtigt.

Indien: DPDPA 2023

Der Digital Personal Data Protection Act (DPDPA) 2023 führt einwilligungsbasierte Datenverarbeitungspflichten und Datenlokalisierungsanforderungen für bestimmte Kategorien ein. Monitoring-Daten, die personenbezogene Identifikatoren indischer Betroffener enthalten, müssen mit Sorgfalt behandelt werden. Die praktische Auswirkung: Wenn Sie nutzerseitige Anwendungen überwachen, die indische Kunden bedienen, stellen Sie sicher, dass Ihre Log-Masking-Pipeline personenbezogene Daten entfernt oder pseudonymisiert, bevor diese die Collection-Ebene verlassen.

Managed DevOps

Cloud Monitoring einführen: Ein praktischer Einstiegspfad

Für Teams, die am Anfang ihrer Monitoring-Reife stehen, hier eine konkrete Abfolge – kein Boil-the-Ocean-Ansatz:

Woche 1–2: Aktivieren Sie natives Monitoring für alle Cloud-Ressourcen. Schalten Sie CloudWatch Detailed Monitoring (1-Minuten-Intervalle), Azure Monitor Diagnostics oder GCP Cloud Monitoring ein. Das ist in der Regel ein Terraform-/Bicep-/Config-Connector-Einzeiler pro Ressource.

Woche 3–4: Instrumentieren Sie Ihre drei kritischsten Services mit OpenTelemetry. Deployen Sie den OTel Collector als Sidecar (Kubernetes) oder Daemon (EC2/VM). Exportieren Sie Traces und Metriken in Ihr gewähltes Backend.

Monat 2: Definieren Sie SLOs für diese drei Services. Implementieren Sie Error-Budget-basiertes Alerting. Verbinden Sie Alerts mit PagerDuty oder Opsgenie mit On-Call-Rotations.

Monat 3: Ergänzen Sie Synthetic Monitoring von mindestens zwei geographischen Standorten (z. B. eu-central-1 Frankfurt und eu-central-2 Zürich). Erstellen Sie Baseline-Dashboards. Beginnen Sie mit der Log-Zentralisierung mit Retention-Stufen.

Fortlaufend: Erweitern Sie die Instrumentierung auf die übrigen Services. Ergänzen Sie Network Monitoring. Integrieren Sie Kostendaten. Überprüfen und justieren Sie Alert-Schwellenwerte vierteljährlich – veraltete Schwellenwerte sind schlimmer als keine, weil sie Teams dazu erziehen, Alerts zu ignorieren.

Virtual Machine Monitors und Cloud Performance

Ein Virtual Machine Monitor (VMM), auch Hypervisor genannt, ist die Software-Schicht, die die Zuweisung physischer Ressourcen – CPU, Memory, Storage, Netzwerk – an virtuelle Maschinen verwaltet. Im Cloud Computing ist der Hypervisor (AWS Nitro, Azure Hyper-V, Googles Custom KVM) das Fundament, das Multi-Tenancy ermöglicht. Aus Monitoring-Perspektive interagieren Sie auf der Public Cloud selten direkt mit dem Hypervisor – der Provider abstrahiert ihn. Aber Sie beobachten seine Auswirkungen: „Steal Time" auf einer Linux-Instanz (die %steal-Metrik in top oder sar) zeigt an, dass der Hypervisor CPU-Zyklen an andere Tenants zuweist. Wenn die Steal Time dauerhaft 5–10 % übersteigt, erleben Sie Noisy-Neighbor-Effekte und sollten Dedicated oder Bare-Metal-Instanzen in Betracht ziehen.

Cloud Logging vs. Cloud Monitoring: Die Beziehung klären

Logging und Monitoring sind unterschiedliche, aber voneinander abhängige Disziplinen. Monitoring beantwortet „Ist gerade etwas kaputt?" durch Echtzeit-Metriken und Alerts. Logging beantwortet „Was genau ist passiert?" durch diskrete Event-Datensätze. Traces ergänzen die dritte Dimension: „Wie hat der Request das System durchlaufen?"

Der moderne Begriff „Observability" vereint alle drei – Metriken, Logs und Traces – zu einer kohärenten Praxis. In Tooling-Begriffen: CloudWatch Metrics + CloudWatch Logs + X-Ray; Azure Monitor Metrics + Log Analytics + Application Insights; GCP Cloud Monitoring + Cloud Logging + Cloud Trace. Oder mit Third-Party-Stacks: Datadog Infrastructure + Logs + APM; Grafana Mimir + Loki + Tempo.

Der praktische Rat: Bauen Sie Logging und Monitoring nicht als separate Projekte mit separaten Teams auf. Sie teilen sich Infrastruktur, teilen Kontext und werden bei jedem Incident gemeinsam abgefragt.

Häufig gestellte Fragen

Wie misst man Cloud-Performance?

Cloud-Performance wird mit der RED-Methode (Rate, Errors, Duration) für Services und der USE-Methode (Utilization, Saturation, Errors) für Infrastruktur gemessen. Instrumentieren Sie Anwendungen mit Distributed Tracing (OpenTelemetry), erfassen Sie Infrastruktur-Metriken über native Cloud-Agenten und definieren Sie Baselines für p95-Latenz, Error Rate und Availability. Synthetic Monitoring ergänzt eine Outside-In-Validierung, dass echte Nutzer Ihre Endpunkte innerhalb der SLA-Schwellenwerte erreichen.

Was sind die drei Bereiche des Cloud-Monitorings?

Die drei Bereiche sind Infrastructure Monitoring (Compute, Storage, Netzwerk-Health), Application Performance Monitoring (Transaction Traces, Error Rates, Response Times) und Log Management/Analytics (zentrale Log-Aggregation, Suche und Alerting). Manche Frameworks ergänzen einen vierten Bereich – Security Monitoring –, in der Praxis fließen Security-Signale jedoch in dieselbe Observability-Pipeline ein.

Was ist die 3-4-5-Regel im Cloud Computing?

Die 3-4-5-Regel ist eine Backup- und Disaster-Recovery-Heuristik: Halten Sie 3 Kopien Ihrer Daten vor, auf 4 verschiedenen Speichermedientypen, wobei 5 dieser Kopien off-site oder in einer anderen Region gespeichert werden. Obwohl ursprünglich eine Datenschutz-Richtlinie, beeinflusst sie direkt das Monitoring-Design, da Sie Replication Health, RPO-Compliance und regionale Failover-Bereitschaft kontinuierlich verifizieren müssen.

Welche fünf Monitoring-Typen gibt es?

Die fünf üblicherweise genannten Typen sind: Infrastructure Monitoring, Application Performance Monitoring (APM), Network Monitoring, Security Monitoring (SIEM/SOC) und Real-User-/Synthetic Monitoring. Im Cloud-Kontext überlappen diese stark – ein Latenz-Spike kann ein Netzwerkproblem, ein Anwendungsfehler oder ein Noisy-Neighbor-Problem auf geteilter Infrastruktur sein –, weshalb Unified-Observability-Plattformen isolierte Tools zunehmend ablösen.

Was ist der Unterschied zwischen Cloud Logging und Cloud Monitoring?

Monitoring erfasst Zeitreihen-Metriken (CPU, Latenz, Error Counts) und löst Alerts bei Schwellenwertüberschreitungen aus. Logging erfasst diskrete Event-Datensätze – Anwendungsfehler, Access Logs, Audit Trails –, die nachträglich abgefragt werden. In der Praxis sind beide komplementär: Ein Alert wird durch eine Monitoring-Metrik ausgelöst, und Engineers wechseln zu den Logs, um die Root Cause zu diagnostizieren. Moderne Observability vereint Metriken, Logs und Traces in einem einzigen Workflow.