Google PCD: Observability, debugging en Site Reliability Operations — Studiegids

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

Onderdeel van de Google Professional Cloud Developer — Studiegids. Oefen met geverifieerde antwoorden in het Google-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

Observeerbaarheid, debugging en site reliability operations in Google Cloud draaien om het meetbaar, diagnosticeerbaar en veerkrachtig maken van systemen. Sterke observeerbaarheid vereist consistente logging en metrics, distributed tracing, bruikbare alarmeringen en een gedisciplineerde incidentrespons. Betrouwbaarheid vraagt om duidelijkheid over service-level indicators en objectives, rigoureuze statussignalering en een feedbackloop die inzichten uit productie omzet in technische verbeteringen. Dit hoofdstuk beschrijft hoe je deze capaciteiten end-to-end opbouwt in Google Cloud en hoe je redeneert over afwegingen en veelvoorkomende faalscenario’s.

Basisprincipes van Logging en Monitoring

Cloud Logging

Genereer gestructureerde logs. Geef de voorkeur aan JSON met stabiele veldnamen, zodat query’s en op logs gebaseerde metrics robuust blijven over releases heen. Neem severity, servicenaam, versie, locatie en een request-ID of trace-context op voor correlatie.
Correleer logs aan traces door de volgende velden in te stellen:
- logging.googleapis.com/trace: projects/PROJECT_ID/traces/TRACE_ID
- logging.googleapis.com/spanId: SPAN_ID
- logging.googleapis.com/trace_sampled: true
Buckets en retentie. De _Default-bucket heeft doorgaans een retentie van 30 dagen (configureerbaar). De _Required-bucket bevat bepaalde auditlogs met een langere, vaste retentie. Maak regionale buckets aan om dataresidentie te beheren en stel per bucket een aangepaste retentie in.
Sinks. Routeer logs naar BigQuery voor analytics, naar Pub/Sub voor streaming consumers, of naar Storage voor archivering. Gebruik geaggregeerde sinks op folder- of organisatieniveau om logs van onderliggende projecten te verzamelen.
Query’s. Gebruik de Logging-querytaal om te filteren op resource.type, labels, jsonPayload, httpRequest of textPayload.

Voorbeelden:

Gestructureerd log-item (ingekort): { “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” }
Retentie bijwerken: gcloud logging buckets update _Default –location=global –retention-days=180
Een BigQuery-sink voor error-logs aanmaken: gcloud logging sinks create bq-errors
bigquery.googleapis.com/projects/myproj/datasets/log_analytics
–log-filter=‘severity>=ERROR’
Recente 5xx-fouten voor Cloud Run lezen: gcloud logging read ‘resource.type=“cloud_run_revision” AND httpRequest.status>=500’ –limit=20

Cloud Monitoring

Metrics. Gebruik Google Cloud-metrics, custom metrics en op logs gebaseerde metrics. Geef de voorkeur aan labels met een lage kardinaliteit; een exploderende labelkardinaliteit veroorzaakt problemen met kosten en query-latency.
Dashboards. Stel dashboards samen per service en per afhankelijkheid (database, cache, wachtrijen). Visualiseer RED- (requests, errors, duration) en USE- (utilization, saturation, errors) signalen.
Alertbeleid. Trigger op drempelwaarden, afwezigheid van metrics, ratio’s, SLO burn rates of mislukte uptime checks. Configureer notificatiekanalen (e-mail, sms, PagerDuty, Pub/Sub, webhooks). Onderdruk ‘flapping’ via windowing en aligners.
Uptime checks. Test vanuit meerdere regio’s; gebruik private uptime voor interne endpoints of voer synthetics uit binnen de VPC.

Op logs gebaseerde metrics

Counters vatten gebeurtenissen samen (bijvoorbeeld het aantal /api/alpha/*-requests).
Distributions leggen latency of de grootte van payloads vast.
Voorbeeld: gcloud logging metrics create api_alpha_count
–description=“Count of /api/alpha/* requests”
–log-filter=‘httpRequest.requestUrl=~"/api/alpha/.*" AND resource.type=“cloud_run_revision”’

Operationele analytics

Voor ad-hoc-analyse, routeer data naar BigQuery via een sink; ontwerp schema’s en partitionering op timestamp om de kosten te beheersen.
Gebruik Log Analytics in Logging-buckets om te aggregeren zonder te exporteren waar dat mogelijk is.
Bouw capaciteitssignalen op uit metrics zoals CPU, geheugen, wachtrijdiepte, Cloud SQL-verbindingen, Spanner high-priority CPU, Pub/Sub unacked messages en Cloud Storage 429/5xx-rates.

Veelvoorkomende valkuilen en afwegingen

Overmatig loggen verhoogt de ingestiekosten en vertroebelt het signaal; geef de voorkeur aan sampling en discipline in het gebruik van severity levels.
Ontbrekende correlatie-ID’s belemmeren de triage van incidenten; propageer trace-ID’s end-to-end.
Lange retentie in ‘hot’ buckets verhoogt de kosten; exporteer naar een archief of BigQuery voor langetermijnbehoeften.

Tracing, Fouten en Diepgaande Diagnostiek

Gedistribueerde tracing

Trace-context. Geef de voorkeur aan W3C trace-context (traceparent, tracestate). Blijf voor interoperabiliteit met Cloud Trace x-cloud-trace-context ondersteunen: x-cloud-trace-context: TRACE_ID/SPAN_ID;o=1
Propagatie. Stuur trace-headers door tussen services, message queues en asynchrone grenzen; leg nieuwe child-spans vast bij het maken van RPC’s of SQL-calls. Verlies van context verbreekt service maps en leidt tot een toename van ‘unknown service’-nodes.
Sampling. Breng kosten en nauwkeurigheid in balans; dynamische head-based sampling bij ingress en tail-based sampling voor zeldzame trage requests kunnen de bruikbaarheid vergroten.

Cloud Trace

Biedt latency-histogrammen, span-waterfalls en service maps. Gebruik annotaties voor kritieke sub-operaties (RPC’s, DB-queries).
Diagnosticeer uitschieters met p95/p99-traces; let op fan-out, N+1-queries of lock-contention.
Activeer trace-logcorrelatie zodat het klikken op een trace de bijbehorende logs toont.

Error Reporting

Aggregeert automatisch excepties per service/versie op basis van de stack-signatuur. Configureer de service-context om vermenging tussen services te voorkomen. Onderdruk bekende, ’noisy’ fouten of stuur ze naar notificaties met een lagere prioriteit.
Redigeer PII (persoonlijk identificeerbare informatie) uit exceptieberichten; log in plaats daarvan stabiele foutcodes en correlatie-ID’s.

Cloud Profiler

Continue CPU/heap-profiling met lage overhead voor ondersteunde runtimes. Vergelijk profielen tussen versies en verkeersniveaus om regressies op te sporen. Vermijd het interpreteren van sampling-artefacten als exacte tellingen.

Cloud Debugger

Snapshots leggen variabelen vast op een specifieke locatie in de code zonder het proces te pauzeren. Logpoints injecteren tijdelijke logging-statements. Beperk de toegang, redigeer gevoelige variabelen en beperk de scope tot expressies zonder PII.

Kort voorbeeld: voeg W3C traceparent toe en correleer een log

HTTP-propagatie: traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
Logveld om te linken naar Cloud Trace: “logging.googleapis.com/trace”: “projects/myproj/traces/4bf92f3577b34da6a3ce929d0e0e4736”

Reliability Engineering, Alarmering en Health Signals

SLI’s, SLO’s, SLA’s en error budgets

SLI’s meten gebruikerstevredenheid: beschikbaarheid, latency, correctheid. Definieer deze per kritiek endpoint en ‘user journey’.
SLO’s stellen doelen, bijv. 99,9% van de requests onder 300 ms over een periode van 30 dagen.
Error budgets kwantificeren de toegestane onbetrouwbaarheid. Gebruik budgets voor releases, experimenten of migraties; bevries wijzigingen als de ‘burn rate’ te hoog is.
SLA’s zijn externe verplichtingen; houd de SLO strenger dan de SLA om marge te beschermen.

Ontwerp van kwalitatieve alerts

Geef waar mogelijk de voorkeur aan SLO- en symptoomgebaseerde alerts boven oorzaakgebaseerde alerts.
Gebruik ‘multi-window, multi-burn-rate’ alerts (bijvoorbeeld 14x over 5 minuten en 2x over 1 uur) om snelle en langzame ‘burns’ te detecteren en tegelijkertijd ruis te verminderen.
Voeg ‘metric absence’ toe voor watchdogs (bijv. de heartbeat van een langlopende taak).
Routeer op basis van ernst (‘severity’); pas rate-limiting toe op notificaties; voorzie links naar runbooks en dashboards.

Health checks en probes

Readiness checks houden verkeer tegen totdat afhankelijkheden gereed zijn; liveness checks triggeren herstarts bij vastgelopen processen; startup probes beschermen langzaam startende applicaties tegen vroegtijdige herstarts.
Sta voor load-balanced VM’s de source ranges van de health checker toe, anders bereikt het verkeer de backends nooit: 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-voorbeeld: readinessProbe: httpGet: { path: /ready, port: 8080 } periodSeconds: 5 failureThreshold: 3 livenessProbe: httpGet: { path: /healthz, port: 8080 } initialDelaySeconds: 30 periodSeconds: 10
Synthetische tests. Gebruik uptime checks en op maat gemaakte end-to-end flows via Cloud Scheduler + Cloud Run/Functions om inloggen, betalingen of andere kritieke paden te valideren.
Monitoring van afhankelijkheden. Volg de verzadiging van databaseverbindingen, RPC-foutratio’s, wachtrij-backlogs, egress-fouten en SLI’s van derden. Stel retries in met ’truncated exponential backoff’ voor tijdelijke 429/5xx-fouten, met ‘idempotency keys’ voor veiligheid.

Incidentrespons, securitybewust debuggen en hoofdoorzaak (Root Cause)

Levenscyclus van incidentrespons

Triage: classificeer de ernst, wijs een incident commander toe en roep de on-call-engineer op via gedefinieerde kanalen.
Indammen: pas bekende mitigaties en traffic controls toe (rollback, canary, circuit breaker, rate limiters).
Communiceren: onderhoud een interne ‘war room’, update stakeholders regelmatig en publiceer een status voor gebruikers wanneer dat nodig is.
Oplossen en herstellen: verifieer de status via SLI’s; vermijd een voortijdig ‘sein veilig’.
Postmortem: analyseer zonder schuldvraag de tijdlijn, detectiegaten, bijdragende factoren en actiepunten met eigenaren en deadlines. Volg op tot afronding.

Runbooks

Bevatten triggers, vereiste context, diagnostische commando’s, veilige mitigaties, rollback-stappen en escalatiepaden. Link naar dashboards, logs en playbooks voor specifieke storingsscenario’s.

Monitoring van quota en capaciteit

Monitor servicequota’s via Cloud Monitoring-metrics. Automatiseer alerts bij 70–80% gebruik en vraag vooraf verhogingen aan voor geplande loadtests of lanceringen.
Te volgen capaciteitssignalen: CPU, geheugen, file descriptors, thread pools, DB-verbindingen, autoscaler-limieten en de diepte van de request-wachtrij.

Debuggen zonder gevoelige informatie bloot te stellen

Redigeer secrets en PII (persoonlijk identificeerbare informatie) bij de bron; centraliseer secrets in Secret Manager. Gebruik hashing of tokenization voor gebruikers-ID’s. Activeer redactie op veldniveau in logging-middleware.
Beperk toegang tot logs, traces en debug-tools via IAM; gebruik CMEK en VPC Service Controls waar van toepassing.
Schakel in Debugger het verzamelen van grote objectgrafieken uit en voeg voorwaarden toe om het vastleggen van gevoelige frames te vermijden.

Analyse van de hoofdoorzaak (root cause) over verschillende lagen

Runtime: correleer pieken in GC, thread pools of CPU via Profiler met p99-latency in Trace.
Netwerk: inspecteer load balancer-logs, VPC Flow Logs, firewall-logs en Connectivity Tests om paden te valideren. Mislukte health checks zijn vaak het gevolg van ontbrekende firewallregels of verkeerde poorten.
IAM: bekijk Cloud Audit Logs voor geweigerde permissies of beleidswijzigingen; bevestig de rollen van serviceaccounts en de scopes van tokens.
Data: gebruik Cloud SQL Insights, Spanner-querystatistieken, Bigtable CPU en ‘hot tablets’, en Storage-foutpercentages om hotspots te vinden. Pas retries met backoff toe voor tijdelijke fouten en verminder fan-out die tail latency versterkt.
Koppel alles aan elkaar met gecorreleerde trace-ID’s en op logs gebaseerde metrics; exporteer naar BigQuery om joins over meerdere bronnen uit te voeren tijdens de analyse na een incident.

Praktijkscenario

Fjord Retail migreert een checkout-proces met meerdere services naar Google Cloud met behulp van Cloud Run, Cloud SQL, Pub/Sub en een externe belasting-API. Gebruikers melden sporadische time-outs en pieken in foutpercentages tijdens flash sales, en de on-call-engineer ontvangt ’noisy’ alerts met een laag signaalgehalte.

Aanpak:

Instrumenteer gestructureerde logging met trace-correlatie

Voeg W3C traceparent-propagatie toe over services heen en neem

undefined

op in alle logs. Rationale: end-to-end correlatie stelt engineers in staat om vanuit een traag gebruikersverzoek direct door te schakelen naar de exacte trage RPC of query en de bijbehorende logs. 2) Maak Logging-buckets, retentie en exports aan

Verhoog de retentie van _Default naar 90 dagen en maak een regionale bucket voor EU-workloads. Voeg een geaggregeerde sink naar BigQuery toe voor ERROR- en WARNING-logs:

undefined

Rationale: voldoende ‘hot’ retentie helpt bij het debuggen; BigQuery maakt snelle incidentanalyses mogelijk zonder de kosten voor ‘hot storage’ op te drijven. 3) Definieer SLI’s/SLO’s en op SLO gebaseerde alerts

Beschikbaarheids-SLI: succesvolle requests / totaal. Latency-SLI: p95-duur voor POST /checkout.
SLO’s: 99,9% beschikbaarheid per maand; 95% van de checkouts < 300 ms.
Configureer multi-window burn-rate-alerts en een ‘metric-absence’-alert voor de checkout-heartbeat. Rationale: op symptomen gebaseerde alerts verminderen ruis en alarmeren alleen bij impact voor de gebruiker.

Stel health probes en synthetische checks in

Cloud Run-services bieden /ready en /healthz aan. Voeg een wereldwijde uptime check toe voor /checkout en een private synthetische taak in de VPC die een volledige checkout uitvoert met testgegevens. Rationale: ‘readiness’ voorkomt dat ‘koude’ backends verkeer ontvangen; synthetische tests vangen end-to-end problemen en regressies van derden op.

Activeer Cloud Trace en Profiler, en pas retries met backoff toe

Installeer Trace/Profiler-agents waar van toepassing; activeer automatische instrumentatie van de HTTP-client en SQL-span-annotatie. Implementeer ’truncated exponential backoff’ met idempotentiesleutels voor aanroepen naar de belasting-API. Rationale: tracing isoleert de oorzaken van latency; backoff vermindert de versterking van 429/5xx-fouten en beschermt error budgets.

Monitor capaciteit en quota’s

Voeg dashboards en alerts toe voor Cloud SQL-verbindingen, CPU, InnoDB buffer pool, Pub/Sub unacked-berichten, Cloud Run-concurrency en het gebruik van servicequota’s. Rationale: capaciteitsverzadiging is een veelvoorkomende verborgen oorzaak van tail latency; vroege alerts voorkomen storingen.

Versterk debugging voor privacy

Gebruik gehashte gebruikers-ID’s en sluit PII uit van foutmeldingen. Beperk Debugger in productie tot alleen logpoints en met redactieregels. Rationale: behoud observability en voldoe tegelijkertijd aan dataminimalisatie.

Bouw dependency-monitors en circuit breakers

Volg het succespercentage en de latency van de externe belasting-API via custom metrics; activeer een circuit breaker die overschakelt op gecachte belastingtarieven wanneer het aantal fouten een drempel overschrijdt. Rationale: isoleer storingen in afhankelijkheden van derden en behoud de beschikbaarheid van de kernfunctionaliteit van de checkout.

Bereid runbooks en escalatiepaden voor

Documenteer de stappen: verifieer SLO-dashboards, controleer de Trace service map op ‘hot edges’, inspecteer Cloud SQL Insights voor trage query’s, verifieer firewall- en health checks, en evalueer de resterende quotaruimte. Neem rollback- en canary-procedures op. Rationale: een consistente, snelle respons vermindert de MTTR en voorkomt ad-hoc risicovolle wijzigingen.

Analyse-pipeline voor na het incident

Gebruik BigQuery-exports om foutpercentages per tenant te berekenen en om logs te correleren met traces en Cloud SQL-inzichten op basis van de trace-ID. Rationale: een duurzame, doorzoekbare geschiedenis maakt nauwkeurige RCA’s en preventieve maatregelen mogelijk.

Dit plan verhoogt de signaalkwaliteit, verkort de tijd tot detectie en oplossing, beschermt de gebruikerservaring tijdens pieken en waarborgt privacy bij het debuggen in productie.

← Continuous Delivery · Alle domeinen · Prestaties →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →