Come monitorare le prestazioni applicative

Un gestionale rallenta alle 9:15, quando il personale apre ordini, anagrafiche e documenti nello stesso momento. Un e-commerce risponde, ma il checkout impiega cinque secondi e le conversioni calano. In questi casi, capire come monitorare prestazioni applicative non significa riempire una dashboard di grafici: significa isolare rapidamente la causa, stimarne l'impatto e intervenire senza compromettere la continuità operativa.

Per una PMI, le prestazioni non sono un tema esclusivamente tecnico. Un'applicazione lenta genera attività manuali, assistenza interna, clienti che abbandonano un acquisto e decisioni prese su dati non aggiornati. Il monitoraggio utile collega quindi il comportamento del codice, del database e dell'infrastruttura agli effetti sui processi aziendali.

Come monitorare le prestazioni applicative: cosa misurare

La prima scelta corretta è evitare una definizione generica di “applicazione lenta”. Una pagina che si carica in due secondi può essere accettabile per un'area informativa, ma non per una schermata di cassa, un pannello di magazzino o una procedura che viene ripetuta centinaia di volte al giorno. Le soglie devono dipendere dalla funzione e dal contesto d'uso.

Le metriche essenziali sono quattro: tempo di risposta, tasso di errore, volume delle richieste e saturazione delle risorse. Il tempo di risposta mostra quanto l'utente attende; il tasso di errore evidenzia richieste fallite o degradate; il volume aiuta a leggere i picchi; CPU, memoria, disco e rete indicano se il problema è nell'ambiente che ospita l'applicazione.

Queste metriche, da sole, non bastano. Una media di 400 millisecondi può nascondere una minoranza di richieste da dieci secondi, proprio quelle che bloccano gli utenti. Per questo conviene osservare anche i percentili, in particolare il p95 e il p99: misurano l'esperienza delle richieste più lente, senza farsi ingannare dalla media.

Su un e-commerce, per esempio, vanno distinti catalogo, ricerca, carrello, login e checkout. Su un gestionale, conviene separare le operazioni critiche come esportazioni, importazioni, chiusure contabili, sincronizzazioni con servizi esterni e generazione di documenti. Non tutte le pagine hanno lo stesso peso operativo, quindi non tutte meritano lo stesso livello di attenzione.

Partire dagli obiettivi di servizio, non dallo strumento

Prima di installare agenti o configurare alert, occorre definire quali livelli di servizio sono accettabili. Un obiettivo concreto può essere: il 95% delle richieste al checkout deve completarsi entro due secondi, mentre gli errori del pagamento devono restare sotto una certa soglia. Per un gestionale, l'obiettivo potrebbe riguardare il tempo di apertura di una pratica o la conclusione di una sincronizzazione entro una finestra prestabilita.

Questi indicatori vengono spesso chiamati SLI e SLO. Il nome conta fino a un certo punto; conta di più la disciplina con cui vengono concordati. Un obiettivo irrealistico produce allarmi continui e perde credibilità. Un obiettivo troppo permissivo fa apparire sano un servizio che gli utenti percepiscono come lento.

Le soglie devono considerare anche gli orari di maggiore carico. Un report complesso può richiedere più tempo durante la notte senza creare problemi, ma lo stesso ritardo alle 10 del mattino può rallentare l'intera operatività. Monitorare bene significa distinguere i casi normali dalle anomalie che richiedono azione.

Osservabilità: metriche, log e tracce devono parlarsi

Il monitoraggio efficace non dipende da una sola fonte di dati. Le metriche mostrano che qualcosa sta peggiorando, i log aiutano a capire che cosa è successo e le tracce distribuite ricostruiscono il percorso di una richiesta attraverso componenti diversi.

Prendiamo una richiesta di checkout. Può attraversare il frontend React, un'API Node.js o Laravel, il database, un servizio di pagamento, un sistema di fatturazione e una coda per l'invio delle notifiche. Se il tempo totale cresce, una traccia consente di capire se il ritardo è dovuto a una query SQL, a un servizio esterno lento, a un worker bloccato o a una chiamata ripetuta inutilmente.

I log devono essere strutturati e contestualizzati. Registrare un semplice messaggio di errore è spesso insufficiente. Sono utili un identificativo della richiesta, l'utente o il tenant quando appropriato, l'endpoint coinvolto, il codice di risposta, la durata e le informazioni tecniche necessarie alla diagnosi. Bisogna però evitare di inserire nei log password, token, dati sanitari, informazioni di pagamento o altri dati personali non necessari.

Le tracce hanno un costo in termini di raccolta e conservazione. In applicazioni ad alto traffico non sempre è sensato tracciare ogni richiesta. Il campionamento è un compromesso ragionevole, a condizione di mantenere una copertura maggiore per le transazioni critiche e per le richieste lente o errate.

Controllare database, code e dipendenze esterne

Molti problemi attribuiti al server applicativo nascono altrove. Un database con query non indicizzate, lock prolungati o connessioni esaurite può rallentare tutto il sistema anche con CPU apparentemente libera. È necessario osservare durata delle query, query più frequenti, numero di connessioni, lock, tempi di attesa e crescita delle tabelle.

Le code meritano la stessa attenzione. Se una piattaforma usa worker per email, importazioni, aggiornamenti di catalogo o integrazioni, il numero di job in attesa e la loro età indicano rapidamente se il sistema sta accumulando ritardo. Un worker attivo ma incapace di svuotare la coda non è un servizio sano: è un collo di bottiglia in formazione.

Anche le dipendenze esterne devono essere misurate. Gateway di pagamento, servizi di spedizione, CRM, ERP, provider email e API di terze parti possono degradare una transazione senza produrre un errore netto. Conviene misurare durata, errori e timeout per ogni integrazione, distinguendo ciò che dipende dalla propria infrastruttura da ciò che dipende da un fornitore.

Monitoraggio infrastrutturale e applicativo: entrambi servono

Su VPS, Docker e Nginx, l'infrastruttura resta parte della prestazione percepita. CPU costantemente alta, memoria insufficiente, swap attivo, spazio disco in esaurimento, file descriptor saturi o errori del reverse proxy possono trasformare un'applicazione corretta in un servizio instabile.

Allo stesso tempo, limitarsi a monitorare il server porta a diagnosi parziali. Un container può essere in salute mentre una rotta applicativa restituisce errori, una migrazione ha rallentato una tabella o una cache non viene più popolata. Il controllo di disponibilità deve quindi includere verifiche sintetiche: richieste periodiche che simulano un'azione essenziale, come autenticazione, ricerca prodotto o invio di un ordine di prova.

Il monitoraggio reale degli utenti completa il quadro quando il canale web è rilevante. Può mostrare differenze tra dispositivi, reti geografiche o browser che non emergono dai test eseguiti dal server. Non sostituisce i controlli sintetici: li affianca, perché misura l'esperienza effettiva anziché una sola condizione controllata.

Alert utili, non rumore operativo

Un alert deve essere associato a una decisione. Se nessuno sa che cosa fare quando arriva, non è un alert: è una notifica che distrae. La regola è semplice: avvisare su sintomi che richiedono una risposta, non su ogni variazione della telemetria.

Un picco momentaneo di CPU può essere normale durante un'elaborazione prevista. Un alert diventa utile se la saturazione persiste, coincide con tempi di risposta in aumento o provoca errori. Allo stesso modo, un singolo errore 500 può essere gestibile; una crescita costante degli errori su checkout, login o API di integrazione richiede una priorità diversa.

La classificazione per gravità deve rispecchiare l'impatto. Un problema che blocca la vendita o l'accesso al gestionale richiede reperibilità e una procedura di escalation. Un rallentamento su una funzione secondaria può generare un ticket da affrontare nell'orario lavorativo. Confondere i livelli porta a due esiti ugualmente dannosi: intervenire troppo tardi o ignorare gli avvisi perché sono troppi.

Usare i dati per migliorare l'applicazione

Il monitoraggio non termina con il ripristino di un servizio. Dopo ogni anomalia significativa conviene ricostruire la sequenza: quando è iniziata, quali componenti erano coinvolti, quale metrica si è mossa per prima, quale intervento ha risolto il problema e come evitare che si ripeta.

Questo lavoro produce priorità tecniche più affidabili rispetto alle impressioni. Se una query compare ogni giorno tra le più lente, un indice o una revisione del flusso può avere più valore di una riscrittura ampia. Se un endpoint diventa critico solo durante campagne commerciali, si può pianificare cache, capacità aggiuntiva o code asincrone prima del prossimo picco.

In Noventra affrontiamo il monitoraggio come parte della gestione dell'intero stack: applicazione, database, container, web server e sicurezza devono fornire segnali coerenti. Un cruscotto ben costruito non serve a dimostrare che esistono metriche. Serve a far prendere decisioni più rapide quando un processo aziendale rischia di fermarsi.

La domanda da porsi non è quante metriche raccogliere, ma quale informazione permetterebbe domani di intervenire prima che un rallentamento diventi un problema operativo. Da lì si costruisce un monitoraggio che resta utile anche quando l'applicazione cresce.