Google PCD: Osservabilità, debugging e operazioni di Site Reliability — Guida allo studio

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

Fa parte della Google Professional Cloud Developer — Guida allo studio. Esercitati con risposte verificate nel centro esami Google, oppure fai test cronometrati su ExamRoll.io.

Panoramica

L’osservabilità, il debug e le operazioni di affidabilità del sito in Google Cloud si concentrano sul rendere i sistemi misurabili, diagnosticabili e resilienti. Una solida osservabilità richiede logging e metriche coerenti, tracciamento distribuito, avvisi efficaci (actionable) e una risposta agli incidenti disciplinata. L’affidabilità richiede chiarezza sugli indicatori e sugli obiettivi di livello di servizio (SLI/SLO), una segnalazione rigorosa dello stato di salute e un ciclo di feedback che trasformi le informazioni ottenute dalla produzione in miglioramenti ingegneristici. Questa sezione illustra come creare queste capacità end-to-end in Google Cloud e come ragionare su compromessi e modalità di fallimento comuni.

Fondamenti di Logging e Monitoring

Cloud Logging

Emettere log strutturati. Preferire JSON con nomi di campo stabili in modo che le query e le metriche basate su log rimangano robuste tra le diverse release. Includere gravità, nome del servizio, versione, posizione e un ID di richiesta o un contesto di traccia per la correlazione.
Correlare i log alle tracce impostando i campi:
- logging.googleapis.com/trace: projects/PROJECT_ID/traces/TRACE_ID
- logging.googleapis.com/spanId: SPAN_ID
- logging.googleapis.com/trace_sampled: true
Bucket e conservazione. Il bucket _Default ha tipicamente una conservazione di 30 giorni (configurabile). Il bucket _Required contiene determinati log di audit con una conservazione più lunga e fissa. Creare bucket regionali per controllare la residenza dei dati e impostare una conservazione personalizzata per ogni bucket.
Sink. Indirizzare i log verso BigQuery per le analisi, verso Pub/Sub per i consumer in streaming o verso Storage per l’archiviazione. Utilizzare sink aggregati a livello di cartella o organizzazione per acquisire i log dei progetti figli.
Query. Utilizzare il linguaggio di query di Logging per filtrare per resource.type, etichette, jsonPayload, httpRequest o textPayload.

Esempi:

Voce di log strutturato (abbreviata): { “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” }
Aggiornare la conservazione: gcloud logging buckets update _Default –location=global –retention-days=180
Creare un sink BigQuery per i log di errore: gcloud logging sinks create bq-errors
bigquery.googleapis.com/projects/myproj/datasets/log_analytics
–log-filter=‘severity>=ERROR’
Leggere i recenti errori 5xx per Cloud Run: gcloud logging read ‘resource.type=“cloud_run_revision” AND httpRequest.status>=500’ –limit=20

Cloud Monitoring

Metriche. Utilizzare le metriche di Google Cloud, le metriche personalizzate e le metriche basate su log. Privilegiare etichette a bassa cardinalità; un’esplosione della cardinalità delle etichette causa problemi di costo e di latenza delle query.
Dashboard. Curare dashboard per ogni servizio e per ogni dipendenza (database, cache, code). Visualizzare i segnali RED (requests, errors, duration - richieste, errori, durata) e USE (utilization, saturation, errors - utilizzo, saturazione, errori).
Criteri di avviso. Attivare avvisi basati su soglie, assenza di metriche, rapporti, tassi di consumo dello SLO (burn rate) o fallimenti dei controlli di uptime. Configurare i canali di notifica (email, SMS, PagerDuty, Pub/Sub, webhook). Sopprimere il ‘flapping’ (oscillazioni di stato) tramite finestre temporali e allineatori.
Controlli di uptime. Eseguire sonde da più regioni; utilizzare controlli di uptime privati per endpoint interni o eseguire test sintetici dall’interno del VPC.

Metriche basate su log

I contatori (Counter) riepilogano le occorrenze (ad esempio, il conteggio delle richieste /api/alpha/*).
Le distribuzioni (Distribution) acquisiscono la latenza o le dimensioni dei payload.
Esempio: 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”’

Analisi operative

Per analisi ad hoc, indirizzare i dati a BigQuery tramite un sink; progettare schemi e partizionamento per timestamp per controllare i costi.
Utilizzare Log Analytics nei bucket di Logging per aggregare i dati senza esportarli, dove applicabile.
Costruire segnali di capacità da metriche come CPU, memoria, profondità della coda, connessioni a Cloud SQL, CPU ad alta priorità di Spanner, messaggi non confermati (unacked) in Pub/Sub e tassi di errori 429/5xx di Cloud Storage.

Insidie e compromessi comuni

Un logging eccessivo aumenta i costi di ingestione e oscura i segnali importanti; preferire il campionamento e una disciplina sulla gravità dei log.
La mancanza di ID di correlazione ostacola il triage degli incidenti; propagare gli ID di traccia end-to-end.
Una lunga conservazione nei bucket ‘caldi’ (hot) aumenta i costi; esportare verso l’archivio o BigQuery per le esigenze a lungo termine.

Tracciamento, Errori e Diagnostica Approfondita

Tracciamento distribuito

Contesto di traccia. Preferire il W3C trace-context (traceparent, tracestate). Per l’interoperabilità con Cloud Trace, continuare a supportare x-cloud-trace-context: x-cloud-trace-context: TRACE_ID/SPAN_ID;o=1
Propagazione. Inoltrare gli header di traccia tra servizi, code di messaggi e confini asincroni; catturare nuovi span figli quando si effettuano chiamate RPC o SQL. La perdita di contesto rompe le mappe dei servizi e gonfia i nodi “servizio sconosciuto”.
Campionamento. Bilanciare costo e fedeltà; il campionamento dinamico basato sull’head all’ingresso e il campionamento basato sulla tail per le richieste lente e rare possono migliorare l’utilità.

Cloud Trace

Fornisce istogrammi di latenza, waterfall degli span e mappe dei servizi. Usare le annotazioni per sotto-operazioni critiche (chiamate RPC, query al DB).
Diagnosticare gli outlier utilizzando le tracce p95/p99; prestare attenzione a fan-out, query N+1 o contesa sui lock.
Abilitare la correlazione tra tracce e log in modo che un clic su una traccia riveli i log associati.

Error Reporting

Aggrega automaticamente le eccezioni per firma dello stack per ogni servizio/versione. Configurare il contesto del servizio per evitare la fusione tra servizi diversi. Sopprimere errori noti e rumorosi o indirizzarli a notifiche a priorità più bassa.
Anonimizzare le PII (Personally Identifiable Information) dai messaggi di eccezione; registrare invece codici di errore stabili e ID di correlazione.

Cloud Profiler

Profilazione continua di CPU/heap a basso overhead per i runtime supportati. Confrontare i profili tra versioni e livelli di traffico per individuare regressioni. Evitare di interpretare gli artefatti del campionamento come conteggi esatti.

Cloud Debugger

Gli snapshot catturano le variabili in un punto del codice senza mettere in pausa il processo. I logpoint iniettano istruzioni di logging temporanee. Limitare l’accesso, anonimizzare le variabili sensibili e limitare lo scope a espressioni che non contengono PII.

Breve esempio: aggiungere un traceparent W3C e correlare un log

Propagazione HTTP: traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
Campo di log per il collegamento a Cloud Trace: “logging.googleapis.com/trace”: “projects/myproj/traces/4bf92f3577b34da6a3ce929d0e0e4736”

Ingegneria dell’Affidabilità, Alerting e Segnali di Integrità

SLI, SLO, SLA e error budget

Gli SLI (Service Level Indicator) misurano la soddisfazione dell’utente: disponibilità, latenza, correttezza. Definirli per ogni endpoint critico e percorso utente.
Gli SLO (Service Level Objective) stabiliscono degli obiettivi, ad es., il 99,9% delle richieste sotto i 300 ms su un periodo di 30 giorni.
Gli error budget quantificano l’inaffidabilità consentita. Utilizzare i budget per rilasci, esperimenti o migrazioni; congelare le modifiche se il burn rate è troppo alto.
Gli SLA (Service Level Agreement) sono impegni esterni; mantenere l’SLO più stringente dello SLA per proteggere il margine.

Progettazione di alert di qualità

Ove possibile, preferire alert basati su SLO e sintomi piuttosto che sulla causa.
Utilizzare alert multi-finestra e multi-burn-rate (ad esempio, 14x in 5 minuti e 2x in 1 ora) per rilevare burn rapidi e lenti, riducendo al contempo il rumore.
Aggiungere l’assenza di metriche per i watchdog (es. heartbeat di un job a lunga esecuzione).
Instradare per severità; limitare la frequenza delle notifiche; fornire link a runbook e dashboard.

Health check e probe

I controlli di readiness bloccano il traffico finché le dipendenze non sono pronte; i controlli di liveness attivano il riavvio di processi bloccati; i probe di avvio proteggono i servizi lenti ad avviarsi da riavvii prematuri.
Per le VM con load balancing, consentire gli intervalli di origine dell’health checker, altrimenti il traffico non raggiungerà mai i backend: 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
Esempio per Kubernetes: readinessProbe: httpGet: { path: /ready, port: 8080 } periodSeconds: 5 failureThreshold: 3 livenessProbe: httpGet: { path: /healthz, port: 8080 } initialDelaySeconds: 30 periodSeconds: 10
Test sintetici. Utilizzare controlli di uptime e flussi end-to-end personalizzati tramite Cloud Scheduler + Cloud Run/Functions per convalidare il login, i pagamenti o altri percorsi critici.
Monitoraggio delle dipendenze. Tracciare la saturazione delle connessioni al database, il rapporto di errori RPC, i backlog delle code, gli errori in uscita e gli SLI di terze parti. Impostare tentativi con backoff esponenziale troncato per errori transitori 429/5xx, con chiavi di idempotenza per sicurezza.

Risposta agli incidenti, debug attento alla sicurezza e causa radice

Ciclo di vita della risposta agli incidenti

Triage: classificare la gravità, assegnare un incident commander e contattare il personale reperibile tramite i canali definiti.
Contenimento: applicare mitigazioni note e controlli del traffico (rollback, canary, circuit breaker, limitatori di frequenza).
Comunicazione: mantenere una war-room interna, aggiornare regolarmente gli stakeholder e pubblicare lo stato per gli utenti quando necessario.
Risoluzione e ripristino: verificare lo stato di salute tramite gli SLI; evitare un “tutto a posto” prematuro.
Post-mortem: analizzare senza colpevolizzazione la timeline, le lacune nel rilevamento, i fattori contribuenti e le azioni correttive con responsabili e scadenze. Tracciare fino alla chiusura.

Runbook

Includere trigger, contesto necessario, comandi diagnostici, mitigazioni sicure, passaggi di rollback e percorsi di escalation. Collegare a dashboard, log e playbook per modalità di guasto specifiche.

Monitoraggio delle quote e della capacità

Monitorare le quote di servizio tramite le metriche di Cloud Monitoring. Automatizzare gli avvisi al 70-80% di utilizzo e richiedere in anticipo aumenti per test di carico o lanci pianificati.
Segnali di capacità da monitorare: CPU, memoria, descrittori di file, pool di thread, connessioni al DB, limiti dell’autoscaler e profondità della coda delle richieste.

Debug senza esporre informazioni sensibili

Oscurare segreti e PII all’origine; centralizzare i segreti in Secret Manager. Usare hashing o tokenizzazione per gli identificatori utente. Abilitare l’oscuramento a livello di campo nel middleware di logging.
Limitare l’accesso a log, tracce e strumenti di debug tramite IAM; usare CMEK e VPC Service Controls dove applicabile.
In Debugger, disabilitare la raccolta di grafi di oggetti di grandi dimensioni e aggiungere condizioni per evitare di catturare frame sensibili.

Analisi della causa radice (root cause) attraverso i vari livelli

Runtime: correlare i picchi di GC, pool di thread o CPU tramite Profiler con la latenza p99 in Trace.
Rete: ispezionare i log del bilanciatore di carico, i VPC Flow Logs, i log del firewall e i Connectivity Tests per convalidare i percorsi. I fallimenti degli health check sono comunemente dovuti a regole firewall mancanti o porte errate.
IAM: esaminare i Cloud Audit Logs per rifiuti di autorizzazione o modifiche alle policy; confermare i ruoli degli account di servizio e gli scope dei token.
Dati: usare Cloud SQL Insights, le statistiche delle query di Spanner, la CPU e le hot tablet di Bigtable e i tassi di errore di Storage per trovare hotspot. Applicare tentativi con backoff per guasti transitori e ridurre il fan-out che amplifica la latenza di coda.
Mettere tutto insieme con ID di traccia correlati e metriche basate su log; esportare in BigQuery per eseguire join multi-sorgente durante l’analisi post-incidente.

Scenario pratico

Fjord Retail migra un processo di checkout multi-servizio su Google Cloud usando Cloud Run, Cloud SQL, Pub/Sub e un’API fiscale esterna. Gli utenti segnalano timeout intermittenti e picchi nel tasso di errore durante le vendite flash, e il personale reperibile riceve avvisi rumorosi e a basso segnale.

Approccio:

Implementare il logging strutturato con correlazione delle tracce

Aggiungere la propagazione di W3C traceparent tra i servizi e includere logging.googleapis.com/trace in tutti i log. Motivazione: la correlazione end-to-end consente agli ingegneri di passare da una richiesta utente lenta all’esatto RPC o query lenta e ai relativi log.

Creare bucket di Logging, policy di conservazione ed esportazioni

Aumentare la conservazione di _Default a 90 giorni e creare un bucket regionale per i carichi di lavoro UE. Aggiungere un sink aggregato a BigQuery per i log di tipo ERROR e WARNING: gcloud logging sinks create bq-prod
bigquery.googleapis.com/projects/fjord/datasets/ops_logs
–log-filter=‘severity>=WARNING’ –include-children Motivazione: una conservazione a caldo sufficiente aiuta il debug; BigQuery consente analisi rapide degli incidenti senza gonfiare i costi dello storage a caldo.

Definire SLI/SLO e avvisi basati su SLO

SLI di disponibilità: richieste andate a buon fine / totali. SLI di latenza: durata p95 per POST /checkout.
SLO: disponibilità del 99,9% su base mensile; 95% dei checkout < 300 ms.
Configurare avvisi di burn rate multi-finestra e un avviso di assenza di metrica per l’heartbeat del checkout. Motivazione: gli avvisi basati sui sintomi riducono il rumore e attivano le notifiche solo in caso di impatto sull’utente.

Impostare probe di integrità e controlli sintetici

I servizi Cloud Run espongono /ready e /healthz. Aggiungere un uptime check globale per /checkout e un job sintetico privato nel VPC che esegue un checkout completo con credenziali di test. Motivazione: la prontezza (readiness) impedisce ai backend “freddi” di ricevere traffico; i test sintetici intercettano problemi end-to-end e regressioni di terze parti.

Abilitare Cloud Trace e Profiler, e adottare tentativi con backoff

Installare gli agenti di Trace/Profiler dove applicabile; abilitare la strumentazione automatica del client HTTP e l’annotazione degli span SQL. Implementare un backoff esponenziale troncato con chiavi di idempotenza per le chiamate all’API fiscale. Motivazione: il tracing isola i fattori che contribuiscono alla latenza; il backoff riduce l’amplificazione degli errori 429/5xx e protegge gli error budget.

Monitorare capacità e quote

Aggiungere dashboard e avvisi per le connessioni Cloud SQL, CPU, buffer pool di InnoDB, messaggi non confermati (unacked) di Pub/Sub, concorrenza di Cloud Run e utilizzo delle quote di servizio. Motivazione: la saturazione della capacità è una causa nascosta comune della latenza di coda; gli avvisi tempestivi prevengono le interruzioni.

Rafforzare il debug per la privacy

Usare ID utente sottoposti ad hashing ed escludere le PII dai messaggi di errore. Limitare Debugger alla produzione con regole di oscuramento e solo logpoint. Motivazione: mantenere l’osservabilità rispettando la minimizzazione dei dati.

Costruire monitor delle dipendenze e circuit breaker

Tracciare il tasso di successo e la latenza dell’API fiscale esterna tramite metriche personalizzate; attivare un circuit breaker per passare a tariffe fiscali memorizzate nella cache quando i fallimenti superano una soglia. Motivazione: isolare i guasti nelle dipendenze di terze parti e mantenere la disponibilità del checkout principale.

Preparare runbook e percorsi di escalation

Documentare i passaggi: verificare le dashboard degli SLO, controllare la mappa dei servizi di Trace per archi “caldi”, ispezionare Cloud SQL Insights per query lente, verificare firewall e health check, e valutare il margine di quota. Includere procedure di rollback e canary. Motivazione: una risposta coerente e rapida riduce l’MTTR ed evita modifiche ad-hoc rischiose.

Pipeline di analisi post-incidente

Usare le esportazioni di BigQuery per calcolare i tassi di errore per tenant e per correlare i log con le tracce e gli insight di Cloud SQL tramite l’ID di traccia. Motivazione: una cronologia durevole e interrogabile consente RCA accurati e misure preventive.

Questo piano eleva la qualità del segnale, riduce il tempo di rilevamento e risoluzione, protegge l’esperienza utente durante i picchi e garantisce la privacy durante il debug in produzione.

← Continuous Delivery · Tutti i domini · Prestazioni →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →