L'osservabilità si basa su tre pilastri — log, metriche e tracce — e l'obiettivo è rispondere a "cosa c'è di sbagliato e perché" per un sistema troppo grande per essere ispezionato manualmente. In scala, la strategia riguarda correlazione, campionamento e costi.
| Pilastro | Risponde | Strumenti |
|---|
| Metriche | C'è qualcosa che non va? (tassi, latenza) | Prometheus, Grafana |
| Tracce | Dove nel flusso? | OpenTelemetry, Jaeger |
| Log | Cosa è successo esattamente? | ELK, Loki |
Metrics alert ─▶ trace pinpoints the slow service ─▶ logs explain the cause
(broad) (path) (detail)
L'ID trace/correlazione deve attraversare le etichette delle metriche, le righe di log e gli span, in modo da poter pivotare tra di essi.
log line: level=error trace_id=abc123 service=payments msg="gateway timeout"
^^^^^^^^^^^^^^^ same id appears in the trace + metrics
✓ Standardize: OpenTelemetry across all services
✓ Use structured (JSON) logs — queryable, not grep-only
✓ Sample traces (e.g. keep all errors + 1% of success) to control cost
✓ Define SLOs and alert on symptoms (latency/error rate), not noise
✓ RED/USE method for dashboards (Rate, Errors, Duration)
Loggare tutto al 100% è inaccessibile e sommerge il segnale. Campiona, struttura e avvisa in base agli SLO.
Con centinaia di servizi, non puoi fare SSH e guardare — l'osservabilità è l'unico modo per comprendere il comportamento in produzione.
La strategia vincente è correlata, campionata e guidata dagli SLO: affronta i problemi reali rapidamente senza farti fallire per l'archiviazione dei dati di telemetria o seppellire on-call nel rumore.
Una raccolta di domande di colloquio IT con risposte dettagliate — da Junior a Senior.
Dona