Osservabilita: logging, metriche e tracing

Sapere cosa succede davvero

In un monolite, quando qualcosa va storto, si guardano i log e spesso basta. In un sistema distribuito di microservizi, una singola richiesta puo attraversare dieci servizi diversi: capire dove e perche qualcosa e andato storto diventa difficile. L'osservabilita e la capacita di comprendere lo stato interno di un sistema a partire dai suoi output esterni.

I tre pilastri

L'osservabilita poggia su tre tipi di segnali complementari.

1. Logging

I log sono record di eventi discreti. Sono insostituibili per il dettaglio, ma diventano ingestibili se non strutturati. La regola fondamentale: log strutturati (JSON) con un identificativo di correlazione.

{
  "timestamp": "2026-03-26T10:12:04Z",
  "level": "error",
  "service": "telemetry",
  "trace_id": "a1b2c3d4",
  "message": "timeout su scrittura time-series db",
  "device_id": "plc-line1-07"
}

Il trace_id permette di ricostruire tutti gli eventi legati alla stessa richiesta, anche tra servizi diversi.

2. Metriche

Le metriche sono valori numerici aggregati nel tempo: richieste al secondo, latenza, uso di CPU e memoria, lunghezza delle code. Sono efficienti da archiviare e ideali per dashboard e alerting. Le metriche rispondono alla domanda "il sistema sta bene?".

3. Tracing distribuito

Il tracing segue una singola richiesta lungo tutto il suo percorso tra i servizi, misurando quanto tempo passa in ciascuno. E lo strumento decisivo per individuare i colli di bottiglia in un'architettura distribuita.

[richiesta] --- API Gateway (5ms)
              └─ Auth Service (12ms)
              └─ Telemetry Service (210ms)  <-- collo di bottiglia
                   └─ Time-series DB (198ms)

Log, metriche o tracing?

I tre segnali rispondono a domande diverse:

• le metriche dicono che qualcosa non va (la latenza e alta);
• il tracing dice dove (quale servizio rallenta);
• i log dicono perche (l'errore specifico).

Usati insieme, permettono di passare dall'allarme alla causa radice in pochi minuti.

Allarmi che servono

Un sistema di alerting efficace evita due estremi: troppi falsi allarmi (che si imparano a ignorare) e troppo pochi (che lasciano scoperti i problemi reali). Conviene allertare sui sintomi percepiti dall'utente (latenza, tasso di errore) piu che sulle cause interne.

Conclusione

L'osservabilita non e un lusso: e cio che separa un sistema che si puo gestire da uno che si subisce. In MUSTNODE integriamo logging strutturato, metriche e tracing fin dalla progettazione, per garantire che le soluzioni restino affidabili e diagnosticabili in produzione.