AWS Monitoring für EC2, EKS, RDS, S3 und mehr
Erfassen Sie CloudWatch-Metriken von 300+ AWS-Services ohne Agent, ergänzen Sie Host- und Trace-Daten per Obseria Agent und OpenTelemetry und sehen Sie Kosten direkt neben der Performance.
Warum AWS mit Obseria überwachen
Agentenlos in Minuten
Verbinden Sie ein AWS-Konto über eine IAM-Rolle mit Leserechten, und CloudWatch-Metriken für 300+ Services fließen Region für Region ein.
Mehr als CloudWatch
Kombinieren Sie CloudWatch mit OpenTelemetry-Traces, Logs und Host-Metriken des Obseria Agent. So sehen Sie, warum ein Service langsam ist, nicht nur dass er es ist.
Kosten im Kontext
Stellen Sie AWS-Abrechnungsdaten neben Auslastung und Traffic, damit überdimensionierte Instanzen und ungenutzte Ressourcen dort auffallen, wo Ihr Team ohnehin hinschaut.
AWS-Services, die Obseria überwacht
- Amazon EC2. CPU, Netzwerk, Disk und Status-Checks pro Instanz, mit dem Obseria Agent zusätzlich Details auf Prozessebene.
- Amazon EKS. Zustand von Cluster, Nodes, Pods und Containern über das DaemonSet des Obseria Agent und die Control-Plane-Metriken.
- Amazon RDS und Aurora. Verbindungen, Latenz, IOPS, Replica Lag und freier Speicher für jede Engine.
- Amazon S3. Bucket-Größe, Objektanzahl, Request-Raten sowie 4xx- und 5xx-Fehler.
- Elastic Load Balancing. Requests, Target Response Time, gesunde Hosts und Fehlercodes für ALB und NLB.
- CloudWatch und AWS Billing. Metriken und Logs aus jedem CloudWatch-Namespace sowie geschätzte Kosten für die Kostenüberwachung.
Die AWS-Kennzahlen, auf die es ankommt
Obseria erfasst diese Werte automatisch und zeigt sie in fertigen Dashboards und Alerts.Zustand der Server
Zeigt, ob Ihre Server rund laufen oder überlastet sind, damit Probleme auffallen, bevor Ihre Kunden sie bemerken.
Leistung der Datenbanken
Macht sichtbar, ob Ihre Datenbanken schnell antworten, genug Platz haben und die aktuelle Zahl an Nutzern verkraften.
Erlebnis Ihrer Kunden
Zeigt, wie schnell Ihre Website und Dienste reagieren und wie oft Besucher auf Fehler statt auf Ergebnisse stoßen.
Speicher und Kosten
Behält das Wachstum Ihres Cloud-Speichers und die erwartete Monatsrechnung im Blick, damit Kostensprünge früh auffallen.
Alle 9 Metriken im Detail anzeigen
| Metrik | Einheit | Aussage |
|---|---|---|
AWS/EC2 CPUUtilization | Percent | Anteil der genutzten vCPU; dauerhaft hohe Werte deuten auf zu kleine Instanzen hin. |
AWS/EC2 StatusCheckFailed | Count | Fehlgeschlagene Instanz- oder System-Checks, ein frühes Signal für Host- oder OS-Probleme. |
AWS/RDS DatabaseConnections | Count | Offene Client-Verbindungen; Spitzen kündigen oft erschöpfte Verbindungspools an. |
AWS/RDS ReadLatency | Seconds | Durchschnittliche Dauer pro Lese-I/O auf der Datenbankinstanz. |
AWS/RDS FreeStorageSpace | Bytes | Verbleibender Speicher; alarmieren Sie lange bevor das Volume voll ist. |
AWS/ApplicationELB TargetResponseTime | Seconds | Zeit vom Weiterleiten des Requests durch den Load Balancer bis zur Antwort des Targets. |
AWS/ApplicationELB HTTPCode_Target_5XX_Count | Count | Serverfehler, die Ihre Targets hinter dem ALB zurückgeben. |
AWS/S3 BucketSizeBytes | Bytes | Tägliche Speichergröße pro Bucket und Storage-Klasse. |
AWS/Billing EstimatedCharges | USD | Geschätzte Kosten seit Monatsbeginn pro Konto und Service. |
AWS-Monitoring in wenigen Minuten einrichten
- Schritt 1
IAM-Rolle mit Leserechten anlegen
Legen Sie eine IAM-Rolle an, die Obseria übernehmen darf, mit Trust Policy für kontoübergreifenden Zugriff und einer Read-only-Policy wie ReadOnlyAccess oder CloudWatchReadOnlyAccess.
- Schritt 2
Konto und Regionen verbinden
Tragen Sie die Rollen-ARN in Obseria ein, wählen Sie Regionen und Services, und das agentenlose Abfragen von CloudWatch-Metriken und Tags beginnt.
- Schritt 3
Tiefe ergänzen, wo sie zählt
Installieren Sie den Obseria Agent auf EC2 oder als DaemonSet auf EKS und richten Sie OpenTelemetry SDKs für Traces auf Ihren OTLP-Endpunkt aus.
# Rolle anlegen, die Obseria übernehmen darf (trust.json enthält die Trust Policy)
aws iam create-role \
--role-name ObseriaReadOnly \
--assume-role-policy-document file://trust.json
# Lesezugriff auf CloudWatch-Metriken, Tags und Ressourcen-Metadaten
aws iam attach-role-policy \
--role-name ObseriaReadOnly \
--policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess
# Rollen-ARN ausgeben und in Obseria eintragen
aws iam get-role --role-name ObseriaReadOnly --query 'Role.Arn' --output textSofort einsatzbereit
Dashboards, Alerts und SLOs, die bereitstehen, sobald die ersten Daten ankommen.
- AWS-Kontoübersicht nach Region und Service
- EC2-Flotte: Zustand und Rightsizing-Kandidaten
- RDS-Performance und Speicherprognose
- Alerts für ALB-Latenz und 5xx-Fehlerrate
- AWS-Kostentrend mit Anomalie-Alerts
AWS-Monitoring: Darauf kommt es an
Warum AWS Monitoring mehr braucht als die Konsole
AWS Monitoring beginnt mit CloudWatch, das für fast jeden Managed Service Metriken veröffentlicht. Das ist eine solide Basis, doch die meisten Produktionsvorfälle überschreiten Servicegrenzen: Eine langsame RDS-Abfrage erhöht die Antwortzeit am ALB, das löst Autoscaling auf EC2 aus, und das treibt die Kosten. In der Konsole liegen diese Signale in getrennten Namespaces, Regionen und Konten. Echte AWS Observability bedeutet, sie miteinander und mit dem Anwendungscode darüber zu korrelieren.
Hinzu kommt die Skalierung über viele Konten und Regionen. Ohne zentrale Sicht wechseln Ihre Bereitschaftsteams während eines Incidents zwischen Konsolen. Eine Plattform, die CloudWatch-Metriken, Logs, Traces und Abrechnungsdaten zusammenführt, verkürzt den Weg vom Alert zur Ursache.
Die AWS-Metriken, auf die es ankommt
Jeder Service liefert Dutzende Metriken, doch wenige tragen den Großteil der Aussagekraft. Wenden Sie die Golden Signals pro Schicht an:
- Compute (EC2, EKS):
CPUUtilization, Netzwerk ein und aus,StatusCheckFailedsowie für EKS CPU, Speicher und Restarts von Nodes und Pods. Die CloudWatch-Basismetriken enthalten für EC2 keine Speicherdaten; diese Lücke schließt der Obseria Agent. - Datenbanken (RDS, Aurora):
DatabaseConnections,ReadLatencyundWriteLatency,FreeStorageSpace,ReplicaLagundCPUUtilization. - Traffic (ELB):
RequestCount,TargetResponseTime,HTTPCode_Target_5XX_CountundUnHealthyHostCount. Zusammen ergeben sie Rate, Fehler und Dauer am Edge. - Storage (S3): täglich
BucketSizeBytesundNumberOfObjects, dazu Request-Metriken wie5xxErrors, sofern im Bucket aktiviert. - Kosten:
EstimatedChargesaus dem Billing-Namespace, aufgeschlüsselt nach Service und verknüpftem Konto.
Typische AWS-Probleme und wie Sie sie erkennen
Überlastete Datenbanken. Steigende DatabaseConnections bei gleichbleibendem Traffic weisen meist auf Verbindungslecks oder fehlendes Pooling hin. Mit Trace-Daten finden Sie den Service, der Verbindungen offen hält.
Ungesunde Targets. Ein wachsender UnHealthyHostCount in einer ALB-Zielgruppe folgt oft auf ein fehlerhaftes Deployment. Die Korrelation mit Deployment-Events und EC2-Status-Checks trennt Anwendungsfehler von Infrastrukturproblemen.
Voller Speicher. RDS-Volumes und EBS-Disks füllen sich langsam und fallen dann plötzlich aus. Prognosebasierte Alerts auf FreeStorageSpace warnen Tage statt Minuten im Voraus.
Kostenüberraschungen. Vergessene Testumgebungen, überdimensionierte Instanzen und viel Traffic zwischen Availability Zones zeigen sich als Kostendrift, lange bevor die Rechnung kommt. Anomalieerkennung auf Abrechnungsmetriken fängt das früh ab.
Pod-Churn auf EKS. Pods in CrashLoopBackOff oder wegen Speicherdruck verdrängte Pods sind in CloudWatch allein kaum sichtbar. Node- und Container-Metriken des Obseria Agent zeigen zusammen mit Kubernetes-Events, welcher Workload auf welcher Node-Gruppe ausfällt und seit wann.
Best Practices für AWS Monitoring
- Taggen Sie konsistent (Team, Service, Umgebung) und nutzen Sie diese Tags als Dimensionen in Dashboards und Alerts.
- Überwachen Sie alle Konten und Regionen zentral, nicht nur die Produktion in Ihrer Hauptregion.
- Alarmieren Sie auf Symptome, die Nutzer spüren, etwa Latenz und Fehlerrate, und nutzen Sie Ressourcenmetriken zur Diagnose.
- Wählen Sie nur die CloudWatch-Namespaces, die Sie wirklich brauchen, um API-Nutzung und Rauschen gering zu halten.
- Instrumentieren Sie Anwendungen mit OpenTelemetry, damit Traces AWS-Ressourcen mit den Codepfaden verbinden, die sie nutzen.
So überwacht Obseria AWS
Obseria verbindet sich agentenlos über eine IAM-Rolle mit Leserechten und erfasst CloudWatch-Metriken und Ressourcen-Tags für 300+ Services. Der Obseria Agent ergänzt Host-, Prozess- und Log-Daten auf EC2 und läuft als DaemonSet auf EKS. OpenTelemetry-Traces kommen per OTLP an. Obseria TopoGraph bildet die Abhängigkeiten automatisch ab, vom Load Balancer über den Service bis zur Datenbank, und Obseria Intelligence nutzt diese Topologie für Root-Cause-Analysen mit nachvollziehbarer Beweiskette. Dashboards, Alerts und SLOs sind enthalten, abfragen können Sie alles mit OQL, PromQL oder SQL.
CloudWatch Logs und VPC Flow Logs lassen sich durch Obseria Pipeline leiten. Die Pipeline filtert verrauschte Einträge, maskiert personenbezogene Daten und leitet jeden Stream vor der Speicherung in die passende Aufbewahrung. Gefilterte Daten kosten nur die Ingestion. So bleiben Debug-Details verfügbar, ohne dass Sie für die Speicherung aller Daten bezahlen. Für regulierte Umgebungen wählen Sie die Datenresidenz in der EU, im Vereinigten Königreich oder im eigenen Cloud-Konto.
Verwandte Integrationen
Passende Funktionen
Cloud Monitoring
Überwachen Sie über 300 Cloud-Services agentenlos und sehen Sie, wie sie Ihre Anwendungen beeinflussen. Eine Plattform für Multi-Cloud-Metriken, Logs, Traces und Topologie.
Mehr erfahrenCloud-Kostenmanagement
Sehen Sie, was jedes Team, jeder Service und jeder Kubernetes-Namespace kostet, direkt neben den Performance-Daten, die es erklären. FinOps, mit dem Engineers arbeiten können.
Mehr erfahrenKubernetes Monitoring
Sehen Sie jeden Cluster, Node, Pod und Workload im Kontext. Obseria verknüpft Metriken, Events, Logs und Traces, damit Sie die Ursache eines fehlerhaften Rollouts in Minuten finden.
Mehr erfahrenMehr erfahren
Was ist Observability?
Was ist Observability? Wie Metriken, Logs, Traces und Profile Ihre Systeme verständlich machen und was Observability vom Monitoring unterscheidet.
Die vier Golden Signals: Latenz, Traffic, Fehler und Sättigung
Die vier Golden Signals erklärt: Latenz, Traffic, Fehler und Sättigung, der Bezug zu RED- und USE-Methode und die Messung mit OpenTelemetry.
Häufige Fragen zum AWS-Monitoring
Nein. CloudWatch-Metriken für 300+ AWS-Services werden agentenlos über eine IAM-Rolle mit Leserechten erfasst. Der Obseria Agent ist optional und ergänzt auf EC2 und EKS Speicher-, Prozess-, Log- und Trace-Kontext.
Leserechte genügen. Die meisten Teams hängen die AWS-Managed-Policy ReadOnlyAccess an oder eine engere Policy mit Rechten für CloudWatch, Tagging und Describe-Aufrufe.
Ja. Verbinden Sie jedes Konto mit einer eigenen Rolle und wählen Sie die Regionen aus. Alle Daten landen an einem Ort und lassen sich nach Konto, Region und Tag filtern.
Obseria übernimmt Abrechnungsmetriken wie EstimatedCharges und zeigt sie neben der Auslastung an, sodass Sie ungenutzte oder überdimensionierte Ressourcen erkennen. Anomalieerkennung meldet unerwartete Kostenänderungen.
Ja. Senden Sie Traces, Metriken und Logs aus OpenTelemetry SDKs oder dem OpenTelemetry Collector per OTLP. Sie können Ihre Daten jederzeit per OTLP exportieren, es gibt also keinen Lock-in.
Starten Sie heute mit dem AWS-Monitoring
Binden Sie AWS in Minuten per OpenTelemetry oder Obseria Agent an. 14 Tage kostenlos.