Osservabilità nell'hosting: perché il monitoraggio da solo non basta più

Distinguere chiaramente tra monitoraggio e osservabilità

Monitoraggio risponde soprattutto a domande operative già note. Verifica, ad esempio, se un sito web è raggiungibile, se un certificato TLS sta per scadere, se lo spazio di archiviazione sta per esaurirsi o se la percentuale di risposte HTTP 5xx supera un valore prestabilito. Tali controlli garantiscono affidabilità nella gestione quotidiana, poiché trasformano le anomalie previste in allarmi concreti.

L’osservabilità non sostituisce questi controlli, ma li integra nei casi in cui gli errori non siano chiaramente identificabili. Se la pagina iniziale risponde con un codice HTTP 200, ma le singole operazioni di checkout richiedono un tempo insolitamente lungo, la domanda fondamentale non è solo se il servizio sia in funzione. Si tratta piuttosto di capire cosa sia successo esattamente durante quella specifica richiesta, quale componente abbia richiesto più tempo e quale contesto spieghi tale anomalia.

La differenza è quindi di natura pratica, non concettuale: un allarme relativo all’aumento dei tassi di errore mette in evidenza un sintomo rilevante per l’utente. L’analisi successiva, tuttavia, richiede spesso più contesto di quanto possa fornire un singolo grafico. Buona Osservabilità pertanto mette in relazione i segnali, anziché considerare affrettatamente un singolo valore di misura come causa.

I tre livelli di telemetria nell'hosting

Nell’hosting, i segnali rilevanti si generano su tre livelli. L’infrastruttura comprende CPU, memoria, supporti di dati, rete e risorse di macchine virtuali o container. Al di sopra di questo si trova il livello di traffico con connessioni, tempi di risposta alle richieste, codici di stato, TLS e il comportamento del reverse proxy o del server web. Il terzo livello è costituito dall’applicazione e dalle sue dipendenze: ad esempio PHP, database, cache, coda o un servizio di pagamento esterno.

Valori di host poco evidenti non sono indice di una buona esperienza utente. Una query al database, un session store che causa blocchi o una chiamata API lenta possono rallentare singole pagine, anche se la CPU e la RAM mostrano riserve sufficienti. Al contrario, un elevato carico della CPU durante una campagna non costituisce automaticamente un malfunzionamento, purché le richieste vengano elaborate con successo e rapidamente entro i limiti previsti.

Il livello di traffico combina entrambe le prospettive. In NGINX, il tempo di richiesta documentato comprende l'elaborazione dal momento della ricezione del primo byte della richiesta fino all'invio dell'ultimo byte della risposta. Se questo valore aumenta, non è ancora possibile stabilire se la responsabilità sia da attribuire al server web, all'applicazione o all'upstream. Tuttavia, indica in modo significativo quali richieste e quali intervalli di tempo dovrebbero essere esaminati più da vicino.

Ne consegue una separazione delle funzioni a livello di organizzazione aziendale. Allarme basato sui sintomi si concentra sulla disponibilità, sul tasso di errore o sulla latenza percepibile e segnala la necessità di intervenire. Le metriche relative alle risorse, i tempi di upstream e le code interne, invece, supportano la diagnosi nei dashboard o durante la ricerca degli errori. Prometheus raccomanda questa separazione affinché i team di monitoraggio non siano sovraccaricati da semplici indicatori di causa.

Collegare metriche, log e tracce

Se si considera una singola richiesta HTTP, i tre segnali di telemetria forniscono prospettive diverse. Metriche raggruppano molti processi in modelli basati sul tempo, come la latenza, il traffico o il tasso di errore. I log registrano singoli eventi, ad esempio un timeout con un messaggio di errore. Le tracce, invece, tracciano il percorso di quella specifica richiesta attraverso il server web, l’applicazione, la cache, il database e i servizi esterni.

Una traccia è composta da span. Ogni span rappresenta una fase operativa, come l’esecuzione del controller, l’accesso alla cache, un’operazione SQL o una chiamata API in uscita, e contiene dati temporali e attributi di classificazione. Un identificativo di traccia collega le fasi della richiesta complessiva; un identificativo di span distingue la rispettiva sotto-operazione. Ciò consente di individuare dove si è verificato un ritardo, senza dover dedurre la causa da una singola metrica.

I log diventano particolarmente significativi quando sono strutturati e contengono il contesto della traccia e dello span. In questo modo, un team può passare direttamente da una traccia lenta ai messaggi di errore, alle indicazioni di ritentativo o agli eventi di timeout relativi alla stessa richiesta. Il contesto attivo può arricchire i log esistenti; prima dell’utilizzo, tuttavia, è necessario verificare quali campi vengano effettivamente esportati dall’ambiente di esecuzione specifico.

Un percorso tipico di telemetria è il seguente: l’applicazione, il server web e l’infrastruttura generano dati; un collector o un agente li riceve, li filtra o li arricchisce; un backend li archivia e li visualizza. Partendo da un allarme, l’analisi passa quindi da una metrica alla traccia e al log. OpenTelemetry offre un framework aperto a questo scopo, ma il grado di maturità varia: Tracciamento-Le specifiche, l'API, l'SDK e il protocollo sono considerati stabili, mentre gli SDK delle metriche possono presentare livelli di sviluppo diversi a seconda del linguaggio.

Ridurre sistematicamente i tempi di pagamento lenti

Un controllo di uptime andato a buon fine e una pagina iniziale con codice di stato HTTP 200 dimostrano solo che il percorso verificato risponde in quel momento. Non escludono che singoli carrelli, verifiche dell’indirizzo o autorizzazioni di pagamento possano risultare lenti o non andare a buon fine. Per un negozio online, quindi, la latenza osservata durante il checkout, insieme al tasso di errore, costituisce un punto di partenza significativo per l’analisi.

Innanzitutto, le serie temporali indicano se il problema è concentrato in un determinato periodo, su un percorso o in una classe di stato. Se, ad esempio, la latenza delle richieste di checkout aumenta e si verificano singoli errori, viene generato un relativo Traccia Interessante: i suoi "spans" suddividono la durata complessiva in fasi operative quali applicazione, cache, database e chiamata esterna. Una traccia descrive quindi il percorso di una specifica richiesta, ma non ne identifica automaticamente la causa certa.

Se, ad esempio, si nota una lunga chiamata al servizio di pagamento, i log strutturati correlati forniscono ulteriori informazioni. Gli identificatori di traccia e di span consentono di cercare i messaggi di timeout, i tentativi di ripetizione o i dettagli di errore corrispondenti alla stessa richiesta. I log strutturati facilitano questa mappatura automatica, a condizione che il contesto attivo venga effettivamente trasferito nei dati di log esportati.

La tabella illustra delle correlazioni, non dimostra un nesso causale. Un intervallo di pagamento lento può essere causato, ad esempio, dal fornitore, da un malfunzionamento della rete, da una connessione esaurita o dal comportamento di riprova della propria applicazione. Proprio le dipendenze esterne devono quindi essere valutate insieme allo stato, alla finestra temporale, al testo dell'errore e alla gestione nell'applicazione.

Impostare correttamente il contesto per le richieste

Una configurazione minima valida non parte dal numero massimo possibile di campi, ma da dati affidabili relativi alla classificazione. Tra questi figurano il nome del servizio, l’ambiente e la versione di distribuzione, nonché il metodo HTTP e la classe di stato. Questi attributi consentono di individuare se un deterioramento riguarda solo l’ambiente di produzione, una versione specifica o un singolo servizio; dovrebbero essere utilizzati in modo coerente nelle metriche, nei log e nelle tracce.

Il contesto della richiesta deve percorrere il percorso dal proxy all’applicazione e da lì al database, alla cache o ai servizi esterni. Se tale trasmissione non è già presente nella combinazione utilizzata di proxy, ambiente di esecuzione e framework, è necessaria un’ulteriore strumentazione. Una traccia visibile all’ingresso dell’applicazione non dimostra quindi che ogni chiamata a monte o ogni log possa essere automaticamente associato.

Dopo un aggiornamento di un plugin o di un tema, un sito WordPress può diventare più lento, anche se le risorse dell’host inizialmente non presentano anomalie. In tal caso, è possibile confrontare i dati del server web relativi alla durata delle richieste e ai codici di stato con i dati applicativi legati a PHP e i tempi del database. In NGINX, il tempo di richiesta documentato comprende l’elaborazione dall’acquisizione del primo byte della richiesta fino all’invio dell’ultimo byte della risposta; tuttavia, da solo non è sufficiente per individuare il collo di bottiglia.

In pratica, ne risulta una catena verificabile: il tempo di risposta è cambiato solo dopo la nuova versione di deployment? Alcuni percorsi mostrano tempi di esecuzione più lunghi, oppure è la durata delle singole operazioni sul database ad aumentare? Chi desidera inoltre comprendere i limiti strutturali di carico e scalabilità di un CMS, può consultare l’articolo su Limiti di scala di WordPress. La telemetria non sostituisce questa valutazione tecnica, ma fornisce gli elementi concreti su cui basarla.

È importante anche considerare i limiti della standardizzazione: OpenTelemetry definisce come stabili la specifica di tracciamento, l’API, l’SDK e il protocollo, mentre il livello di maturità degli SDK per le metriche può variare a seconda del linguaggio. Prima di procedere con l’implementazione, il team dovrebbe quindi verificare, per il proprio linguaggio e la propria libreria, quali segnali, attributi e informazioni di contesto siano effettivamente disponibili.

Valutare gli obiettivi di latenza e i tempi di risposta del database

Gli indicatori di servizio dovrebbero rappresentare una caratteristica percepibile, come ad esempio le richieste di checkout andate a buon fine entro un determinato periodo di tempo o la percentuale di risposte errate. Da ciò è possibile ricavare un obiettivo di servizio. Pertanto, un elevato carico della CPU rimane un valore diagnostico importante, ma non comporta necessariamente un’escalation se gli obiettivi degli utenti continuano a essere rispettati.

Un valore medio può nascondere le richieste brevi e quelle molto lente. Un percentile Risponde a un’altra domanda: p95 indica il valore al di sotto del quale si colloca il 95% dei valori osservati. Non rappresenta né l’esperienza media degli utenti né una prova del fatto che tutte le altre richieste fossero accettabili. Il tasso di errore, il traffico e l’intervallo di tempo considerato sono elementi da tenere in considerazione nella valutazione.

Per le latenze raggruppate su più istanze, valgono Istogrammi Spesso utile: i bucket possono essere aggregati e da essi è possibile calcolare approssimativamente i quantili. Al contrario, i quantili calcolati in precedenza a partire dai riepiloghi di diverse repliche non devono essere mediati, poiché ciò non produce un quantile complessivo statisticamente significativo.

Un obiettivo puramente illustrativo potrebbe essere: il 95% delle richieste di checkout andate a buon fine dovrebbe essere completato in meno di 300 millisecondi. Da ciò non deriva alcuna garanzia di prestazioni né un valore limite valido per ogni negozio. Mostrano semplicemente la logica di ragionamento: se l’obiettivo non viene raggiunto, le tracce aiutano a suddividere il tempo; gli span del database possono poi distinguere le classi di query sospette dal carico generale.

Non è necessario che il database sia in stato di errore. Un health check positivo e valori normali della CPU non escludono che poche query lente possano dominare un percorso critico. Solo la combinazione tra distribuzione della latenza, percentuali di tempo di traccia e contesto di errore o di attesa mostra se valga la pena approfondire un caso isolato, un modello in crescita o un altro elemento nel percorso della richiesta.

Integrare gli allarmi e la ricerca dei guasti

Le regole di allarme dovrebbero innanzitutto rilevare ciò che gli utenti notano effettivamente: servizi non raggiungibili, aumento delle percentuali di errori 5xx o tempi di risposta costantemente troppo elevati. Tali allarmi basati sui sintomi forniscono un chiaro motivo per agire. Il carico della CPU, le code, lo spazio libero sul file system o i tempi di upstream rimangono fattori importanti, ma spesso sono più adatti alla diagnosi che come unico fattore scatenante di uno stato di allerta.

In caso di un numero elevato di risposte 502 o 504, l’analisi inizia quindi con la portata e la tempistica: quali percorsi, host, regioni o versioni di distribuzione sono interessati? Il codice di stato indica solo che la comunicazione ha subito un'interruzione in una fase dell'elaborazione o che ha richiesto troppo tempo. Non dimostra né che il proxy inverso funzioni in modo errato, né che la causa sia da ricercarsi nell'applicazione o in un determinato upstream.

Nella fase successiva, i dati del proxy, quali la durata della richiesta, la durata dell’upstream, la classe di stato e il numero di connessioni attive, aiutano a circoscrivere l’errore nel tempo. NGINX, ad esempio, documenta la durata della richiesta come l’intervallo di tempo che intercorre tra la lettura del primo byte della richiesta e l’invio dell’ultimo byte della risposta. Si tratta di un’utile indicazione della durata complessiva, ma senza ulteriori dati non consente di distinguere le componenti relative all’applicazione, alla rete e alle dipendenze.

Successivamente, una traccia interessata conduce dall’arrivo della richiesta all’applicazione, alla cache, al database o a un servizio esterno. I log applicativi strutturati con contesto di traccia e span possono evidenziare timeout, interruzioni di connessione o tentativi di ripetizione. Questo collegamento è possibile solo se il contesto viene trasmesso attraverso i componenti coinvolti e l’arricchimento dei log è stato effettivamente configurato.

Per l'operatività, ne risulta una procedura affidabile: confermare l'allarme sulla base del sintomo, individuare le richieste interessate e circoscrivere l'intervallo di tempo, confrontare i valori del proxy e delle risorse, esaminare una traccia rappresentativa e infine passare ai log corrispondenti. Segnali correlati alla causa Accorciano la ricerca, ma non sostituiscono la verifica delle modifiche, delle dipendenze e dei messaggi di errore. La correlazione mostra quali osservazioni si verificano contemporaneamente; non costituisce però una prova delle cause.

Un elevato carico di lavoro del server durante una campagna può essere normale, mentre un singolo accesso lento al database, in presenza di un utilizzo della CPU nella norma, può compromettere il processo di checkout. I dashboard dovrebbero quindi rappresentare sia l’obiettivo dell’utente sia la catena diagnostica. In questo modo, il monitoraggio rimane responsabile delle anomalie prevedibili, mentre la telemetria correlata supporta l’analisi di un quadro di errore specifico.

Gestione del volume dei dati, della protezione dei dati e della cardinalità

Con l'aumentare del traffico, raramente è opportuno conservare ogni richiesta in modo permanente come traccia completa. Campionamento limita il volume dei dati e i costi senza rinunciare completamente all'analisi. La selezione deve essere commisurata al rischio: errori, transazioni insolitamente lente e percorsi critici delle query sono solitamente più preziosi di un insieme casuale e omogeneo di tracce non significative.

Nel tail sampling, la decisione viene presa solo quando una traccia è completa o quasi completa. Ciò consente, ad esempio, di dare la priorità alle tracce con stato di errore o di lunga durata. Poiché ciò richiede lo stato e il buffer, il componente di telemetria deve essere sufficientemente dimensionato; un sovraccarico può comportare lo scarto dei dati e la mancanza proprio delle tracce rilevanti.

Il collector, l’agente e il percorso di esportazione devono quindi essere essi stessi oggetto di monitoraggio. Sono determinanti, ad esempio, gli errori di ricezione e di esportazione, le code, i ritardi e i dati scartati. Se questi segnali vengono a mancare o se la perdita di dati aumenta, una dashboard vuota non deve essere considerata prova di un servizio funzionante. La pipeline di telemetria è una dipendenza operativa e necessita di limiti ben definiti.

La minimizzazione dei dati inizia prima dell’esportazione: selezionare gli attributi in modo mirato, verificare regolarmente i dati inseriti e rimuovere i valori sensibili tramite filtri, redazione o operazioni di trasformazione. In particolare, le intestazioni, i cookie, i corpi completi e gli identificatori meritano un controllo esplicito dell’autorizzazione. Anche i campi apparentemente tecnici possono contenere dati personali o riservati.

Per quanto riguarda le metriche, occorre inoltre considerare la cardinalità Fondamentale: ogni nuova combinazione di valori di etichetta genera un’ulteriore serie temporale. Gli identificatori di utente, sessione o ordine non sono quindi etichette adeguate. Prometheus consiglia, in presenza di circa 100 valori possibili o in caso di forte crescita degli stessi, di prendere in considerazione un modello di dati alternativo. Per casi specifici, sono più adatte le tracce o i log strutturati con un periodo di conservazione limitato.

Introdurre l’osservabilità in modo adeguato e graduale

L'approccio più adeguato dipende dall'architettura e dal rischio, non dalla massima gamma di funzionalità possibile. Un piccolo sito web statico trae vantaggio principalmente dai controlli di raggiungibilità, dal monitoraggio della scadenza dei certificati TLS, dagli stati HTTP e dalle risorse di base. In questi casi, il tracciamento completo dell'applicazione spesso comporta un dispendio di risorse senza un corrispondente guadagno in termini di informazioni.

Nel caso di un CMS o di un negozio online, alla vista di base segue solitamente la correlazione tra server web, applicazione e database. Solo quando più servizi o container interagiscono tra loro, il trasferimento coerente del contesto diventa particolarmente importante per i percorsi critici. AWS raccomanda di considerare l’osservabilità a livello di applicazione e delle dipendenze e di collegare gli indicatori tecnici agli obiettivi aziendali e degli utenti.

I servizi CDN, DNS, di pagamento, di spedizione o di posta elettronica fanno parte del percorso reale della richiesta, ma sono controllabili solo in misura limitata. I propri span e le caratteristiche relative alla latenza o agli errori possono evidenziare quando è intervenuta una dipendenza. Ciò non comporta un’attribuzione automatica di colpa: le condizioni di rete, i tentativi di riconnessione, la propria configurazione dei timeout e lo stato del servizio devono essere valutati nel loro insieme. Per questioni relative alla disponibilità e al routing, l’articolo su Strategie multi-CDN nell'hosting l'analisi degli aspetti relativi alla selezione e al failover.

Un’implementazione pragmatica definisce innanzitutto pochi obiettivi orientati all’utente e i relativi indicatori. Successivamente vengono limitati i campi di dati, la conservazione e i diritti di accesso, prima che il tracciamento venga gradualmente integrato nei processi critici per l’azienda. Il campionamento non rappresenta in questo caso una lacuna, bensì una scelta controllata, a condizione che i casi di errore e di latenza vengano conservati in modo mirato e che la pipeline di selezione sia gestita in modo trasparente.

L'osservabilità non sostituisce né un'architettura solida né i test, i backup o una procedura di gestione degli incidenti. Essa fornisce contesto che consente di prendere decisioni Per questi compiti: i team riescono a individuare meglio quali percorsi degli utenti sono interessati, quali componenti dovrebbero essere verificati e quali ipotesi sono supportate dai dati. Il valore aggiunto aumenta con domande chiare e una telemetria accuratamente circoscritta, non con una raccolta il più ampia possibile di dati grezzi.