I tre segnali dell’osservabilità: scegliere lo strumento giusto

Il troubleshooting di produzione parte dal riconoscere quale segnale risponde alla domanda che stiamo facendo. Cloud Trace misura la latenza delle richieste distribuite; Cloud Profiler misura il consumo di risorse (CPU e memoria) del codice in esecuzione; Error Reporting aggrega le eccezioni. Confonderli è l’errore classico: se un servizio è lento ma non va in crash, la risposta viene dal trace o dal profiler, non dai log degli errori. In un approccio SRE il punto di partenza è quasi sempre un burn-rate alert sull’error budget di uno SLO: l’alert dice che stiamo consumando budget troppo in fretta, gli strumenti di osservabilità dicono perché.

Cloud Trace: latenza e colli di bottiglia distribuiti

Cloud Trace raccoglie gli span che compongono il percorso di una richiesta attraverso più servizi, mostrando dove si accumula il tempo (il tipico diagramma a cascata). È lo strumento per la tail latency: la p50 può essere sana mentre la p99 degrada per un singolo downstream lento o per una chiamata seriale che dovrebbe essere parallela. Trace risponde a “quale hop della catena costa i millisecondi?”, non a “quale funzione brucia CPU”. Poiché tracciare ogni richiesta è costoso, si usa il sampling: si accetta di non vedere ogni singola richiesta in cambio di overhead contenuto. L’instrumentation avviene tipicamente via OpenTelemetry, lo standard verso cui Google Cloud converge, con auto-instrumentation per i framework comuni e span manuali dove serve granularità sul codice di business.

Cloud Profiler ed Error Reporting: risorse ed eccezioni

Cloud Profiler fa continuous profiling in produzione: campiona statisticamente CPU time, wall time e allocazione di heap/memoria con overhead trascurabile, così da poterlo tenere sempre attivo. Risponde a domande che il trace non può: “quale funzione consuma il 40% della CPU?” o “dove cresce l’uso di memoria che porta a OOM?”. È diagnostica aggregata nel tempo, non per-richiesta. Error Reporting raccoglie e deduplica le eccezioni dai log, raggruppandole per firma dello stack trace: invece di migliaia di righe identiche si ottiene un gruppo con conteggio, primo/ultimo avvistamento e trend, con la possibilità di notificare quando compare un errore nuovo. Serve a capire quali errori dominano e da quando, non la latenza né il consumo di risorse.

Correlazione e root cause analysis

La potenza sta nel legare i segnali. Scrivere log strutturati che includono il trace ID permette di saltare da uno span lento esattamente ai log di quella richiesta; gli exemplars legano un punto anomalo di una metrica al trace che lo ha generato. Un flusso di RCA tipico: il burn-rate alert scatta → le metriche localizzano il servizio e la finestra temporale → il trace isola lo span responsabile → i log correlati e il profiler spiegano la causa (una query lenta, un memory leak, una dipendenza degradata). L’obiettivo operativo è ridurre l’MTTR; l’output finale è un postmortem blameless, che documenta cause e azioni correttive senza colpevolizzare le persone. Un’instrumentation coerente su tutti i servizi è ciò che rende possibile questa correlazione: senza contesto propagato i segnali restano silos.

Trappole tipiche d’esame

  • Latenza p99 alta ma nessun errore → Cloud Trace: il problema è di tempo, non di eccezioni; Error Reporting non mostrerebbe nulla perché non ci sono crash.
  • CPU al 90% in produzione, causa ignota → Cloud Profiler: serve profiling continuo aggregato sulle funzioni; il trace mostra la latenza degli hop, non quale funzione brucia CPU.
  • Migliaia di eccezioni identiche nei log → Error Reporting: deduplica per firma e fornisce conteggio/trend; leggere i log grezzi o costruire metriche a mano è il distrattore.
  • Saltare da uno span lento ai log della stessa richiesta → trace ID nei log strutturati: è la correlazione corretta; abbassare il sampling o aggiungere log non correlati non aiuta.
  • “Chi ha causato l’incidente?” → postmortem blameless: l’esame premia il focus su cause sistemiche e azioni correttive, mai sull’individuazione del colpevole.
  • Attivare il profiler solo durante l’incidente → continuous profiling sempre attivo: l’overhead è trascurabile e serve la baseline storica per confrontare il “prima” e il “dopo”.