Osservabilità come disciplina, non come dashboard

L’osservabilità in Google Cloud poggia sulla suite Cloud Operations (ex Stackdriver): raccogliere segnali — log, metriche, trace — che permettano di rispondere a domande non previste in anticipo. Per un developer il punto non è “guardare grafici”, ma strumentare il codice così che, in produzione, si capisca cosa è lento, perché fallisce e quanto costa in risorse. I tre pilastri classici (logs, metrics, traces) si completano con Error Reporting e Cloud Profiler.

Cloud Logging e Cloud Monitoring

Cloud Logging raccoglie i log applicativi. La best practice developer è lo structured logging: emettere JSON su stdout/stderr (su Cloud Run, Cloud Functions e GKE viene parsato automaticamente in campi con severity e correlato al trace ID) invece di stringhe piatte. I campi strutturati abilitano query precise e riducono il rumore. Da questi log si creano log-based metrics: counter (quante entry corrispondono a un filtro) o distribution (valori numerici estratti), utili per allertare su un pattern di log senza strumentare una metrica applicativa custom.

Cloud Monitoring gestisce le metriche (di sistema, delle risorse gestite e custom), le dashboard, le alerting policy (con notification channel) e gli uptime check (probe sintetici verso un endpoint per misurarne disponibilità e latenza dall’esterno). Regola pratica: log-based metric per trasformare eventi di log in serie temporali; metrica custom quando l’applicazione deve pubblicare direttamente un valore di business.

Cloud Trace, Cloud Profiler ed Error Reporting

Cloud Trace serve la latenza: raccoglie trace distribuiti (span) e mostra dove il tempo viene speso lungo una richiesta che attraversa più servizi. È lo strumento per diagnosticare code path lenti, fan-out di chiamate, latenza delle dipendenze e cold start. L’integrazione avviene tipicamente via OpenTelemetry; ambienti come Cloud Run e App Engine catturano trace di base automaticamente. La correlazione log↔trace (stesso trace ID) permette di saltare dal log allo span corrispondente.

Cloud Profiler serve CPU e memoria: è un profiler continuo, always-on, a basso overhead (campionamento statistico) pensato per la produzione. Mostra consumo di CPU time, heap allocation, wall time e contention. È la scelta quando il sintomo è “il servizio consuma troppa CPU/RAM” o “i costi compute crescono”, non “le richieste sono lente” (quella è Trace).

Error Reporting aggrega e deduplica automaticamente le eccezioni non gestite a partire dagli stack trace nei log, raggruppa errori simili e notifica le nuove regressioni. Evita di costruire manualmente query sui log per contare le eccezioni.

SLI, SLO ed error budget

L’affidabilità si governa con numeri. Un SLI (Service Level Indicator) è una misura quantitativa del servizio: availability, error rate, latenza al percentile (es. p99). Un SLO (Service Level Objective) è il target dell’SLI su una finestra temporale (es. 99.9% di richieste sotto 300 ms su 28 giorni). L’error budget — la quota di inaffidabilità ammessa (100% − SLO) — è centrale: guida le decisioni di rilascio, perché a budget esaurito si congela il deploy di feature e ci si concentra sulla stabilità. L’SLA è invece l’impegno contrattuale esterno, di solito meno stringente dell’SLO interno. Cloud Monitoring supporta nativamente la definizione di SLO e il tracking del budget.

Trappole tipiche d’esame

  • Richieste lente vs alto consumo di CPU → Trace vs Profiler: Cloud Trace diagnostica dove si perde tempo in una richiesta distribuita; Cloud Profiler analizza quanta CPU/memoria consuma il codice. Distrattore classico che li scambia.
  • Allertare sulla frequenza di un messaggio di log → log-based metric: non serve una metrica custom applicativa; crea una log-based metric sul filtro e definisci un’alerting policy.
  • Contare o raggruppare le eccezioni in produzione → Error Reporting: aggrega e deduplica gli stack trace automaticamente; costruire query manuali su Cloud Logging è la risposta sbagliata.
  • Monitorare la disponibilità di un endpoint dall’esterno → uptime check: un’alerting policy su metriche interne non rileva l’irraggiungibilità di rete; l’uptime check è il probe sintetico corretto.
  • Log utili e correlati su Cloud Run → structured logging su stdout: scrivere JSON su stdout è più efficiente e abilita la correlazione con il trace; chiamare l’API di Logging per ogni entry aggiunge latenza.
  • Decidere se rilasciare una feature → SLO ed error budget: è il budget residuo a guidare freeze o deploy, non l’SLA; confondere SLO (target interno) e SLA (impegno esterno) è la trappola.