Monitoring, Logging, Tracing: come i progetti di osservabilità falliscono e come salvarli con SLO chiari

Un progetto di Observability in molte aziende inizia con un buon impulso: rilevare i guasti più rapidamente, delimitare con precisione le cause, alleggerire il supporto, rendere i rilasci più sicuri. Nella pratica, tuttavia, l’iniziativa spesso sfocia nel contrario: troppi dashboard privi di significato, troppi allarmi senza priorità, costi di storage e licenze in aumento, e alla fine resta aperta la domanda se l’operatività migliori davvero.

Il difetto di fondo raramente è l’assenza di uno strumento. Più spesso manca la definizione obiettiva e precisa: cosa deve funzionare in modo affidabile per quale catena di servizio o di processo – e come lo misuriamo? Proprio qui gli SLO (Service Level Objectives, valori obiettivo misurabili per un servizio) fungono da binari. Gli SLO collegano la telemetria tecnica (Monitoring, Logging, Tracing) con la realtà operativa, le responsabilità e le vie decisionali.

Questo articolo inquadra i modelli di failure tipici e mostra come riportare Observability sulla giusta rotta con SLO chiari – con attenzione al funzionamento, all’amministrazione, ai dati, alle interfacce, alla manutenzione, alla sicurezza e al rollout.

Monitoring, Logging, Tracing: Che cosa sono – e perché «più dati» non basta?

Observability viene spesso usato come termine ombrello. Per l’esercizio operativo è importante separare nettamente i tre tipi di segnale:

• Monitoring/Metriken: serie temporali aggregate (es. tempi di risposta, tassi di errore, lunghezze delle code). Vantaggio: veloce, economico, facilmente soggetto ad alert. Rischio: senza contesto difficile da interpretare.
• Logging: eventi con contesto (es. ordine creato, validazione fallita, API esterna risponde 503). Vantaggio: dettagliato e auditabile. Rischio: volumi di dati, protezione dei dati, sovrabbondanza di log senza struttura.
• Tracing: tracce di esecuzione distribuite attraverso più componenti (Distributed Tracing). Vantaggio: mostra dove si perde tempo e quale dipendenza è bloccata. Rischio: strumentazione, strategia di sampling, correlazione tra sistemi.

Un errore comune: pensare che raccogliendo solo abbastanza log e trace gli incident si risolvano da soli. Nella realtà la complessità aumenta inizialmente. Senza un quadro d’insieme e criteri di rilevanza, l’Observability diventa un deposito di dati – non uno strumento di governo.

Perché i progetti di Observability falliscono: i modelli più comuni della quotidianità operativa

I seguenti modelli si riscontrano particolarmente spesso in paesaggi aziendali maturi – cioè dove software di business, interfacce e infrastrutture si sono sviluppati nel corso di anni e sono coinvolti più team.

1) Tool-first invece di Service-first: dashboard senza decisione operativa

Viene introdotto un nuovo tool APM o di log e si creano dashboard „per ogni evenienza“. Quello che manca è la domanda: Quale decisione operativa dovrebbe diventare più rapida o migliore grazie a questo? Un dashboard che non aiuta durante un incidente nella pratica è spesso solo decorazione. Sintomo tipico: in caso di guasto i team saltano tra dieci viste senza sapere quale sia attendibile.

2) Flusso di allarmi e affaticamento da allarmi: tutto è critico, quindi niente è critico

Se ogni picco di CPU, ogni singolo errore HTTP e ogni avviso di un agent diventa un allarme, il risultato non è più sicurezza ma assuefazione. Affaticamento da allarmi significa: il personale on-call reagisce più tardi, le escalation diventano poco chiare e i guasti reali passano inosservati. Per la direzione IT è anche un rischio in termini di compliance e dimostrabilità: «Abbiamo avuto allarmi» non prova che si sia reagito in modo mirato.

3) Nessuna correlazione: ticket senza Trace-IDs, log senza contesto

Soprattutto nelle soluzioni software prossime ai processi (workflow vicini all’ERP, percorsi di integrazione, portali) gli incidenti spesso si verificano alle interfacce: REST-API, message broker, import di file, EDI, identity provider. Senza una ID di correlazione (un identificatore univoco che scorre lungo la catena) una singola operazione non può essere tracciata end-to-end. Risultato: molto tempo speso a chiedersi «È un problema nostro o del partner?» invece di fare Root Cause Analysis.

4) Esplosione dei costi dovuta al volume di log e trace

Logging e tracing sono intensivi in termini di dati. Senza una strategia di retention (periodo di conservazione), sampling (campionamento mirato dei trace) e regole di filtraggio, storage e ingest diventano rapidamente costosi – on-prem come nel cloud. Spesso si taglia poi in fretta, peggiorando la qualità dei dati. Questo crea un circolo vizioso: meno fiducia → più log «per sicurezza» → costi più alti.

5) Tematiche di sicurezza e protezione dei dati affrontate troppo tardi

I log contengono rapidamente dati personali (nomi, e-mail, IP, numeri cliente) o contenuti sensibili (token, session-ID, URL interne). Se la prospettiva legale e di security arriva solo dopo il rollout, si profilano due opzioni peggiori: spegnere tutto o «continuare così» con il rischio. L’observability deve fin dall’inizio considerare la classificazione dei dati (esigenza di protezione), il mascheramento/oscuramento e i concetti di accesso.

6) Ownership poco chiara: chi è responsabile operativo per quale servizio?

In molte aziende il team A gestisce l’infrastruttura, il team B l’applicazione, il team C l’integrazione, il team D lo stack database. L’observability mostra i problemi – ma senza un chiaro confine di servizio e obblighi operativi la responsabilità rimane diffusa. Finisce in discussioni su chat invece che in un processo d’incidente strutturato con un passaggio di consegne chiaro.

SLOs come ancora di salvezza: cosa garantisce un buon SLO

SLOs sono obiettivi misurabili per la qualità del servizio. Vengono derivati da SLIs (indicatori di livello di servizio, la metrica misurata). Importante: gli SLOs non sono principalmente «percentuali di disponibilità» per il marketing, ma uno strumento di governo per l’operatività e la prioritizzazione.

Un buon SLO risponde, per un servizio concreto (es. «registrazione ordini nel portale», «caricamento documenti», «elaborazione notturna della fatturazione», «API per registrazioni di magazzino») a tre domande:

• Cosa significa «buono» dal punto di vista dell’utente? (es. «risposta < 1,5 s» o «successo senza errori»)
• Come lo misuriamo in modo oggettivo? (SLI, sorgente dei dati, finestra di misurazione)
• Cosa succede se non viene rispettato? (priorità, sospensione delle modifiche, misure di capacità)

In questo modo l’Observability si trasforma da semplice serbatoio di dati in un sistema che supporta le decisioni: cosa è davvero critico in questo momento? Dove investiamo come prossimo passo? Quali rischi accettiamo consapevolmente?

Da SLAs a SLOs e Error Budgets: inquadramento pratico per i decisori

Nelle aziende esistono spesso SLAs (Service Level Agreements, impegni contrattuali o interni). Gli SLO sono più strettamente radicati nella tecnologia e nell’esercizio e possono servire come leva di controllo interna, anche quando uno SLA è molto generico.

Un meccanismo centrale è l‘Error Budget: se uno SLO richiede ad es. il 99,9% di successo in 30 giorni, è accettato un piccolo “budget” di errori/non disponibilità. All’inizio può sembrare controintuitivo, ma è operativo: permette un bilancio oggettivo tra stabilità e cambiamento (release, migrazioni, ottimizzazione delle prestazioni).

Importante per la pratica: gli Error Budget funzionano solo se la misurazione è corretta e l’organizzazione è pronta a trarne conseguenze. Altrimenti rimane solo un’altra metrica.

Definire SLO che orientino realmente monitoring, logging e tracing

L’errore più frequente con gli SLO è che siano troppo generici (“99,9% di disponibilità dell’app”). Più sensata è una struttura di SLO lungo azioni utente e punti di integrazione. Un approccio pragmatico:

Schritt 1: Servicegrenzen entlang der Prozesskette schneiden

Non definite i “service” secondo l’organigramma, ma secondo l’effetto: ad es. “creare un ordine”, “processare un pagamento”, “registrare il picking”, “interfaccia verso il corriere”. Soprattutto nelle landscape di software aziendale su misura questi confini sono decisivi, perché support e business pensano in queste unità.

Schritt 2: Pro Service 1–3 SLIs, die Nutzerwirkung abbilden

Si sono dimostrati utili SLIs come:

• Tasso di successo di una transazione (ad es. HTTP 2xx/3xx, oppure “Business Success” derivante dalla logica applicativa)
• Latenza sul percorso critico (p95/p99 invece della media)
• Freshness nelle pipeline di dati (“Quanto sono vecchi i dati nel DWH/Reporting?”)

Il punto chiave: non ogni metrica di sistema è un SLI. Una CPU elevata è un sintomo, non un risultato utente. Usate le metriche di sistema per la diagnosi, non come obiettivo.

Schritt 3: Messfenster, Ausschlüsse und Abhängigkeiten sauber festlegen

Uno SLO senza finestra di misurazione è inutile. Definite: 28 giorni a finestra mobile (rolling)? Mensile? Solo finestre temporali business? E chiarite quali dipendenze includere: se l’API di un partner esterno cade, questo conta nel vostro SLO? Per operazioni ed escalation questa chiarezza vale oro.

Schritt 4: Alerting an SLO-Burn-Rate koppeln

Al posto di “Allarme se errori > X in 5 minuti” nella pratica funziona spesso meglio un approccio basato sulla Burn-Rate: quanto velocemente si consuma l’Error Budget? Così priorizzate gli alert in base al rischio per il raggiungimento degli obiettivi — non in base alla rumorosità delle singole metriche. Risultato: meno allarmi, ma più rilevanti.

Architekturfolgen: Was Sie für belastbare Observability technisch einplanen müssen

SLOs sono governance, ma richiedono una base tecnica. In ambienti maturi raramente si tratta di „solo configurare“. Elementi tipici dell’architettura:

Pipeline di telemetria: raccogliere, trasformare, archiviare, rendere disponibili

On-prem o cloud: serve una catena chiara su come la telemetria entra nel sistema. Ciò include agenti/collector, trasporto (coda/buffer), elaborazione (parsing, enrichment, redaction), archiviazione e accesso. Soprattutto per logging e tracing un buffer è importante per assorbire i picchi di carico e, in caso di guasti, non gravare sui sistemi produttivi.

Identità e accessi: chi può vedere quali dati?

I dati di observability sono spesso sensibili. Pianificate ruoli e concetti di tenant: l’operazione vede metriche infrastrutturali, il supporto vede eventi correlati, il reparto di business riceve solo viste di servizio aggregate. Aggiungete audit log per l’accesso a log/trace quando sono rilevanti requisiti normativi.

Igiene dei dati nel logging: struttura, mascheramento, conservazione

«Registriamo tutto» non è un piano. Sono sensati log strutturati (leggibili da macchina), campi definiti (es. servizio, ambiente, ID di correlazione, classe di errore) e mascheramento coerente. Definite la conservazione in base allo scopo: breve per il debug (es. 7–14 giorni), più lunga per eventi di sicurezza o requisiti di audit – ma separata, in modo che costi e diritti di accesso rimangano gestibili.

Tracing mirato, non capillare: sampling e percorsi critici

Il distributed tracing è particolarmente prezioso per le tratte di integrazione e i problemi di performance. Un tracing al 100% su tutta la superficie però è raramente sostenibile e spesso non necessario. Definite regole di sampling (es. più trace in caso di errori o latenza anomala) e focalizzatevi sul percorso critico: Login/SSO, upload, salvataggio dell’ordine, chiamata a interfaccia, elaborazione in coda.

Esempi concreti: SLO per scenari tipici di software aziendale

Per evitare che gli SLO rimangano teorici, ecco tre esempi ricorrenti nelle soluzioni software vicine ai processi. I valori sono intenzionalmente segnaposto – gli obiettivi devono adattarsi a utilizzo, profilo di carico e rischio di processo.

Esempio A: Portale clienti «Creazione ordine»

• SLI Tasso di successo: percentuale di creazioni d’ordine completate con successo (Business Success) in 30 giorni.
• SLI Latenza: p95 del tempo end-to-end per la creazione dell’ordine (incl. DB-commit e risposta di conferma).
• Segnali di diagnostica: deadlock/timeout sul DB, lunghezze delle code per l’elaborazione a valle, classi di errore nel log dell’applicazione (validazione vs. infrastruttura).

Importante: lo SLO dovrebbe misurare il flusso degli utenti, non solo «HTTP 200». Altrimenti si rischia di non rilevare i casi in cui una richiesta è tecnicamente andata a buon fine ma è stata annullata sul piano funzionale.

Esempio B: Interfaccia con un fornitore di servizi di spedizione (REST/EDI)

• SLI: Percentuale delle registrazioni di spedizione che vengono confermate con successo entro X minuti (incl. ritentativi).
• Dipendenze: endpoint esterno, percorso di rete, certificati, limiti di richiesta (rate-limits).
• Diagnosi: codici di errore per categoria, quota di retry, Dead-Letter-Queue (archivio per messaggi che dopo diversi tentativi non sono stati elaborati).

Qui viene fuori il valore aggiunto degli SLO per l’operatività: potete distinguere chiaramente se un incidente riguarda la vostra elaborazione (es. certificato scaduto) o è principalmente responsabilità del partner (es. errori 5xx). Questo riduce il tempo in War Room e migliora la comunicazione con il reparto di business e i partner.

Esempio C: esecuzione notturna «Fatturazione/Elaborazione batch»

• SLI: Percentuale dei job batch che completano con successo entro l’orario di cut-off definito.
• SLI: Numero di interventi manuali per esecuzione (operazioni che attivano i runbook).
• Diagnosi: pattern di lock/deadlock nel database, colli di bottiglia delle risorse, tempi di attesa I/O, valori anomali nei sotto-job.

I processi batch sono classici „blind spots“: gli utenti notano i problemi solo al mattino. Uno SLO con orario di cut-off crea aspettative chiare e permette un alerting mirato che non trasforma ogni piccolo ritardo in un’escalation, ma segnala precocemente i rischi reali.

Rollout e operatività: come mantenere il modello SLO vivo nella pratica quotidiana

La parte più difficile non è la prima definizione, ma il suo consolidamento. L’osservabilità spesso fallisce per limiti dei processi operativi, non per la tecnologia.

Ruoli e responsabilità (senza overhead)

Non avete bisogno di una grande organizzazione SRE, ma di responsabilità chiare:

• Service Owner: responsabile funzionale/tecnico per i target e la prioritizzazione.
• Ops/Plattform: gestisce la pipeline di telemetria, accessi, retention, controllo dei costi.
• On-Call/Support: utilizza alert, runbook, percorsi di escalation; fornisce feedback sulla qualità degli allarmi.

È importante stabilire un ritmo vincolante (mensile o quindicinale): SLO-Review, Top-Alerts, costi/volume, „Unknowns“ aperti.

Integrare runbook e processo di incident con l’osservabilità

Un allarme senza percorso d’azione è rumore. Collegate ogni regola di alert critica a un runbook (breve procedura operativa): cosa verificare? Quali dashboard/view sono rilevanti? Come si esegue l’escalation? Quali azioni immediate sono permesse (es. disabilitare una feature, limitare la coda, modalità di sola lettura)?

Per la direzione IT è anche una leva di scalabilità: buoni runbook riducono la dipendenza dalle singole persone e abbassano il tempo medio di risoluzione (MTTR) senza „eroismi“.

Release e Change Management: gli SLO come segnale di stop, non come decorazione

Quando l’error budget è scarso, le modifiche rischiose dovrebbero essere posticipate o rilasciate con misure di protezione aggiuntive (es. canary, feature flags, finestra di monitoraggio stretta). Non è un fine a sé: previene che la stabilità torni ad essere prioritaria solo dopo un guasto.

Sul piano dei contenuti si può facilmente appoggiarsi agli standard di release management esistenti e collegare internamente riferimenti a contributi su rollout, accettazione e pianificazione del rollback.

Checkliste: Warnsignale, dass Ihr Observability-Projekt aus dem Ruder läuft

• Gli allarmi vengono regolarmente silenziati o ignorati.
• I dashboard sono numerosi, ma nessuno sa quale sia decisivo durante un incident.
• Il volume dei log cresce più rapidamente del valore; la retention viene ridotta „a sentimento“.
• Sicurezza/protezione dei dati viene discussa solo dopo il rollout riguardo ai contenuti nei log.
• Gli incident finiscono spesso con „non è stato possibile riprodurlo“ o „non è chiaro chi sia responsabile“.
• Esiste tracing, ma senza un ID di correlazione coerente attraverso le interfacce.

Se più punti sono veri, quasi sempre conviene un reset tramite SLOs: prioritizzare pochi servizi, definire SLIs chiare, indirizzare la telemetria in modo mirato, semplificare radicalmente la gestione degli allarmi.

Conclusione: SLOs rendono l’osservabilità di nuovo controllabile – e operativamente onesta

Monitoring, logging e tracing sono imprescindibili, ma non risolvono da soli un problema operativo. Un progetto di osservabilità tipicamente non fallisce per mancanza di dati, ma per assenza di chiarezza sugli obiettivi, scarsa qualità degli allarmi, volumi di dati fuori controllo e assegnazione di responsabilità poco chiara. SLOs rimettono l’iniziativa su ciò che conta nella quotidianità aziendale: servizi affidabili lungo la catena di processo, priorità chiare durante l’incident, e decisioni comprensibili e giustificabili tra stabilità, costi e cambiamento.

Se desiderate riallineare l’osservabilità nel vostro panorama o stabilizzare pragmaticamente un setup impantanato, conviene uno sguardo strutturato ai confini dei servizi, alle SLIs, alla pipeline di telemetria e ai processi operativi. Per una prima collocazione e un avvio del progetto pulito Avvio del progetto — Architettura & collaborazione ci raggiunga tramite .

Discutere un progetto o un intervento di modernizzazione con Net-Base.