Cloud Monitoring: metriche, dashboard e alerting

Cloud Monitoring raccoglie metriche da Google Cloud, dagli agent (Ops Agent) e da fonti custom, organizzandole come time series con label. I mattoni operativi da padroneggiare sono: le metric (le serie temporali), le dashboard (la visualizzazione), le alerting policy, gli uptime check e i notification channel. Una alerting policy definisce una condizione su una metrica (threshold, metric-absence, forecast) e, allo scatto, instrada le notifiche ai channel configurati (email, PagerDuty, Pub/Sub, webhook, Slack). Gli uptime check sondano endpoint HTTP(S)/TCP da più regioni e possono a loro volta alimentare un alert sulla disponibilità.

La regola SRE che l’esame premia: allerta sui sintomi visibili all’utente (latency, error rate, saturazione, disponibilità), non su ogni singola causa interna. Un alert deve essere azionabile; l’alert fatigue riduce l’affidabilità perché nasconde i segnali veri sotto il rumore, e ogni page inutile è toil.

SLO monitoring e burn-rate alert

Qui si concentra il ragionamento core. Le definizioni esatte: SLI e la misura (es. percentuale di richieste con latenza < 300 ms), SLO e l’obiettivo su quella misura (es. 99,9% su una finestra di 28 giorni), SLA e il contratto commerciale con penali verso il cliente. L’error budget e 1 − SLO: con SLO 99,9% hai lo 0,1% di richieste che possono fallire nella finestra prima di violare l’obiettivo. Cloud Monitoring offre SLO nativi (request-based o windows-based SLI) con visualizzazione del budget residuo.

Il burn-rate alert allerta sul consumo dell’error budget, non su ogni spike isolato. Il burn rate misura la velocità con cui bruci il budget: burn rate 1 consuma esattamente tutto il budget nella finestra dello SLO, burn rate alto lo consuma molto più in fretta. La best practice Google e il multi-window, multi-burn-rate alert: una finestra breve con burn rate alto cattura gli incidenti gravi e rapidi e giustifica una page immediata; una finestra piu lunga con burn rate piu basso cattura i degradi lenti ma persistenti e va in ticket. Cosi riduci sia i falsi positivi sia il tempo di rilevamento, distinguendo cio che sveglia qualcuno di notte da cio che aspetta l’orario lavorativo.

Cloud Logging: log-based metric, sink e Log Analytics

Cloud Logging ingerisce e indicizza i log. Le log-based metric estraggono metriche (counter o distribution) dal contenuto dei log: utili per contare le occorrenze di un pattern (es. i 5xx) e costruirci sopra un’alerting policy. I log sink instradano i log verso destinazioni: BigQuery per l’analisi, Cloud Storage per archiviazione a basso costo e retention lunga, Pub/Sub per lo streaming verso sistemi terzi (es. un SIEM). Un aggregated sink a livello di organization o folder centralizza i log di molti progetti in un colpo solo. Log Analytics consente query SQL direttamente sui log dentro Cloud Logging, senza esportarli altrove: ideale per analisi ad hoc, mentre la retention lunga e le query pesanti ricorrenti spingono verso un sink BigQuery/Storage.

Managed Service for Prometheus e strumentazione

Google Cloud Managed Service for Prometheus e la raccolta gestita di metriche in stile Prometheus dai workload (tipicamente su GKE): mantiene compatibilita PromQL, ma con storage gestito e scalabile, cosi non gestisci ne fai lo scaling di un server Prometheus self-managed. E la scelta quando hai gia instrumentation o exporter Prometheus, oppure metriche applicative custom ad alta cardinalita. La strumentazione dell’applicazione completa l’observability e va tenuta distinta per ruolo: Cloud Trace per la latenza distribuita (tracing), Cloud Profiler per il consumo di CPU e memoria, Monitoring per metriche e alert, Logging per gli eventi.

Trappole tipiche d’esame

  • Alert che scatta a ogni spike momentaneo → burn-rate alert multi-window/multi-burn-rate: alerta sul consumo dell’error budget, non sul singolo picco; combina finestra breve+burn rate alto (page) e finestra lunga+burn rate basso (ticket).
  • Domanda che scambia SLI/SLO/SLA → tienili distinti: SLI e la misura, SLO l’obiettivo interno, SLA il contratto con penali; fissa sempre lo SLO piu stringente dell’SLA per avere margine.
  • Serve interrogare i log con SQL senza spostarli → Log Analytics, non un sink BigQuery: il sink serve a esportare/archiviare, Log Analytics interroga in place.
  • Metriche Prometheus custom dai workload GKE → Managed Service for Prometheus, non un Prometheus self-managed: stessa PromQL, zero gestione dello storage e dello scaling.
  • Contare un pattern nei log per allertare → log-based metric + alerting policy: estrai la metrica dal log, poi costruiscici sopra la condizione.
  • Diagnosi confusa fra lentezza e consumo risorse → Cloud Trace vs Cloud Profiler: Trace per la latenza distribuita, Profiler per CPU/memoria.