Osservabilità per Startup: Log, Metriche e Tracce senza Rovinarti

Se scopri i problemi in produzione dai tuoi utenti, non hai osservabilità — hai un canale di supporto.

È una situazione più comune di quanto sembri. L'applicazione va giù, un cliente manda un'email furiosa, il team si mette a controllare i log nella console di AWS, qualcuno dice "a me funziona" e così passano due ore prima che qualcuno trovi il problema. Ti suona familiare?

L'osservabilità non è un lusso delle grandi aziende con team di SRE dedicati. È la capacità di capire cosa sta succedendo nel tuo sistema senza doverlo indovinare. E in una startup, dove ogni incidente può costarti utenti (e il prossimo round di finanziamento), è un investimento che si ripaga dal primo giorno.

I tre pilastri dell'osservabilità

C'è un framework classico che divide l'osservabilità in tre pilastri: log, metriche e tracce. Non sono intercambiabili — ognuno risponde a una domanda diversa.

• Log: Cos'è successo? Sono registrazioni di eventi discreti. Un utente ha tentato il login, una transazione è fallita, un servizio si è riavviato.
• Metriche: Quanto e a che velocità? Sono dati numerici aggregati nel tempo. Latenza media, tasso di errore, utilizzo CPU.
• Tracce: Dove nel sistema? Sono il percorso di una richiesta attraverso più servizi. La request è entrata dall'API gateway, è passata al servizio di autenticazione, ha interrogato il database, ha chiamato il servizio di pagamenti.

Non ti servono tutti e tre dal primo giorno. Ma devi capire quando introdurre ciascuno.

Log: la base di tutto

Ogni sistema genera log. La differenza sta nel generarli in modo utile o nel fare semplicemente console.log("errore qui") e sperare per il meglio.

Il logging strutturato è la prima cosa da implementare. Invece di stringhe sparse, genera log in formato JSON con campi coerenti: timestamp, livello, servizio, messaggio, request ID, utente. Questo permette di cercare, filtrare e aggregare automaticamente.

{
  "timestamp": "2024-06-04T10:23:45Z",
  "level": "error",
  "service": "payment-api",
  "message": "Payment processing failed",
  "requestId": "abc-123",
  "userId": "user-456",
  "errorCode": "GATEWAY_TIMEOUT"
}

I livelli di log devono significare qualcosa. Se tutto è INFO o tutto è ERROR, non hai livelli — hai rumore. Definisci una convenzione chiara: DEBUG per lo sviluppo, INFO per i flussi normali, WARN per situazioni recuperabili, ERROR per guasti che richiedono attenzione.

Centralizza i tuoi log. Se devi fare SSH su tre server diversi per indagare un problema, hai già perso. Opzioni in base al budget:

• Budget minimo: Loki + Grafana (open source, leggero, perfetto per iniziare)
• Cloud nativo: CloudWatch Logs (AWS), Cloud Logging (GCP)
• Tutto in uno: Datadog, New Relic (più costoso, ma più completo)
• Classico: ELK Stack (Elasticsearch, Logstash, Kibana) — potente ma richiede manutenzione

Metriche: i 4 segnali d'oro

Google ha definito i 4 segnali d'oro del monitoraggio, e restano il miglior punto di partenza:

1. Latenza: Quanto ci mette il tuo servizio a rispondere? Non solo la media — i percentili p95 e p99 sono quelli che contano. Se la tua latenza media è 200ms ma il p99 è 5 secondi, hai un problema che la media nasconde.

2. Traffico: Quante richieste stai ricevendo? Ti aiuta a capire i pattern di utilizzo e a rilevare anomalie (picchi inattesi o cali improvvisi).

3. Errori: Che percentuale di richieste fallisce? Sia errori espliciti (HTTP 5xx) sia impliciti (risposte corrette ma con dati errati).

4. Saturazione: Quanto è pieno il tuo sistema? CPU, memoria, disco, connessioni al database. Quando qualcosa si satura, tutto il resto inizia a degradarsi.

C'è una distinzione importante tra metriche applicative e metriche infrastrutturali. Quelle infrastrutturali (CPU, memoria, disco) ti dicono che qualcosa non va. Quelle applicative (richieste al secondo, tasso di errore, latenza per endpoint) ti dicono cosa non va. Ti servono entrambe.

Strumenti:

• Prometheus + Grafana: Lo standard open source. Prometheus raccoglie e memorizza le metriche, Grafana le visualizza. Gratuito, potente, e con un ecosistema enorme.
• Datadog: Metriche, log e tracce in un'unica piattaforma. Eccellente ma costoso — occhio alla fattura.
• New Relic: Simile a Datadog. Ha un tier gratuito decente per iniziare.

Tracce: quando un servizio non basta

Se hai un monolite semplice, probabilmente non ti servono ancora le tracce distribuite. Ma appena hai due o più servizi che comunicano tra loro, le tracce diventano essenziali.

Una traccia distribuita ti mostra il percorso completo di una richiesta attraverso il tuo sistema. Vedi esattamente dove si spende il tempo, dove fallisce e quale servizio sta causando il collo di bottiglia.

OpenTelemetry si è affermato come lo standard per la strumentazione. È open source, vendor-neutral, e supporta log, metriche e tracce. Se vuoi investire tempo nella strumentazione del tuo codice, fallo con OpenTelemetry — così non ti leghi a nessun vendor specifico.

Strumenti:

• Jaeger: Open source, creato da Uber. Perfetto per iniziare con le tracce distribuite.
• Zipkin: Un'altra opzione open source, più semplice di Jaeger.
• Datadog APM / New Relic: Se usi già la loro piattaforma per le metriche, aggiungere le tracce è naturale.

Lo stack adatto alle startup

Non cercare di implementare tutto in una volta. Questa è una progressione sensata:

Fase 1 — Il minimo indispensabile (dal primo giorno):

• Logging strutturato in JSON
• Log centralizzati (Loki + Grafana o CloudWatch)
• Metriche base dell'infrastruttura (quelle che il tuo cloud provider ti dà gratis)
• Alert su errori HTTP 5xx e latenza

Fase 2 — Maturazione (quando hai utenti reali):

• Metriche applicative con Prometheus + Grafana
• Dashboard per servizio con i 4 segnali d'oro
• Alert più sofisticati con livelli di severità

Fase 3 — Distribuzione (quando hai più servizi):

• OpenTelemetry per la strumentazione
• Tracce distribuite con Jaeger o il tuo APM di preferenza
• Correlazione tra log, metriche e tracce (il request ID è la chiave)

Ottimizzazione dei costi: non rovinarti per monitorare

L'osservabilità può diventare costosa rapidamente. Datadog è eccellente finché non vedi la fattura. Ecco alcune strategie:

• Sampling nelle tracce: Non serve tracciare il 100% delle richieste. Un 10-20% di solito basta per individuare i problemi. Traccia sempre le richieste con errori.
• Policy di retention: Ti servono i log di 6 mesi fa? Probabilmente no per il debug quotidiano. Definisci retention brevi per i dati dettagliati e lunghe per le metriche aggregate.
• Livelli di log in produzione: Non inviare log di livello DEBUG in produzione. È rumore costoso. INFO e superiori di solito bastano.
• Alert intelligenti: Ogni alert non azionabile è un costo — non solo economico, ma di attenzione del team.

Alert: l'arte di non generare stanchezza

Una cattiva strategia di alert è peggio di non avere alert. Se il tuo team riceve 50 notifiche al giorno, impareranno a ignorarle tutte — compresa quella importante.

Genera alert sui sintomi, non sulle cause. Alerta quando il tasso di errore sale sopra l'1%, non quando la CPU raggiunge l'80%. La CPU all'80% può essere normale sotto carico; un tasso di errore del 5% non lo è mai.

Ogni alert ha bisogno di un runbook. Se qualcuno riceve un alert alle 3 di notte, deve sapere esattamente cosa controllare per primo. Senza runbook, è panico + SSH + "cos'è questo".

Classifica per severità. Non tutto è urgente. Un errore intermittente su un endpoint poco usato può aspettare domani. Un'interruzione del servizio pagamenti, no.

L'osservabilità come cultura

L'osservabilità non è solo strumenti — è una mentalità ingegneristica. I team che la adottano fin dall'inizio fanno debug più velocemente, deployano con più fiducia e dormono meglio.

In Conectia, gli ingegneri senior che integriamo nel tuo team costruiscono sistemi osservabili di default. Non come add-on dopo il terzo down in produzione, ma come parte fondamentale dell'architettura. Perché quando il tuo sistema cresce e la complessità aumenta, la differenza tra un team che sa cosa succede in produzione e uno che tira a indovinare è la differenza tra scalare e sopravvivere.

---

Il tuo team scopre i problemi in produzione dagli utenti? Parla con un CTO — integriamo ingegneri senior che costruiscono osservabilità fin dal primo deploy.