La versione in 30 secondi#

Monitoring: Il mio sistema funziona? (Sì/No)
Observability: Perché il mio sistema si è rotto? (Analisi della causa principale)
Logging: Cosa è successo? (Registro eventi)

Il monitoring risponde a domande SÌ/NO. L'observability ti permette di fare qualsiasi domanda sul tuo sistema. Il logging è raccolta dati; monitoring e observability sono analisi.

La maggior parte dei team usa i termini in modo intercambiabile. Questo crea confusione, gonfiamento del budget e — peggio — punti ciechi durante le emergenze.

Perché è importante (il vero costo della confusione)#

Il tuo team di engineering ha appena rilasciato del nuovo codice. 30 minuti dopo, il processamento dei pagamenti rallenta. Succedono tre cose:

Senza Observability (vecchio modo):

Scatta l'avviso: "Tempo di risposta API pagamenti >3 secondi"
L'engineer reperibile apre la dashboard: vede il grafico del tempo di risposta. Punto.
L'engineer comincia a tirare a indovinare: "È un problema di database? Rete? Deploy recente?"
L'engineer controlla i log manualmente: 500.000 righe di log in 30 minuti. Dove guardare?
Dopo 45 minuti di debugging: il nuovo codice ha aggiunto una query SQL lenta
Durata incidente: 1 ora. Perdita di fatturato: ~$7.000

Con Observability (modo moderno):

Scatta l'avviso: "Tempo di risposta API pagamenti >3 secondi"
L'engineer reperibile apre la dashboard di observability
La dashboard suggerisce automaticamente: "Il nuovo codice ha aggiunto una query N+1 alla tabella payment_verification"
L'engineer salta direttamente alla query, la ottimizza
Durata incidente: 5 minuti. Perdita di fatturato: ~$600

La differenza: 55 minuti risparmiati + $6.400 di fatturato salvato da un singolo incidente.

Per un'azienda con 2-3 incidenti al mese, il ROI dell'observability è facilmente $100K+/anno.

Cos'è il monitoring? (la vecchia base)#

Il monitoring risponde a: Il mio sistema sta funzionando in questo momento?

Monitoring = domande booleane (Sì/No)#

Il server risponde alle richieste? (Sì/No)
Il tempo di risposta è <2 secondi? (Sì/No)
La CPU del database è <80%? (Sì/No)
Il tasso di errore è <1%? (Sì/No)
Il test sintetico è passato? (Sì/No)

Come funziona il monitoring#

Raccogli una metrica: Controlla il tempo di risposta ogni 60 secondi
Confronta con la soglia: Se il tempo di risposta >2s, scatta l'avviso
Avvisa se sforata: Chiama l'engineer reperibile

Il monitoring è binario. Tu definisci le regole; il sistema le fa rispettare. Quando una regola si rompe, ti chiamano. Questo è il monitoring.

Il limite del monitoring#

Il monitoring ti dice che qualcosa è sbagliato, ma non perché sia sbagliato.

Esempio:

Avviso: "CPU del database al 95%"
Il monitoring mostra: il grafico CPU che spara verso l'alto
Ma non sai: perché la CPU è alta? Quale query? Quale utente? Nuovo codice? Picco di traffico improvviso?

Devi scavare manualmente per scoprirlo. Qui entra in gioco l'observability.

Cos'è l'observability? (l'approccio moderno)#

L'observability risponde a: Perché il mio sistema non sta funzionando?

Observability = domande infinite#

Invece di chiedere "X è vero?", fai qualsiasi domanda sul tuo sistema:

"Quale query ha causato il picco di CPU?"
"Perché il tempo di risposta è aumentato dopo questo deploy?"
"Quali utenti sono interessati?"
"Cosa è cambiato nel sistema 2 minuti prima che scattasse l'avviso?"
"Quali richieste hanno richiesto >5 secondi nell'ultima ora?"
"Come si confronta il tasso di errore di oggi con quello della scorsa settimana a quest'ora?"

Con l'observability, puoi rispondere a QUALSIASI domanda sul comportamento del sistema.

I 3 pilastri dell'observability#

Pilastro 1: Metrics (cosa è successo, in numeri)

Tempo di risposta: 1,2s
Tasso di errore: 0,5%
Query database al secondo: 1.200
Uso memoria: 4,2GB
Sono dati aggregati e riassunti

Pilastro 2: Logs (cosa è successo, in dettaglio)

"L'utente john@usegum.com ha fatto login"
"La query di verifica pagamento ha richiesto 1,2s"
"Connessione database chiusa per timeout"
Eventi dettagliati e granulari. Tanto volume.

Pilastro 3: Traces (come una richiesta si è mossa nel sistema)

L'utente invia il pagamento → handler API → query database → chiamata gateway pagamenti → servizio email
Mostra il percorso completo che una richiesta ha fatto e dove ha speso tempo
Tracing distribuito tra servizi

Come funziona l'observability#

Strumenta tutto: Aggiungi logging a tutti i percorsi di codice
Raccogli i dati: Cattura metrics, logs e traces
Conserva i dati: Storage a lungo termine (settimane/mesi di storico)
Interroga liberamente: Fai qualsiasi domanda sul comportamento del sistema
Correla automaticamente: "Questo picco di CPU è correlato a questo percorso di codice; questo errore è correlato a questa azione utente"

Monitoring vs Observability: a confronto#

Aspetto	Monitoring	Observability
Tipo di domanda	X è vero?	Perché X sta succedendo?
Punti dati	10-50 metriche	Milioni di punti dati
Tempo di setup	Veloce (1 ora)	Più lungo (1-2 settimane)
Curva di apprendimento	Semplice (dashboard)	Ripida (linguaggio di query)
MTTR (Mean Time To Repair)	30-60 min	5-10 min
Costo	$100-500/mese	$1.000-5.000/mese
Ideale per	"Il mio sistema è up?"	"Perché il mio sistema si è rotto?"
Quando lo superi	>5 servizi, >10 avvisi	Funziona ancora su scala

Il sistema a 3 livelli (come operano davvero la maggior parte dei team)#

Livello 1: Monitoring (le basi — ti serve questo)#

Uptime monitoring standard per tutti:

Disponibilità del sito: la homepage risponde in <2s?
Salute API: gli endpoint critici rispondono?
Dipendenze di terze parti: Stripe è raggiungibile?
Basi infrastrutturali: CPU, memoria, spazio disco

Esempi di tool: UptimeRobot, Pingdom, Hyperping, Datadog (tier base)

Costo: $20-100/mese

Tempo di setup: 1-2 ore

Quando ti serve: Giorno 1, piccola startup con 1-2 servizi

Livello 2: Logging di base (i dettagli — probabilmente ti serve)#

Quando il monitoring dice che qualcosa è sbagliato, dove guardi?

I log mostrano cosa è successo:

Messaggi di errore: "Database connection timeout"
Dettagli della richiesta: User ID, percorso della richiesta, codice di risposta
Eventi di business: "Utente ha acquistato un articolo", "Pagamento fallito"
Eventi di sistema: "Server avviato", "Pressione memoria rilevata"

Esempi di tool: Datadog, New Relic, Better Stack, ELK Stack

Costo: $100-500/mese

Tempo di setup: 2-4 ore (base), 1-2 settimane (completo)

Quando ti serve: Quando il monitoring ti avvisa 5+ volte/giorno e non riesci a trovare la causa principale

Livello 3: Observability completa (la comprensione — ti serve su scala)#

Una volta che hai i log, vuoi correlarli con metriche e traces.

L'observability ti permette di:

Vedere quale percorso di codice ha causato l'avviso
Capire come una richiesta si è mossa attraverso 10 servizi
Correlare comportamento utente → comportamento applicazione → impatto infrastrutturale

Esempi di tool: Datadog (full stack), Dynatrace, New Relic, Splunk

Costo: $1.000-10.000+/mese

Tempo di setup: 2-4 settimane (completo)

Quando ti serve: >10 microservizi, >5 engineer, sistema distribuito complesso

Esempio reale: avviso di tempo di risposta API#

Scenario: Il tempo di risposta della tua API pagamenti è schizzato a 3 secondi (normale: 500ms)

Solo con monitoring#

Scatta l'avviso: "Tempo di risposta API pagamenti 3000ms"
Vedi: Un grafico che mostra il picco del tempo di risposta
Pensi: "È un problema di database? Picco di carico? Bug?"
Controlli: CPU server (normale), memoria (normale), connessioni (normale)
Controlli: deploy recenti (nessuno nelle ultime 2 ore)
Controlli: log del traffico (traffico raddoppiato)
Controlli: log database (un sacco di query su payment_verification)
INFINE: trovi la query lenta nei log
Tempo trascorso: 45 minuti

Con observability#

Scatta l'avviso: "Tempo di risposta API pagamenti 3000ms"
Vedi: La dashboard di observability mostra automaticamente:
  - Quale percorso di codice è lento: payment_verification
  - Quale query: SELECT * FROM users ... (rilevata query N+1)
  - Quale utente l'ha attivata: john@usegum.com
  - Quando è iniziato: Esattamente quando è stato deployato il nuovo codice
  - Richieste interessate: 150 su 2.000
Vedi: Trace che mostra lo stack trace esatto del codice lento
Risolvi: Ottimizzi la query
Tempo trascorso: 5 minuti

La differenza:

Senza observability: 45 minuti per la causa principale
Con observability: 5 minuti per la causa principale
Fatturato salvato: ~$6.500 per un singolo incidente

Logging: la base (ma non è monitoring né observability)#

Il logging è raccolta dati. Monitoring e observability sono analisi dati.

Cos'è il logging#

Scrivere eventi in una posizione centrale:

// Nella tua applicazione
logger.info("User logged in", {
  user_id: "12345",
  timestamp: "2026-02-20T14:23:45Z",
  ip_address: "203.0.113.42"
})

logger.error("Payment verification failed", {
  user_id: "12345",
  amount: 99.99,
  error: "Stripe API timeout",
  duration_ms: 5000
})

I log vengono scritti. Conservati. Disponibili per la ricerca.

Limiti del logging#

Troppi dati: Un'applicazione web tipica genera oltre 1.000 righe di log al secondo. Cercare in 1M di righe di log all'ora è doloroso.

Nessun contesto: Una riga di log dice "Pagamento fallito" ma non ti dice se fa parte di un attacco, di un problema sistemico o se è isolato.

Nessuna correlazione: Vedere un singolo log di fallimento pagamento non ti mostra i 500 fallimenti simili che stanno succedendo contemporaneamente.

Il logging è la base per l'observability#

Hai bisogno di buon logging per costruire observability. Ma il logging da solo non è observability.

Quando usare cosa (albero decisionale)#

Stai partendo?
├─ Sì → Usa solo Monitoring
│       (UptimeRobot, Hyperping)
│       Focus: il sistema è up?
│       Costo: $20-50/mese
│       Setup: 1 ora

Stai facendo debug di 5+ incidenti al mese?
├─ Sì → Aggiungi Logging
│       (Datadog, Better Stack)
│       Focus: cosa è successo?
│       Costo: aggiungi $100-300/mese
│       Setup: 2-4 ore base, 1-2 settimane completo

Stai eseguendo >5 microservizi o >10 engineer?
├─ Sì → Passa a Observability
│       (Datadog full stack, Dynatrace, Splunk)
│       Focus: perché è successo?
│       Costo: $1.000+/mese
│       Setup: 2-4 settimane

Sei a scala enterprise (100+ engineer)?
└─ Sì → Ti serve tutto
        (Observability completa + tool specializzati)
        Costo: $5.000+/mese
        Setup: continuo, 1-2 persone dedicate

Idee sbagliate comuni#

Idea sbagliata 1: "L'observability è solo logging fancy"#

Realtà: L'observability è la combinazione di metrics + logs + traces, più la capacità di correlarli automaticamente.

Il logging fa parte dell'observability, ma non è il tutto. Ti servono anche metriche (tempo di risposta, tasso di errore) e traces (tracing distribuito).

Idea sbagliata 2: "Più logging = miglior observability"#

Realtà: 1 milione di righe di log sono inutili se non puoi cercarle. Qualità > Quantità.

Logga in modo strategico:

Logga gli errori (sempre)
Logga gli eventi di business (acquisto, login, pagamento)
Logga i problemi di prestazioni (query lente, timeout)
Non loggare ogni chiamata di funzione (crea rumore)

Idea sbagliata 3: "Il monitoring può intercettare qualsiasi problema"#

Realtà: Il monitoring intercetta i problemi che corrispondono alle tue regole. I problemi al di fuori delle regole non vengono rilevati.

Esempio: Hai una regola "avvisa se tempo di risposta >3 secondi". Ma il tempo di risposta è 1,5 secondi normalmente e 2,5 secondi dopo il deploy. È un AUMENTO del 67% ma non supera la tua soglia. Il monitoring non avvisa. L'observability sì.

Idea sbagliata 4: "L'observability sostituisce il monitoring"#

Realtà: L'observability richiede il monitoring come base.

Hai comunque bisogno di avvisi per i problemi critici. Ma hai anche bisogno della capacità di investigare.

Idea sbagliata 5: "L'observability deve per forza essere costosa"#

Realtà: Esistono molti strumenti di observability open source. Puoi costruire il tuo.

Ma richiedono sforzo di engineering per essere mantenuti. Per la maggior parte dei team, le piattaforme SaaS di observability ($1.000-5.000/mese) sono più economiche che assumere qualcuno per mantenere l'infrastruttura.

Costruire una strategia di observability#

Fase 1: Base di monitoring (mese 1)#

Imposta uptime monitoring core
Monitora gli endpoint critici
Verifica da 3 region (elimina i falsi allarmi)
Routing degli avvisi (critico = chiamata, warning = Slack)

Costo: $50/mese Tool: UptimeRobot, Hyperping o Nova Uptime

Fase 2: Aggiungi logging (mese 2-3)#

Strumenta il codice con logging strutturato
Logga errori, eventi di business, metriche di prestazioni
Imposta aggregazione dei log
Costruisci dashboard per cercare i log

Costo: Aggiungi $100-200/mese Tool: Datadog, Better Stack, ELK Stack

Fase 3: Tracing distribuito (mese 4-6)#

Aggiungi tracing per tracciare le richieste tra i servizi
Correla traces con log
Identifica colli di bottiglia nel flusso delle richieste

Costo: Aggiungi $200-500/mese Tool: Datadog, New Relic, Jaeger

Fase 4: Observability completa (mese 6+)#

Combina metrics + logs + traces
Avvisi automatici basati su anomalie
Analisi della causa principale alimentata da ML
Analisi storica e rilevamento dei trend

Costo: $1.000-5.000+/mese Tool: Datadog, Dynatrace, Splunk

Confronto strumenti di observability#

Tool	Monitoring	Logging	Tracing	Prezzo	Ideale per
UptimeRobot	Eccellente	No	No	$10/mese	Siti semplici
Hyperping	Eccellente	Limitato	No	$24/mese	SaaS, team API
Datadog	Eccellente	Eccellente	Eccellente	$100+	Enterprise, all-in-one
Better Stack	Eccellente	Eccellente	Limitato	$50/mese	Mid-market
New Relic	Eccellente	Eccellente	Eccellente	$100+	APM enterprise
Splunk	Limitato	Eccellente	Eccellente	$200+	Enterprise, data analysis
ELK Stack	No	Eccellente (self-hosted)	Limitato	Self-hosted	Team attenti ai costi
Dynatrace	Eccellente	Eccellente	Eccellente	$500+	Grandi enterprise
Grafana	Eccellente	Limitato	Limitato	$50+ (self-hosted)	Preferenza open source

Riassunto: Monitoring vs Observability#

Monitoring = "Il mio sistema sta funzionando?" (Sì/No)

10-50 metriche
Avvisi basati su regole
Dashboard semplici
Ottimo per siti web, app semplici
Costo: $20-100/mese

Observability = "Perché il mio sistema è rotto?" (Causa principale)

Milioni di punti dati
Querying a forma libera
Dashboard complesse
Essenziale per i microservizi
Costo: $1.000-5.000+/mese

Logging = "Cosa è successo?" (Raccolta dati)

Eventi grezzi
Storico ricercabile
Base per l'observability
Necessario per il debugging

La maggior parte dei team ha bisogno di: Monitoring + Logging come base, poi aggiungere Observability man mano che si scala.

Quando fare upgrade:

Solo monitoring: Funziona per 1-2 servizi
- Logging: Funziona per 3-5 servizi, 2-3 engineer
- Observability: Richiesta per >10 servizi, >5 engineer, dipendenze complesse

Non investire troppo in observability troppo presto (costoso e complesso). Non aspettare troppo (l'MTTR peggiora con l'aumentare della complessità).

Prossimi passi#

Se hai solo il monitoring: Aggiungi logging strutturato questa settimana. È a basso costo e ad alto impatto.
Se hai i log: Costruisci una dashboard per correlare gli errori con i deploy. Inizia a capire le cause principali.
Se sei su scala: Investi nel tracing distribuito. È la chiave per fare debugging di sistemi complessi.

Pronto a passare dal monitoring all'observability? Inizia con l'uptime monitoring di Nova Uptime come base, poi aggiungi logging e tracing man mano che cresci.