"L'observability è roba da aziende con un team SRE." È la scusa più comune per andare in produzione alla cieca. La verità è che nel 2026 un team piccolo può avere log, metriche e tracce serie con costi bassissimi e mezza giornata di setup. Ecco lo stack che usiamo sui nostri progetti, e la filosofia dietro.
I tre pilastri, senza mistica
- Log: cosa è successo, con contesto. Strutturati (JSON), non stringhe libere.
- Metriche: numeri aggregati nel tempo (latenza, throughput, error rate). Poco spazio, tanta informazione.
- Tracce: il viaggio di una singola richiesta attraverso i tuoi servizi. Il pilastro più sottovalutato dai team piccoli, e quello che risolve i bug "impossibili".
Lo standard che ha cambiato le regole: OpenTelemetry
Il motivo per cui oggi un team piccolo può fare observability seria è OpenTelemetry. È lo standard aperto per strumentare il codice: instrumenti una volta con le sue SDK, e poi mandi i dati dove vuoi. Niente più lock-in verso un singolo vendor. Cambi backend senza toccare il codice dell'applicazione. Per chi ha un budget da PMI, è la libertà di scegliere l'opzione economica oggi e cambiare domani senza rifare tutto.
Lo stack che usiamo
Strumentazione
OpenTelemetry SDK sull'app. Per un progetto Next.js, l'auto-instrumentation copre già HTTP, query al database e chiamate esterne senza scrivere quasi nulla. Aggiungiamo span manuali solo sui percorsi critici di business.
Log strutturati
JSON con campi coerenti: timestamp, level, traceId, userId quando lecito. Il traceId nel log è il trucco che collega un errore alla sua traccia completa. Senza, hai due sistemi separati che non si parlano.
Backend
Qui il team piccolo ha scelta. Le opzioni self-hosted mature (lo stack Grafana con Loki per i log, Tempo per le tracce, Prometheus per le metriche) girano su una VM economica. In alternativa, i tier gratuiti o low-cost dei backend gestiti bastano ampiamente per il volume di una PMI. La regola: paghi per l'ingestione dei dati, quindi controlli cosa mandi.
La trappola dei costi: il campionamento
Il conto salato dell'observability non è il tool: è il volume di dati. Un'app trafficata genera milioni di span. Mandarli tutti fa esplodere la bolletta. La soluzione è il sampling: tieni il 100% delle tracce con errore e un campione delle richieste normali (5-10% basta per capire i pattern). Così vedi tutti i problemi e paghi una frazione.
Alert utili, non rumore
L'errore classico è mettere alert su tutto e finire per ignorarli. Noi partiamo da pochi alert che contano: error rate sopra soglia, latenza p95 fuori scala, saturazione risorse. Un alert che non richiede azione è rumore che addestra il team a ignorare gli alert veri. Meglio tre alert affidabili che trenta ignorati.
Verdetto
Nel 2026 non c'è più scusa per andare in produzione senza observability. OpenTelemetry ha reso lo strumento gratuito e portabile; il costo residuo è solo il volume di dati, e lo controlli col sampling. Il ritorno è enorme: il primo incidente serio che risolvi in dieci minuti invece che in un pomeriggio ha già ripagato la mezza giornata di setup. Non è roba da grandi aziende, è igiene di base.