Costruire una web app è solo metà del lavoro. L’altra metà — quella che distingue un prodotto reale da un prototipo — è tenerla in vita ogni giorno: sapere in tempo reale se funziona, perché un utente ha ricevuto un errore e dove sta rallentando. Questo è il tema dell’osservabilità web app, ed è una delle competenze che applico costantemente quando sviluppo e gestisco prodotti come apicco.app, tandemops.app e indelio.eu.
Quando un’azienda affida lo sviluppo di un’applicazione a uno sviluppatore, il rischio più sottovalutato è questo: il software viene consegnato, sembra funzionare, e poi nessuno sa cosa succede in produzione. Io lavoro in modo diverso. Costruisco l’app e la infrastruttura che mi permette di osservarla, perché un prodotto senza osservabilità è una scatola nera che si rompe nel momento peggiore.
Cos’è l’osservabilità di una web app
L’osservabilità è la capacità di capire cosa sta accadendo dentro un sistema guardando ciò che produce verso l’esterno. Non è solo “il sito è online o offline” (quello è il monitoraggio di uptime), ma una visione molto più profonda che si fonda su tre pilastri:
- Log: il racconto cronologico di ciò che l’applicazione fa, riga per riga.
- Metriche: numeri aggregati nel tempo — richieste al secondo, tempi di risposta, uso di CPU e memoria, errori per minuto.
- Tracce: il percorso di una singola richiesta attraverso i vari componenti del sistema, per capire dove si perde tempo.
Messi insieme, questi tre elementi rispondono alle domande che contano davvero per un’azienda: l’app è veloce? Gli utenti incontrano errori? Stiamo per esaurire le risorse del server? E soprattutto: come lo scopro prima che lo scopra il cliente?
Il problema che risolve: niente più sorprese in produzione
Senza osservabilità, la gestione di una web app diventa reattiva. Un utente segnala che “non funziona”, e si parte a indovinare. Con un sistema di osservabilità ben costruito, invece, l’app stessa mi avvisa: ricevo una notifica quando il tasso di errori supera una soglia, vedo esattamente quale endpoint è lento e in quale momento, e ho lo stack trace completo dell’errore prima ancora che qualcuno mi scriva.
Per un’azienda questo significa due cose concrete: meno tempi di inattività e problemi risolti in minuti anziché in ore. Quando opero un’applicazione gestionale su cui un cliente fa girare il suo lavoro quotidiano, questa differenza è tutto.
Il mio stack tecnico per l’osservabilità
Costruisco infrastrutture di osservabilità prevalentemente self-hosted, sui server che gestisco. Questo mi dà controllo totale sui dati, costi prevedibili e nessun lock-in con piattaforme esterne a pagamento. Ecco gli strumenti che uso più spesso:
Logging strutturato
La prima regola è non scrivere log come testo libero, ma in formato strutturato (tipicamente JSON). Ogni riga di log porta con sé contesto: ID della richiesta, utente, durata, codice di stato. Nel backend — che sia Node.js, un’API in Express o un servizio in Python — configuro librerie di logging che producono output coerente e facilmente interrogabile.
Aggregazione e ricerca dei log
I log non servono se restano sparsi su decine di container. Li centralizzo con Grafana Loki, che raccoglie i flussi da tutti i servizi e li rende ricercabili da un’unica interfaccia. In alternativa, per progetti più complessi, lo stack ELK (Elasticsearch, Logstash, Kibana). Con una query trovo in pochi secondi tutte le righe relative a un singolo utente o a un singolo errore.
Metriche e dashboard
Per le metriche uso Prometheus, che interroga periodicamente le applicazioni e raccoglie valori numerici, e Grafana per visualizzarli in dashboard chiare. Tempi di risposta, throughput, memoria, errori HTTP: tutto su un cruscotto che racconta la salute del sistema a colpo d’occhio.
Tracciamento degli errori
Per catturare le eccezioni del codice integro un sistema di error tracking self-hosted (ad esempio GlitchTip, compatibile con l’ecosistema Sentry). Quando il codice frontend in React o il backend lancia un errore, ricevo l’evento completo: messaggio, stack trace, browser, passi che hanno portato al problema. È la differenza tra “qualcosa non va” e “la riga 42 del modulo pagamenti fallisce su Safari”.
Alerting
L’ultimo tassello sono gli avvisi. Configuro regole che, al superamento di soglie critiche, mi notificano immediatamente via email o messaggistica. Tutto gira in container Docker orchestrati con Portainer, dietro reverse proxy con SSL gestito, sulla stessa infrastruttura HestiaCP e Nginx che uso per ospitare i progetti dei clienti.
Cosa dimostra tutto questo sulla mia capacità di consegnare
Un’azienda che cerca uno sviluppatore non vuole solo codice: vuole un prodotto che resti in piedi. La capacità di progettare l’osservabilità fin dall’inizio è ciò che separa chi “scrive un’app” da chi costruisce e gestisce un servizio. Quando integro logging, metriche e alert in un progetto, sto dicendo al cliente che mi assumo la responsabilità del prodotto anche dopo il lancio.
È lo stesso approccio con cui mantengo l’infrastruttura cloud e on-premise di più attività: ogni applicazione che sviluppo nasce già pronta per essere osservata, misurata e migliorata nel tempo. Non è un extra opzionale, è il modo corretto di consegnare software professionale.
Vuoi una web app costruita e gestita per durare?
Se la tua azienda ha bisogno di un’applicazione web o di un sito su misura — sviluppato con uno stack moderno e progettato per funzionare in modo affidabile anche dopo la consegna — posso aiutarti dall’idea al prodotto in produzione, occupandomi anche di hosting, sicurezza e osservabilità.
Scopri i miei progetti su cornelcaba.com e contattami qui per parlare del tuo: trasformiamo la tua idea in una web app solida, veloce e sotto controllo.
