Google Cloud Monitoring für GKE, Cloud Run, Cloud SQL und Pub/Sub
Erfassen Sie Cloud-Monitoring-Metriken aus allen GCP-Projekten ohne Agent, ergänzen Sie Kubernetes- und Host-Daten per Obseria Agent und verfolgen Sie Requests mit OpenTelemetry über Services hinweg.
Warum Google Cloud mit Obseria überwachen
Alle Projekte an einem Ort
Verbinden Sie GCP-Projekte über ein Service-Konto mit Leserechten und sehen Sie Compute Engine, GKE, Cloud Run, Cloud SQL und Pub/Sub gemeinsam.
OpenTelemetry-nativ
Google-Cloud-Services und Client-Bibliotheken unterstützen OpenTelemetry gut; Obseria übernimmt OTLP-Traces, Metriken und Logs unverändert.
Vom Backlog zur Ursache
Verknüpfen Sie einen wachsenden Pub/Sub-Backlog oder eine langsame Cloud-SQL-Abfrage per Topologie und Traces mit dem verursachenden Service und Deployment.
Google-Cloud-Services, die Obseria überwacht
- Compute Engine. CPU, Disk, Netzwerk und Uptime pro Instanz und Managed Instance Group, mit dem Obseria Agent auch Prozesse.
- Google Kubernetes Engine (GKE). Metriken zu Cluster, Nodes, Pods und Containern für Standard- und Autopilot-Cluster.
- Cloud Run. Requests, Latenz, Instanzanzahl sowie CPU und Speicher der Container pro Service und Revision.
- Cloud SQL. CPU, Speicher, Disk, Verbindungen und Replikationsverzögerung für PostgreSQL, MySQL und SQL Server.
- Pub/Sub. Publish-Raten, nicht zugestellte Nachrichten und Alter der ältesten unbestätigten Nachricht pro Subscription.
- Cloud Monitoring und Cloud Logging. Metriken jedes Google-Cloud-Metriktyps sowie aus Cloud Logging weitergeleitete Logs.
Die Google Cloud-Kennzahlen, auf die es ankommt
Obseria erfasst diese Werte automatisch und zeigt sie in fertigen Dashboards und Alerts.Verfügbare Rechenkapazität
Zeigt, wie stark Ihre virtuellen Maschinen und Container ausgelastet sind, damit Engpässe rechtzeitig erkannt werden.
Tempo und Nachfrage
Zeigt, wie viele Anfragen Ihre Dienste bearbeiten, wie schnell sie antworten und wie weit sie dafür hochskalieren.
Auslastung der Datenbanken
Macht sichtbar, ob Ihre verwalteten Datenbanken entspannt arbeiten oder in Spitzenzeiten an ihre Grenzen kommen.
Rückstau bei Nachrichten
Zeigt, ob sich Nachrichten im Hintergrund stauen oder zu lange warten, was Bestellungen und Folgeprozesse verzögert.
Alle 9 Metriken im Detail anzeigen
| Metrik | Einheit | Aussage |
|---|---|---|
compute.googleapis.com/instance/cpu/utilization | Ratio | Anteil der genutzten CPU einer VM-Instanz. |
kubernetes.io/container/cpu/core_usage_time | s | Kumulierte CPU-Zeit eines Containers auf GKE. |
kubernetes.io/container/memory/used_bytes | Bytes | Speichernutzung eines Containers; im Vergleich zum Limit lassen sich OOM Kills vorhersehen. |
run.googleapis.com/request_count | Count | Von einer Cloud-Run-Revision bediente Requests, aufgeteilt nach Response-Code-Klasse. |
run.googleapis.com/request_latencies | ms | Verteilung der Request-Latenz pro Cloud-Run-Revision. |
run.googleapis.com/container/instance_count | Count | Laufende Container-Instanzen, hilfreich um Skalierungsgrenzen und Cold Starts zu erkennen. |
cloudsql.googleapis.com/database/cpu/utilization | Ratio | CPU-Auslastung der Cloud-SQL-Instanz. |
pubsub.googleapis.com/subscription/num_undelivered_messages | Count | Backlog unbestätigter Nachrichten in einer Subscription. |
pubsub.googleapis.com/subscription/oldest_unacked_message_age | s | Alter der ältesten unbestätigten Nachricht, das deutlichste Zeichen für einen hängenden Consumer. |
Google Cloud-Monitoring in wenigen Minuten einrichten
- Schritt 1
Service-Konto mit Leserechten anlegen
Legen Sie in jedem Projekt oder auf Ordnerebene ein Service-Konto an und vergeben Sie Monitoring Viewer, Compute Viewer und Cloud Asset Viewer.
- Schritt 2
Projekte in Obseria verbinden
Hinterlegen Sie die Zugangsdaten des Service-Kontos, wählen Sie Projekte und Services, und Cloud-Monitoring-Metriken fließen agentenlos ein.
- Schritt 3
GKE- und Trace-Tiefe ergänzen
Installieren Sie den Obseria Agent per Helm Chart auf GKE und richten Sie OpenTelemetry SDKs auf Cloud Run oder GKE auf Ihren OTLP-Endpunkt aus.
# Service-Konto für die agentenlose Erfassung
gcloud iam service-accounts create obseria-reader \
--display-name="Obseria read-only"
SA="obseria-reader@${PROJECT_ID}.iam.gserviceaccount.com"
# Lesezugriff auf Metriken, Instanzen und Asset-Metadaten
for ROLE in roles/monitoring.viewer roles/compute.viewer roles/cloudasset.viewer; do
gcloud projects add-iam-policy-binding "${PROJECT_ID}" \
--member="serviceAccount:${SA}" \
--role="${ROLE}"
doneSofort einsatzbereit
Dashboards, Alerts und SLOs, die bereitstehen, sobald die ersten Daten ankommen.
- GCP-Projektübersicht nach Service und Region
- Zustand von GKE-Clustern und Workloads
- Cloud Run: Latenz, Fehler und Skalierung
- Cloud-SQL-Performance und Replikationsverzögerung
- Alerts für Pub/Sub-Backlog und Nachrichtenalter
Google Cloud-Monitoring: Darauf kommt es an
Warum Google Cloud Monitoring über einzelne Services hinausgehen muss
Google Cloud Monitoring basiert auf Cloud Monitoring, das Tausende Metriktypen für Compute Engine, GKE, Cloud Run, Cloud SQL, Pub/Sub und den Rest der Plattform bereitstellt. Jede Metrik ist präzise, doch moderne GCP-Architekturen sind ereignisgesteuert und verteilt: Ein Cloud-Run-Service veröffentlicht in Pub/Sub, ein Worker auf GKE verarbeitet die Nachrichten und schreibt in Cloud SQL. Steigt die Latenz, kann die Ursache an jeder Stelle dieser Kette liegen.
GCP Observability bedeutet, diese Metriken projektübergreifend mit Traces und Logs Ihrer Services zu verbinden, damit Sie einen einzelnen Request oder eine Nachricht durch das System verfolgen können. Dazu gehört auch, GCP neben Workloads auf AWS, Azure oder im eigenen Rechenzentrum zu betrachten, denn kaum ein Unternehmen nutzt nur eine Cloud.
Die GCP-Metriken, auf die es ankommt
Nutzen Sie die Golden Signals pro Service und ergänzen Sie Sättigungsmetriken überall dort, wo Queues und Pools im Spiel sind:
- Compute Engine:
instance/cpu/utilization, Lese- und Schreiboperationen auf Disks, Netzwerk-Bytes und Uptime. Für Speicherwerte braucht es einen Gast-Agent, den der Obseria Agent bereitstellt. - GKE:
container/cpu/core_usage_time,container/memory/used_bytesim Vergleich zu den Limits, Container-Restarts und allokierbare Node-Ressourcen. - Cloud Run:
request_countnach Response-Code-Klasse, Perzentile vonrequest_latencies,container/instance_countsowie CPU- und Speicherauslastung der Container. - Cloud SQL:
database/cpu/utilization, Speicher- und Disk-Auslastung, Verbindungen wiedatabase/postgresql/num_backendsund Replica Lag. - Pub/Sub:
subscription/num_undelivered_messagesundsubscription/oldest_unacked_message_agesowie Publish- und Acknowledge-Raten.
Typische Google-Cloud-Probleme und wie Sie sie erkennen
Hängende Consumer. Steigt oldest_unacked_message_age stetig, während der Backlog wächst, fällt ein Subscriber aus oder ist zu langsam. Traces des Consumers zeigen, ob er auf einen nachgelagerten Aufruf wartet oder abstürzt.
Skalierungsgrenzen bei Cloud Run. Erreicht container/instance_count das konfigurierte Maximum, steigen Latenz sowie 429- und 503-Antworten. Cold Starts zeigen sich als lange erste Requests auf neuen Instanzen. Beides wird sichtbar, wenn Latenz und Instanzanzahl in einem Diagramm stehen.
Ausgelastetes Cloud SQL. Hohe CPU oder erschöpfte Verbindungen gehen oft auf eine neue Abfrage oder einen fehlenden Connection Pool in einem hochskalierten Cloud-Run-Service zurück. Datenbank-Spans nennen Abfrage und Aufrufer.
Ressourcendruck auf GKE. Container nahe am Speicherlimit werden per OOM Kill beendet und neu gestartet. Restart-Zähler, Speichernutzung im Verhältnis zum Limit und Kubernetes-Events identifizieren den Workload und helfen Ihnen, Requests und Limits oder die Autopilot-Ressourcen richtig einzustellen.
Quota- und Konfigurationsänderungen. Geänderte Quotas, IAM-Bindungen oder neue Revisionen gehen Incidents häufig voraus. Stehen Deployments und Revisionen auf derselben Zeitachse wie die Metriken, wird der Zusammenhang offensichtlich.
Best Practices für Google Cloud Monitoring
- Verwenden Sie einheitliche Labels für Team, Service und Umgebung und übernehmen Sie diese in Dashboards und Alerts.
- Verbinden Sie alle Projekte über IAM-Zuweisungen auf Ordnerebene, damit neue Projekte automatisch überwacht werden.
- Alarmieren Sie auf Latenz, Fehlerrate und Backlog-Alter, die Nutzer und nachgelagerte Systeme spüren, nicht nur auf CPU.
- Instrumentieren Sie Services mit OpenTelemetry und übertragen Sie den Trace-Kontext über Attribute der Pub/Sub-Nachrichten.
- Erfassen Sie Revisionen und Deployments als Events, um Regressionen mit Releases zu korrelieren.
So überwacht Obseria Google Cloud
Obseria verbindet sich agentenlos über ein Service-Konto mit Leserechten und erfasst Cloud-Monitoring-Metriken und Asset-Metadaten für Compute Engine, GKE, Cloud Run, Cloud SQL, Pub/Sub und weitere Services, als Teil von 300+ Cloud-Services über AWS, Azure und Google Cloud. Der Obseria Agent läuft als DaemonSet auf GKE und auf Compute-Engine-VMs, OpenTelemetry-Traces, Metriken und Logs kommen per OTLP an. Obseria TopoGraph bildet Services, Topics und Datenbanken automatisch ab, und Obseria Intelligence findet auf dieser Grundlage Ursachen mit einer nachvollziehbaren Beweiskette. Dashboards, Alerts und SLOs sind ohne Aufpreis enthalten.
Einträge aus Cloud Logging lassen sich über einen Log Sink an Obseria leiten und von Obseria Pipeline verarbeiten. Die Pipeline verwirft Rauschen, maskiert personenbezogene Daten und leitet jeden Stream in die passende Aufbewahrung. Da Obseria OTLP, PromQL und SQL unterstützt, behalten Teams, die bereits Managed Service for Prometheus oder OpenTelemetry auf GKE nutzen, ihre Instrumentierung und ihre Abfragen.
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 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 erfahrenServerless Monitoring
Verfolgen Sie jede Invocation über Functions, Queues und APIs hinweg. Obseria zeigt Cold Starts, Fehler, Laufzeit und Kosten Ihrer Serverless-Workloads im Kontext des Gesamtsystems.
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 Google Cloud-Monitoring
Nein. Cloud-Monitoring-Metriken werden agentenlos über ein Service-Konto mit Leserechten erfasst. Der Obseria Agent ist optional und ergänzt Host-, Kubernetes- und Log-Details auf Compute Engine und GKE.
Monitoring Viewer für Metriken, Compute Viewer für Instanz-Metadaten und Cloud Asset Viewer für die Ressourcenerkennung. Alle drei sind reine Leserollen.
Ja. Plattformmetriken von Autopilot-Clustern werden agentenlos erfasst, und OpenTelemetry Collectors oder SDKs im Cluster können zusätzliche Telemetrie per OTLP senden.
Binden Sie das OpenTelemetry SDK Ihrer Sprache ein und setzen Sie OTEL_SERVICE_NAME, OTEL_EXPORTER_OTLP_ENDPOINT und OTEL_EXPORTER_OTLP_HEADERS als Umgebungsvariablen des Service. Die Traces erscheinen dann innerhalb weniger Minuten.
Ja. Vergeben Sie die Rollen auf Ordner- oder Organisationsebene und wählen Sie die Projekte in Obseria aus. Die Daten aller Projekte lassen sich nach Projekt, Region und Label filtern.
Starten Sie heute mit dem Google Cloud-Monitoring
Binden Sie Google Cloud in Minuten per OpenTelemetry oder Obseria Agent an. 14 Tage kostenlos.