Was ist Cloud Monitoring?

Was ist Cloud Monitoring?

Cloud Monitoring ist die kontinuierliche Beobachtung von Workloads, Services und Managed Components, die auf einer Public Cloud (AWS, GCP, Azure, OCI) oder einem hybriden Mix aus Cloud und On-Prem laufen. Es zieht Metriken, Logs, Traces und Events aus Cloud-nativen Quellen (CloudWatch, Cloud Monitoring, Azure Monitor, EKS oder ECS Control Plane, RDS Performance Insights, S3 Request Metrics, ALB Access Logs, Lambda Invocations) und aus jedem Agent, den du auf VMs oder Container deployst, und zeigt das Ergebnis als Dashboards, Alerts und Incident Workflows.

Der Output hat dieselbe Form wie klassisches Monitoring (Charts, Alerts, On-Call Rotations), aber die Data Sources und die Unit of Work sind anders: ephemere Container statt langlebiger Hosts, Managed Services statt selbst betriebener Daemons, Per-Invocation Billing statt Fixed-Cost Server. Tools im Space sind Datadog, New Relic, Dynatrace, Grafana Cloud, AWS CloudWatch, Google Cloud Operations und Azure Monitor.

Cloud Monitoring vs On-Prem Monitoring vs APM

Die Disziplinen überlappen, aber die Datenform unterscheidet sich:

• Cloud Monitoring konsumiert Managed-Service-Metriken und ephemere Compute (Container, Functions). Die Unit of Work churnt pro Minute und Tags treiben Gruppierung (Account, Region, Service, Environment).
• On-Prem Monitoring überwacht fixe Hardware: Hosts, die seit Jahren in DNS stehen, Switches, Storage Arrays. Tooling wie Nagios, Zabbix oder PRTG zentriert sich auf SNMP und Per-Host-Installs.
• APM ist orthogonal zu beiden: es instrumentiert App-Code, egal wo er läuft, und reportet Per-Endpoint Latenz und Errors. Siehe Application Performance Monitoring für den Application Layer.

Die meisten Teams auf Cloud brauchen Cloud Monitoring für Infrastruktur und APM für den App-Code; der On-Prem-Pfad schrumpft, ist aber für regulierte Workloads weiter relevant.

Was Cloud Monitoring abdeckt

• Compute-Health: EC2/GCE/Azure VM CPU, Memory, Disk; ECS/EKS/GKE/AKS Container-Count, Restarts, Pending Pods.
• Managed-Service-Metriken: RDS Connections, ElastiCache Hit Rate, DynamoDB Throttles, S3 4xx/5xx, SQS Queue Depth, ALB Target Response Time.
• Serverless: Lambda Invocation Count, Duration, Errors, Throttles, Concurrent Executions; dasselbe für Cloud Functions und Azure Functions.
• Network und Edge: CloudFront Cache Hit Rate, NAT Gateway Bytes, VPC Flow Logs, Route 53 Query Volume.
• Cost-Signale: Per-Account Daily Spend, Unblended Cost nach Service oder Tag, Anomaly Alerts bei plötzlichem Daily-Spend-Sprung.
• Security und Audit: CloudTrail Events, GuardDuty Findings, IAM Access Analyzer; kein SIEM-Ersatz, aber die Early-Warning-Layer.

Wichtige Cloud-Monitoring-Metriken

1. Availability per Service: CloudWatch HealthyHostCount, ALB Target Health, RDS Instance State, aggregiert auf ein SLA-Target.
2. Latenz per Managed Component: RDS Query Latenz, ALB TargetResponseTime p50/p95/p99, S3 First-Byte Latenz.
3. Error Rate per Layer: ALB HTTPCode_Target_5XX_Count, Lambda Errors, RDS Deadlocks, SQS Dead-Letter Depth.
4. Saturation: CPU Credits Remaining auf Burstable Instances, RDS CPU und Connection Saturation, ElastiCache Evictions, Autoscaling Group Desired vs In-Service.
5. Throughput: Requests per Second per Service, Bytes per Second per Network Path, Messages per Minute durch SQS/SNS/Kinesis.
6. Cost-per-Request: Spend geteilt durch nützliche Arbeit, die Long-Term-Effizienz-Metrik, die die meisten Teams ignorieren, bis die Bill spikt.

Wie man Cloud Monitoring betreibt

Starte mit dem provider-nativen Metric Stream (CloudWatch Metric Streams zu Firehose, oder direktes API Polling für eine Cloud) und forwarde ihn zu einem zentralen Backend (Datadog, Grafana, eigenes Prometheus + Mimir). Tagge jede Resource konsistent (Service, Environment, Team, Cost-Center), damit dieselbe Dashboard-Query nach jeder Dimension sliced. Layere Logs (CloudWatch Logs oder Cloud Logging) und Traces (X-Ray, Cloud Trace, OpenTelemetry zum selben Backend) drauf. Wire Alerts zu PagerDuty oder Opsgenie mit On-Call-Rotations per Service. Prune periodisch Metriken, die kein Team ownt: Cloud-Monitoring-Bills wachsen schneller als die Infrastruktur.

Cloud Monitoring sitzt neben Load Testing in der Launch-Readiness-Pipeline. Run Load Testing oder Spike Testing von außerhalb des Cloud-Networks, beobachte die Cloud-Monitoring-Dashboards live und erfasse, welche Managed Component zuerst saturiert (DB Connections, Autoscaling Lag, Dead-Letter Queue Depth). Siehe auch Observability für das breitere Investigations-Framework, in das Cloud Monitoring einspeist.

Wenn dein Team production-shape Load Runs braucht, die sauber mit deinen Cloud-Monitoring-Dashboards korrelieren, bietet LoadFocus Load Testing Services mit Runs, die auf deine Dashboard-Fenster abgestimmt sind, und Summary Reports cross-referenziert mit deinen CloudWatch- oder Datadog-Screenshots.