Google PCD: Observability, Debugging und Site Reliability Operations — Lernleitfaden

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

Teil des Google Professional Cloud Developer — Lernleitfaden. Üben Sie mit verifizierten Antworten im Google-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Observability, Debugging und Site Reliability Operations in Google Cloud konzentrieren sich darauf, Systeme messbar, diagnostizierbar und resilient zu machen. Eine starke Observability erfordert konsistentes Logging und Metriken, verteiltes Tracing, handlungsrelevante Benachrichtigungen und eine disziplinierte Reaktion auf Vorfälle (Incident Response). Zuverlässigkeit erfordert Klarheit über Service-Level-Indikatoren und -Ziele, rigorose Zustandsignale und eine Feedback-Schleife, die Erkenntnisse aus der Produktion in technische Verbesserungen umwandelt. Dieser Abschnitt beschreibt, wie diese Fähigkeiten End-to-End in Google Cloud aufgebaut werden und wie man Kompromisse und häufige Fehlermodi abwägt.

Grundlagen von Logging und Monitoring

Cloud Logging

• Geben Sie strukturierte Logs aus. Bevorzugen Sie JSON mit stabilen Feldnamen, damit Abfragen und logbasierte Messwerte über Releases hinweg robust bleiben. Fügen Sie Schweregrad, Dienstname, Version, Standort und eine Anfrage-ID oder einen Trace-Kontext zur Korrelation hinzu.
• Korrelieren Sie Logs mit Traces, indem Sie folgende Felder setzen:
  • logging.googleapis.com/trace: projects/PROJECT_ID/traces/TRACE_ID
  • logging.googleapis.com/spanId: SPAN_ID
  • logging.googleapis.com/trace_sampled: true
• Buckets und Aufbewahrung. Der _Default-Bucket hat typischerweise eine Aufbewahrungsfrist von 30 Tagen (konfigurierbar). Der _Required-Bucket enthält bestimmte Audit-Logs mit einer längeren, festen Aufbewahrungsfrist. Erstellen Sie regionale Buckets, um die Datenresidenz zu steuern und benutzerdefinierte Aufbewahrungsfristen pro Bucket festzulegen.
• Senken. Leiten Sie Logs zur Analyse an BigQuery, für Streaming-Konsumenten an Pub/Sub oder zur Archivierung an Storage weiter. Verwenden Sie aggregierte Senken auf Ordner- oder Organisationsebene, um untergeordnete Projekte zu erfassen.
• Abfragen. Verwenden Sie die Logging-Abfragesprache, um nach resource.type, Labels, jsonPayload, httpRequest oder textPayload zu filtern.

Beispiele:

• Strukturierter Log-Eintrag (gekürzt): { “severity”: “ERROR”, “message”: “Checkout failed”, “service”: “payments”, “version”: “2026-09-01”, “user_id_hash”: “9c1…”, “labels”: {“tenant”:“gold”}, “logging.googleapis.com/trace”: “projects/myproj/traces/4bf92f3577b34da6a3ce929d0e0e4736”, “logging.googleapis.com/spanId”: “00f067aa0ba902b7” }
• Aufbewahrungsfrist aktualisieren:

undefined

• Eine BigQuery-Senke für Fehler-Logs erstellen:

undefined

• Letzte 5xx-Fehler für Cloud Run lesen:

undefined

Cloud Monitoring

• Messwerte. Verwenden Sie Google Cloud-Messwerte, benutzerdefinierte Messwerte und logbasierte Messwerte. Bevorzugen Sie Labels mit niedriger Kardinalität; eine explodierende Label-Kardinalität verursacht Kosten- und Abfragelatenzprobleme.
• Dashboards. Stellen Sie Dashboards pro Dienst und pro Abhängigkeit (Datenbank, Cache, Warteschlangen) zusammen. Visualisieren Sie RED- (Requests, Errors, Duration) und USE-Signale (Utilization, Saturation, Errors).
• Benachrichtigungsrichtlinien. Lösen Sie bei Schwellenwerten, dem Fehlen von Messwerten, Verhältnissen, SLO-Burn-Rates oder Fehlern bei Uptime-Prüfungen aus. Konfigurieren Sie Benachrichtigungskanäle (E-Mail, SMS, PagerDuty, Pub/Sub, Webhooks). Unterdrücken Sie „Flapping“ (schnell wechselnde Zustände) durch Windowing und Aligner.
• Uptime-Prüfungen. Führen Sie Sonden aus mehreren Regionen aus; verwenden Sie private Uptime-Prüfungen für interne Endpunkte oder führen Sie Synthetics innerhalb der VPC aus.

Logbasierte Messwerte

• Zähler fassen Vorkommnisse zusammen (z. B. die Anzahl der /api/alpha/*-Anfragen).
• Verteilungen erfassen Latenz oder Payload-Größen.
• Beispiel:

undefined

Betriebsanalysen

• Für Ad-hoc-Analysen leiten Sie Daten über eine Senke an BigQuery weiter; entwerfen Sie Schemata und Partitionierungen nach Zeitstempel, um die Kosten zu kontrollieren.
• Verwenden Sie Log Analytics in Logging-Buckets, um Daten gegebenenfalls ohne Export zu aggregieren.
• Erstellen Sie Kapazitätssignale aus Messwerten wie CPU, Arbeitsspeicher, Warteschlangentiefe, Cloud SQL-Verbindungen, Spanner-CPU mit hoher Priorität, nicht bestätigten Pub/Sub-Nachrichten und Cloud Storage 429/5xx-Raten.

Häufige Fallstricke und Kompromisse

• Übermäßiges Logging erhöht die Ingestion-Kosten und verschleiert das Signal; bevorzugen Sie Sampling und eine disziplinierte Verwendung von Schweregraden.
• Fehlende Korrelations-IDs erschweren die Incident-Triage; propagieren Sie Trace-IDs End-to-End.
• Lange Aufbewahrungsfristen in „heißen“ Buckets erhöhen die Kosten; exportieren Sie für langfristige Anforderungen in ein Archiv oder nach BigQuery.

Tracing, Fehler und Tiefendiagnose

Verteiltes Tracing

• Trace-Kontext. Bevorzugen Sie den W3C-Trace-Kontext (traceparent, tracestate). Für die Interoperabilität mit Cloud Trace unterstützen Sie weiterhin x-cloud-trace-context: x-cloud-trace-context: TRACE_ID/SPAN_ID;o=1
• Propagation. Leiten Sie Trace-Header über Services, Message Queues und asynchrone Grenzen hinweg weiter; erfassen Sie neue Child-Spans, wenn Sie RPCs oder SQL-Aufrufe tätigen. Ein Kontextverlust beeinträchtigt Service-Maps und führt zu einer Zunahme von „unknown service“-Knoten.
• Sampling. Wägen Sie Kosten und Genauigkeit ab; dynamisches Head-based Sampling am Ingress und Tail-based Sampling für seltene langsame Anfragen können die Nützlichkeit verbessern.

Cloud Trace

• Bietet Latenz-Histogramme, Span-Wasserfälle und Service-Maps. Verwenden Sie Annotationen für kritische Teiloperationen (RPCs, DB-Abfragen).
• Diagnostizieren Sie Ausreißer mithilfe von p95/p99-Traces; achten Sie auf Fan-Out, N+1-Abfragen oder Lock-Konflikte.
• Aktivieren Sie die Trace-Log-Korrelation, damit ein Klick auf einen Trace die zugehörigen Logs anzeigt.

Error Reporting

• Aggregiert Ausnahmen automatisch nach Stack-Signatur pro Service/Version. Konfigurieren Sie den Service-Kontext, um eine Vermischung zwischen Services zu vermeiden. Unterdrücken Sie bekannte, störanfällige Fehler oder leiten Sie sie an Benachrichtigungen mit niedrigerer Priorität weiter.
• Redigieren Sie personenbezogene Daten (PII) aus Ausnahmemeldungen; protokollieren Sie stattdessen stabile Fehlercodes und Korrelations-IDs.

Cloud Profiler

• Kontinuierliches CPU-/Heap-Profiling mit geringem Overhead für unterstützte Laufzeitumgebungen. Vergleichen Sie Profile zwischen Versionen und bei unterschiedlichen Traffic-Levels, um Regressionen zu erkennen. Vermeiden Sie es, Sampling-Artefakte als exakte Zählungen zu interpretieren.

Cloud Debugger

• Snapshots erfassen Variablen an einer Codestelle, ohne den Prozess anzuhalten. Logpoints fügen temporäre Logging-Anweisungen ein. Beschränken Sie den Zugriff, redigieren Sie sensible Variablen und begrenzen Sie den Geltungsbereich auf Ausdrücke ohne personenbezogene Daten (PII).

Kurzes Beispiel: W3C-Traceparent hinzufügen und ein Log korrelieren

• HTTP-Propagation: traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
• Log-Feld zur Verknüpfung mit Cloud Trace: “logging.googleapis.com/trace”: “projects/myproj/traces/4bf92f3577b34da6a3ce929d0e0e4736”

Reliability Engineering, Alerting und Zustandsignale

SLIs, SLOs, SLAs und Fehlerbudgets

• SLIs messen die Zufriedenheit der Nutzer: Verfügbarkeit, Latenz, Korrektheit. Definieren Sie sie pro kritischem Endpunkt und User Journey.
• SLOs setzen Ziele, z. B. 99,9 % der Anfragen unter 300 ms über 30 Tage.
• Fehlerbudgets quantifizieren die zulässige Unzuverlässigkeit. Verbrauchen Sie Budgets für Releases, Experimente oder Migrationen; frieren Sie Änderungen ein, wenn die Burn-Rate zu hoch ist.
• SLAs sind externe Verpflichtungen; halten Sie das SLO strenger als das SLA, um eine Marge zu sichern.

Design von qualitativ hochwertigen Alerts

• Bevorzugen Sie, wo möglich, SLO- und symptom-basierte Alerts gegenüber ursachenbasierten.
• Verwenden Sie Multi-Window-, Multi-Burn-Rate-Alerts (zum Beispiel 14x über 5 Minuten und 2x über 1 Stunde), um schnelle und langsame Verbräuche zu erfassen und gleichzeitig das Rauschen zu reduzieren.
• Fügen Sie Metrik-Abwesenheit für Watchdogs hinzu (z. B. Heartbeat eines langlaufenden Jobs).
• Leiten Sie nach Schweregrad weiter; begrenzen Sie die Rate der Benachrichtigungen; stellen Sie Links zu Runbooks und Dashboards bereit.

Health Checks und Probes

• Readiness Checks blockieren den Traffic, bis Abhängigkeiten bereit sind; Liveness Checks lösen Neustarts bei blockierten Prozessen aus; Startup Probes schützen langsam startende Prozesse vor vorzeitigen Neustarts.
• Erlauben Sie für VMs mit Load Balancing die Quellbereiche des Health Checkers, da der Traffic sonst die Backends nie erreicht: gcloud compute firewall-rules create allow-lb
  –network prod –allow tcp
  –source-ranges 130.211.0.0/22,35.191.0.0/16 –direction INGRESS
• Kubernetes-Beispiel: readinessProbe: httpGet: { path: /ready, port: 8080 } periodSeconds: 5 failureThreshold: 3 livenessProbe: httpGet: { path: /healthz, port: 8080 } initialDelaySeconds: 30 periodSeconds: 10
• Synthetisches Testen. Nutzen Sie Uptime Checks und maßgeschneiderte End-to-End-Abläufe über Cloud Scheduler + Cloud Run/Functions, um Login, Zahlungen oder andere kritische Pfade zu validieren.
• Abhängigkeits-Monitoring. Verfolgen Sie die Sättigung von Datenbankverbindungen, RPC-Fehlerquoten, Warteschlangen-Backlogs, Egress-Fehler und SLIs von Drittanbietern. Richten Sie Wiederholungsversuche mit Truncated Exponential Backoff für vorübergehende 429/5xx-Fehler ein, mit Idempotenz-Schlüsseln zur Sicherheit.

Incident Response, sicherheitsbewusstes Debugging und Ursachenanalyse

Incident-Response-Lebenszyklus

• Triage: Schweregrad einstufen, Incident Commander zuweisen und Rufbereitschaft über definierte Kanäle alarmieren.
• Eindämmen: Bekannte Gegenmaßnahmen und Traffic-Steuerungen anwenden (Rollback, Canary, Circuit Breaker, Ratenbegrenzer).
• Kommunizieren: Einen internen War-Room unterhalten, Stakeholder regelmäßig informieren und bei Bedarf einen für Benutzer sichtbaren Status veröffentlichen.
• Beheben und wiederherstellen: Systemzustand über SLIs verifizieren; voreilige Entwarnung vermeiden.
• Postmortem: Schuldfrei die Zeitachse, Erkennungslücken, begünstigende Faktoren und Action Items mit Verantwortlichen und Fälligkeitsdaten analysieren. Bis zum Abschluss nachverfolgen.

Runbooks

• Enthalten Auslöser, erforderlichen Kontext, Diagnosebefehle, sichere Gegenmaßnahmen, Rollback-Schritte und Eskalationspfade. Verlinken auf Dashboards, Logs und Playbooks für spezifische Fehlermodi.

Überwachung von Kontingenten und Kapazitäten

• Service-Kontingente über Metriken in Cloud Monitoring überwachen. Benachrichtigungen bei 70–80 % Auslastung automatisieren und Erhöhungen für geplante Lasttests oder Launches vorab beantragen.
• Zu überwachende Kapazitätssignale: CPU, Arbeitsspeicher, File Descriptors, Thread-Pools, DB-Verbindungen, Autoscaler-Limits und Tiefe der Anfrage-Warteschlange.

Debugging ohne Offenlegung sensibler Informationen

• Secrets und PII an der Quelle schwärzen; Secrets zentral in Secret Manager verwalten. Hashing oder Tokenisierung für Benutzerkennungen verwenden. Schwärzung auf Feldebene in der Logging-Middleware aktivieren.
• Zugriff auf Logs, Traces und Debug-Tools über IAM einschränken; gegebenenfalls CMEK und VPC Service Controls verwenden.
• In Debugger die Erfassung großer Objektgraphen deaktivieren und Bedingungen hinzufügen, um das Erfassen sensibler Frames zu vermeiden.

Ursachenanalyse über verschiedene Schichten hinweg

• Laufzeit: Spitzen bei GC, Thread-Pools oder CPU über Profiler mit der p99-Latenz in Trace korrelieren.
• Netzwerk: Load-Balancer-Logs, VPC Flow Logs, Firewall-Logs und Connectivity Tests prüfen, um Pfade zu validieren. Fehler bei Health-Checks resultieren häufig aus fehlenden Firewall-Regeln oder falschen Ports.
• IAM: Cloud Audit Logs auf Berechtigungsverweigerungen oder Richtlinienänderungen überprüfen; Rollen von Service Accounts und Token-Scopes bestätigen.
• Daten: Cloud SQL Insights, Spanner-Abfragestatistiken, Bigtable-CPU-Auslastung und Hot Tablets sowie Storage-Fehlerraten nutzen, um Hotspots zu finden.
• Wiederholungsversuche mit Backoff bei vorübergehenden Fehlern anwenden und Fan-Out reduzieren, der die Tail-Latenz verstärkt.
• Mit korrelierten Trace-IDs und logbasierten Metriken verknüpfen; nach BigQuery exportieren, um während der Post-Incident-Analyse Joins über mehrere Quellen auszuführen.

Praktisches Problemszenario

Fjord Retail migriert einen aus mehreren Services bestehenden Checkout zu Google Cloud und nutzt dabei Cloud Run, Cloud SQL, Pub/Sub und eine externe Steuer-API. Benutzer berichten von zeitweiligen Timeouts und sprunghaft ansteigenden Fehlerraten während Flash Sales, und die Rufbereitschaft erhält verrauschte, wenig aussagekräftige Alarme.

Vorgehensweise:

1. Strukturiertes Logging mit Trace-Korrelation instrumentieren

• W3C-Traceparent-Propagation über Services hinweg hinzufügen und logging.googleapis.com/trace in alle Logs aufnehmen. Begründung: Die End-to-End-Korrelation ermöglicht es Entwicklern, von einer langsamen Benutzeranfrage direkt zum exakten langsamen RPC oder zur langsamen Abfrage und den zugehörigen Logs zu wechseln.

2. Logging-Buckets, Aufbewahrungsfristen und Exporte erstellen

• Die Aufbewahrungsfrist von _Default auf 90 Tage erhöhen und einen regionalen Bucket für EU-Workloads erstellen. Einen aggregierten Sink nach BigQuery für ERROR- und WARNING-Logs hinzufügen: gcloud logging sinks create bq-prod
  bigquery.googleapis.com/projects/fjord/datasets/ops_logs
  –log-filter=‘severity>=WARNING’ –include-children Begründung: Eine ausreichende Hot-Storage-Aufbewahrung unterstützt das Debugging; BigQuery ermöglicht schnelle Analysen bei Störfällen, ohne die Kosten für Hot Storage zu erhöhen.

3. SLIs/SLOs und SLO-basiertes Alerting definieren

• Verfügbarkeits-SLI: erfolgreiche Anfragen / gesamt. Latenz-SLI: p95-Dauer für POST /checkout.
• SLOs: 99,9 % Verfügbarkeit pro Monat; 95 % der Checkouts < 300 ms.
• Multi-Window-Burn-Rate-Alerts und einen Metric-Absence-Alert für den Checkout-Heartbeat konfigurieren. Begründung: Symptombasierte Alarme reduzieren das Rauschen und alarmieren nur bei Auswirkungen auf die Benutzer.

4. Health Probes und synthetische Prüfungen einrichten

• Cloud Run-Services stellen /ready und /healthz bereit. Einen globalen Uptime-Check für /checkout und einen privaten synthetischen Job in der VPC hinzufügen, der einen vollständigen Checkout mit Test-Anmeldedaten durchführt. Begründung: Readiness verhindert, dass kalte Backends Traffic erhalten; Synthetics erkennen End-to-End-Probleme und Regressionen bei Drittanbietern.

5. Cloud Trace und Profiler aktivieren und Wiederholungsversuche mit Backoff einführen

• Trace/Profiler-Agents installieren, wo anwendbar; automatische HTTP-Client-Instrumentierung und SQL-Span-Annotation aktivieren. Truncated Exponential Backoff mit Idempotenzschlüsseln für Aufrufe der Steuer-API implementieren. Begründung: Tracing isoliert Latenzverursacher; Backoff reduziert die Verstärkung von 429/5xx-Fehlern und schont die Fehlerbudgets.

6. Kapazität und Kontingente überwachen

• Dashboards und Alarme für Cloud SQL-Verbindungen, CPU, InnoDB-Buffer-Pool, nicht bestätigte Pub/Sub-Nachrichten, Cloud Run-Gleichzeitigkeit und Service-Kontingentnutzung hinzufügen. Begründung: Kapazitätssättigung ist eine häufige versteckte Ursache für Tail-Latenz; frühzeitige Alarme verhindern Ausfälle.

7. Debugging im Hinblick auf den Datenschutz härten

• Gehashte Benutzer-IDs verwenden und PII aus Fehlermeldungen ausschließen. Den Zugriff auf Debugger in der Produktion auf Logpoints und die Anwendung von Schwärzungsregeln beschränken. Begründung: Aufrechterhaltung der Observability bei gleichzeitiger Einhaltung der Datenminimierung.

8. Überwachung von Abhängigkeiten und Circuit Breaker erstellen

• Erfolgsrate und Latenz der externen Steuer-API über benutzerdefinierte Metriken verfolgen; einen Circuit Breaker auslösen, der auf zwischengespeicherte Steuersätze zurückgreift, wenn Fehler einen Schwellenwert überschreiten. Begründung: Ausfälle bei Drittanbieter-Abhängigkeiten isolieren und die Verfügbarkeit des Kern-Checkouts aufrechterhalten.

9. Runbooks und Eskalationspfade vorbereiten

• Schritte dokumentieren: SLO-Dashboards überprüfen, Trace Service Map auf Hot Edges prüfen, Cloud SQL Insights auf langsame Abfragen untersuchen, Firewall und Health-Checks verifizieren und den Spielraum bei den Kontingenten bewerten. Rollback- und Canary-Verfahren einschließen. Begründung: Eine konsistente, schnelle Reaktion reduziert die MTTR und vermeidet riskante Ad-hoc-Änderungen.

10. Analyse-Pipeline für die Zeit nach einem Vorfall

• BigQuery-Exporte nutzen, um mandantenspezifische Fehlerraten zu berechnen und Logs mit Traces und Cloud SQL Insights anhand der Trace-ID zu korrelieren. Begründung: Eine dauerhafte, abfragbare Historie ermöglicht genaue RCAs und Präventionsmaßnahmen.

Dieser Plan erhöht die Signalqualität, verkürzt die Zeit bis zur Erkennung und Behebung, schützt die User Experience bei Lastspitzen und setzt den Datenschutz beim Debugging in der Produktion durch.

← Continuous Delivery · Alle Domänen · Performance →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Google durchsuchen →