Come leggere i log del server quando qualcosa si rompe

Qualcosa si rompe, la pagina diventa bianca e all’improvviso il server sembra una stanza chiusa a chiave, senza finestre.

I log sono il modo per aprire una finestra. Non sono magia e non servono solo agli amministratori di sistema a tempo pieno. Un log è semplicemente un registro scritto di ciò che è accaduto: chi ha richiesto una pagina, cosa ha tentato di fare l’applicazione, cosa non ha funzionato e quando.

Il trucco non sta nel leggere ogni riga, ma nel trovare la pista giusta.

Cosa sono i log del server, in parole semplici

Pensa ai log come all'unione di uno scontrino, della registrazione di una telecamera di sicurezza e di un diario di bordo.

Uno scontrino ti indica cosa è stato richiesto. La telecamera mostra l'istante esatto in cui è successo. Il diario ti fornisce la spiegazione del problema: permesso negato, file non trovato, database non disponibile, memoria esaurita.

Di solito il server esegue più componenti contemporaneamente. Può esserci un web server che accoglie i visitatori, un’applicazione che genera le pagine o gestisce le richieste, un database che salva le informazioni e dei processi in background che lavorano in silenzio. Ogni componente può avere un proprio log dedicato.

Ecco perché un singolo problema può lasciare indizi in più posti. Un visitatore vede una generica pagina di errore, il log dell’app segnala che la password del database è errata, mentre il log del web server indica solo che l’app ha restituito un errore.

I log non esistono per spaventarti con del gergo tecnico. Esistono per rispondere a una domanda molto più semplice: cosa è cambiato, cosa è fallito e dove?

Parti dal sintomo, non dal file

Quando qualcosa si rompe, si è tentati di aprire subito un file di log e iniziare a scorrere. È come aprire un dizionario per correggere una frase: prima ti serve la frase.

Parti sempre dal sintomo visibile:

• Il sito è completamente irraggiungibile?
• Si rompe solo una pagina specifica?
• Il login non funziona, ma la homepage sì?
• Il problema si è verificato dopo un rilascio, un aggiornamento, un rinnovo del certificato o una modifica al dominio?
• Succede a tutti gli utenti o soltanto a uno?

Dopodiché, individua l'orario. I log sono ordinati cronologicamente, quindi sapere che “si è rotto intorno alle 14:10” è molto più utile di un generico “si è rotto oggi”. Se conosci il minuto esatto, puoi ignorare gran parte del rumore di fondo.

Se l’intero sito è irraggiungibile, il problema potrebbe trovarsi a livello di rete, dominio, firewall o web server. È lo stesso ragionamento a livelli spiegato in perché un sito non si carica. Se il sito si carica ma è dolorosamente lento, i log possono aiutare, ma potresti anche avere a che fare con una forte pressione su CPU, RAM, disco o traffico, come illustrato in perché un server diventa lento.

I tre posti in cui di solito compaiono gli errori

La maggior parte delle attività di risoluzione dei problemi per principianti si riduce a tre tipi di log.

Il primo è il log del web server. Registra le richieste in entrata e le relative risposte. Se qualcuno richiede una pagina che non esiste, vedrai un errore 404. Se l’app va in crash dietro le quinte, vedrai un 500. Questi numeri sono codici di stato HTTP, ovvero brevi etichette che indicano l’esito di ciascuna richiesta web.

Il secondo è il log dell’applicazione. È qui che spesso si nascondono i dettagli più utili. Un web server può limitarsi a dire “l’app ha fallito”, mentre l’app può specificare “impossibile connettersi al database”, “variabile d'ambiente mancante”, “permesso negato” o “il provider email ha rifiutato il messaggio”.

Il terzo è il log di sistema. Riguarda il server stesso: servizi che si avviano o si arrestano, spazio su disco in esaurimento, RAM insufficiente o processi in background terminati dal sistema. Se un’app sparisce senza mostrare un errore chiaro, il log di sistema può spiegarne il motivo.

Se usi i container, c'est un ulteriore livello da considerare: i log dei container. Un container è come una scatola etichettata che racchiude un’app e le sue dipendenze. Mantiene tutto in ordine, ma significa anche che ogni container ha i propri log interni. Se questo approccio è nuovo per te, la guida per principianti a Docker su un server ti fornirà tutto il contesto necessario in parole semplici.

Leggi i log come una timeline

Una volta identificato il sintomo e l’orario approssimativo, leggi i log come una sequenza temporale (timeline), non come un romanzo.

Cerca la prima riga anomala comparsa prima dell’errore visibile all’utente. Gli errori successivi sono spesso solo delle conseguenze indirette. Se la connessione al database fallisce, l’app genererà altri cinque avvisi perché non riesce a caricare utenti, sessioni, prodotti o impostazioni. Il primo errore è la tubatura rotta; tutto il resto è solo acqua sul pavimento.

Fai attenzione ai comportamenti ripetuti. Un singolo login fallito è normale, ma centinaia di tentativi falliti possono indicare un attacco in corso o un'integrazione configurata male. Un’immagine mancante può essere un fatto trascurabile, ma se ogni pagina fa riferimento allo stesso file mancante, c’è un errore nel percorso o nel processo di pubblicazione.

Impara anche a distinguere gli avvisi (warning) dagli errori. Un avviso è come una spia gialla sul cruscotto: è utile notarlo, ma non sempre rappresenta la causa del problema. Un errore assomiglia di più a un motore che si spegne all'improvviso. Alcuni avvisi rimangono nei log per mesi senza avere alcuna relazione con il malfunzionamento di oggi.

Leggere correttamente i log porta quasi sempre a porsi una domanda più precisa, piuttosto che a trovare una risposta immediata. “Il sito non funziona” diventa “l’app non riesce a raggiungere il database”, “il certificato SSL è scaduto” oppure “il progetto sta puntando alla cartella sbagliata”. Arrivare a quella domanda più specifica è già un enorme passo avanti.

La scorciatoia

Server Manager ti aiuta mantenendo le varie componenti collegate a ciò che ti interessa davvero: il sito o l’applicazione. Quando qualcosa si rompe, non devi sforzarti di ricordare quale servizio appartiene a quale progetto, quale dominio punta dove o se il certificato di quel sito è quello corretto.

Questo riduce drasticamente le cause d'errore più comuni evidenziate dai log: un certificato sbagliato o scaduto, un progetto che interferisce con un altro, un dominio orientato verso la destinazione errata o una vecchia configurazione che nessuno comprende più a distanza di mesi. Il vero beneficio non sta nell'eliminare del tutto il troubleshooting, ma nel poterlo avviare da una struttura pulita e leggibile.

Quando il server rimane ordinato nel tempo, i log smettono di sembrare un cassetto pieno di cianfrusaglie e diventano un quaderno ben etichettato. In questo modo puoi associare l’errore all’app giusta, al dominio corretto e alla modifica recente molto più velocemente.

Il tuo risultato: meno tentativi, campo più ristretto più in fretta

Non serve comprendere ogni singola riga di log per utilizzarli con efficacia.

Ti bastano il sintomo, l’orario, il livello probabile del problema e il primo errore significativo: elementi sufficienti per passare dal panico a una lista ristretta di possibili cause.

Quando i log smettono di sembrare un muro di testo incomprensibile, smetti di tirare a indovinare. Puoi capire subito se il problema riguarda il sito, l’app, il database, il certificato, il server o una modifica recente — ed è esattamente lì che la risoluzione dei problemi diventa semplice e gestibile.