Cloud Monitoring: metriche, dashboard, uptime check e alerting

Cloud Monitoring raccoglie automaticamente le metriche di sistema dai servizi Google Cloud (CPU, disco e rete per le VM, richieste per i load balancer) e le espone in Metrics Explorer e nelle dashboard, che componi con grafici personalizzati. Concetto chiave: il metrics scope. Un progetto “scoping” può osservare le risorse di più progetti, così centralizzi il monitoring multi-progetto senza duplicare la configurazione.

Gli uptime check verificano da più località la raggiungibilità di un endpoint pubblico (HTTP, HTTPS o TCP) e sono la base per allertare sulla disponibilità di un sito. Le alerting policy definiscono una condizione (es. “CPU > 80% per 5 minuti”) e, quando scatta, inviano notifiche tramite i notification channel (email, SMS, Slack, PagerDuty, Pub/Sub, webhook, app mobile). Ricorda: una policy senza notification channel valuta la condizione ma non avvisa nessuno. I ruoli tipici sono roles/monitoring.viewer per la sola lettura e roles/monitoring.editor per creare dashboard e policy.

Cloud Logging: log, log-based metric e sink

Cloud Logging centralizza i log; li consulti e filtri in Logs Explorer col linguaggio di query, oppure da CLI con gcloud logging read. Da un pattern ricorrente puoi derivare una log-based metric (di tipo counter o distribution) con gcloud logging metrics create: trasformi eventi testuali (es. errori HTTP 500) in una metrica su cui costruire grafici e alerting policy.

Il Log Router instrada ogni log entry verso uno o più sink. Un sink combina un filtro con una destinazione ed è lo strumento per l’export:

  • BigQuery per analisi SQL e query interattive;
  • Cloud Storage per archiviazione a lungo termine e conformità a basso costo;
  • Pub/Sub per lo streaming verso sistemi esterni (es. un SIEM di terze parti come Splunk).

Crei un sink con gcloud logging sinks create NOME DESTINAZIONE --log-filter=.... Attenzione al punto più insidioso: il sink ha una writer identity (un service account) che devi autorizzare sulla destinazione (es. roles/bigquery.dataEditor sul dataset o roles/storage.objectCreator sul bucket), altrimenti l’export fallisce. I ruoli di gestione sono roles/logging.viewer e roles/logging.admin.

Ops Agent ed Error Reporting

Le VM di Compute Engine espongono di default solo metriche dall’hypervisor (CPU, disco, rete): non la memoria in-guest né i log applicativi. Per ottenere metriche di memoria/processi e i log di sistema e applicazione devi installare l’Ops Agent (l’agente unificato che sostituisce i vecchi Monitoring e Logging agent). Il service account della VM deve avere roles/monitoring.metricWriter e roles/logging.logWriter perché l’agente possa scrivere.

Error Reporting aggrega e raggruppa automaticamente errori ed eccezioni delle applicazioni in esecuzione, evidenziando i problemi ricorrenti senza dover scandagliare i log a mano.

Diagnosticare un problema operativo

Il flusso tipico: parti da un alert o da un uptime check fallito, apri la dashboard per individuare la metrica anomala, poi passi a Logs Explorer filtrando per risorsa e finestra temporale per isolare la causa; Error Reporting ti indica l’eccezione dominante. Se mancano dati di memoria o i log dalla VM, il sospetto numero uno è l’Ops Agent non installato o senza permessi.

Trappole tipiche d’esame

  • Serve la memory/disk usage in-guest di una VM → installa l’Ops Agent: le metriche base di Compute Engine non includono la memoria; senza agente non la vedi.
  • Export dei log verso Splunk o un SIEM esterno → sink verso Pub/Sub: lo streaming real-time passa da Pub/Sub, non da BigQuery né da Cloud Storage.
  • Archiviazione dei log a lungo termine e basso costo per compliance → sink verso Cloud Storage: BigQuery serve l’analisi SQL, non l’archiviazione economica.
  • L’export del sink fallisce → autorizza la writer identity sulla destinazione: concedi roles/bigquery.dataEditor o roles/storage.objectCreator al service account del sink.
  • Allerta su un pattern nei log (es. errori 500) → log-based metric + alerting policy: prima trasformi il log in metrica, poi ci costruisci sopra la policy.
  • Monitorare più progetti in un’unica vista → metrics scope: aggiungi i progetti al progetto scoping, non creare configurazioni separate.