Come leggere i log del server: 404, bot e lentezze
Cosa mostra ogni parte di una riga di log del server, come individuare errori 404 e richieste lente, e come distinguere visitatori reali dai bot.
Team rabbitclipPubblicato: 5 min di lettura
In breve
Una riga di log del server contiene l'indirizzo che ha fatto la richiesta, la data, la pagina richiesta, il codice di stato restituito e le informazioni sul browser, tutto in un'unica riga. Leggerle con regolarità risponde a tre domande: quali pagine restituiscono un errore 404, quale parte del traffico sono visitatori reali rispetto ai bot, e quali richieste rispondono più lentamente del normale. Tutti e tre sono segnali visibili molto prima che diventino un vero reclamo.
Quando il sito di un'azienda di facility management riceve solo poche centinaia di visite al mese ma il server registra decine di migliaia di richieste al giorno, quella differenza deriva quasi sempre dal traffico bot. Senza guardare i log, è difficile capire da dove nasca quel divario.
Come si legge una riga di log?
Un log del server è la registrazione che il server tiene di ogni richiesta ricevuta; il formato «combined» predefinito di Nginx e Apache elenca l'indirizzo IP di origine, la data, l'indirizzo richiesto, il metodo HTTP, il codice di stato, il numero di byte inviati, la pagina di riferimento e l'identità del browser, in quest'ordine.
In una riga tipica compare prima l'IP del visitatore, poi data e ora tra parentesi quadre, quindi l'indirizzo richiesto tra virgolette che inizia con GET o POST, seguito subito dal codice di stato a tre cifre, 200 per successo, 404 per non trovato, 500 per errore del server, la quantità di dati inviati e infine l'identità del browser tra virgolette alla fine. Imparare questo ordine una volta sola basta per leggere qualunque file di log in seguito.
Cosa mostrano davvero gli errori 404?
Un 404 significa che la pagina richiesta non è stata trovata sul server. Deriva da un link rotto, da un'altra pagina che punta a un indirizzo non più esistente, da una migrazione in cui i vecchi indirizzi non sono mai stati reindirizzati, oppure da un bot che prova un indirizzo casuale.
Rivedere i 404 nei log con regolarità mostra quale link rotto colpisce davvero i visitatori reali; un 404 che si ripete spesso e proviene da un browser genuino merita di essere corretto per primo, un tentativo isolato di bot può di solito essere ignorato.
Come distinguere i visitatori reali dal traffico bot?
Il primo punto da controllare è il campo user-agent; i bot noti dei motori di ricerca si identificano apertamente. Ma un bot malevolo presenta spesso uno user-agent che sembra un browser reale, quindi quel solo campo non basta.
- Più di una richiesta al secondo dallo stesso indirizzo IP, cosa che non corrisponde a un comportamento umano
- Richieste ripetute concentrate solo su determinate pagine, un modulo di accesso, una casella di ricerca
- Richieste che vanno direttamente a pagine profonde senza mai aver consultato prima robots.txt
- Uno user-agent realistico abbinato a intestazioni mancanti che un browser reale invierebbe normalmente, lingua, cookie
Come trovare le richieste lente nei log
Il tempo di risposta non compare nella maggior parte dei formati di log predefiniti, ma sia Nginx sia Apache offrono una variabile separata per aggiungerlo; una volta aggiunta, ogni richiesta mostra in millisecondi quanto ha impiegato a rispondere.
Con quel campo presente, filtrare le richieste oltre una soglia, ad esempio un secondo, permette di trovare quale pagina, quale query o quale integrazione sta causando il rallentamento. È un segnale che si può cogliere prima che un cliente si lamenti che il sito è lento.
Per quanto tempo tenere i log, e chi dovrebbe controllarli?
I file di log non vengono conservati per sempre; lo spazio su disco è limitato e la maggior parte degli hosting applica una rotazione predefinita da poche settimane a pochi mesi. Poiché un'analisi di sicurezza dopo un incidente può richiedere log più vecchi, vale la pena fissare questo periodo deliberatamente invece di lasciarlo al valore predefinito del fornitore.
Controllare i log con regolarità può essere un'abitudine settimanale di dieci minuti per una sola persona; l'obiettivo non è leggere ogni riga, ma dare un'occhiata alla distribuzione dei codici di stato e agli errori più ricorrenti.
Ottenere un riepilogo rapido con un solo comando
Un riepilogo rapido si può ottenere da un file di log anche senza un team tecnico. Un comando semplice che conta e ordina le righe per codice di stato mostra in pochi secondi quante volte si ripete ogni errore; i 404 o 500 più frequenti compaiono in cima alla lista.
La stessa logica, ordinando per numero totale di richieste per indirizzo IP, rivela subito una fonte di traffico bot insolitamente intensa. Entrambi i filtri danno un risultato molto più rapido della lettura riga per riga dell'intero file.
Errori frequenti
I log restano spesso un file che si apre solo dopo che qualcosa è già andato storto; senza uno sguardo regolare, l'avviso anticipato viene perso.
- Controllare i log solo dopo che il sito è già andato in down, perdendo i segnali di allerta precedenti
- Non rivedere mai i 404, lasciando link rotti inosservati per mesi
- Leggere l'analytics come se ogni visita fosse umana, senza mai considerare la quota di traffico bot
- Non aggiungere mai un campo per il tempo di risposta ai log, lasciando sconosciuta l'origine di una lentezza
I log del server mostrano un sito in modo più onesto di qualsiasi dashboard analytics; ogni richiesta, reale o bot, vi è registrata. Un'abitudine settimanale di dieci minuti coglie molti problemi prima che diventino un reclamo di un cliente. Una prima chiamata conoscitiva con rabbitclip è un buon momento per leggere insieme i log del proprio server.
Domande frequenti
Serve uno strumento speciale per leggere i file di log?
Per un sito piccolo basta filtrare un file di testo semplice dalla riga di comando. Con la crescita del traffico, uno strumento di analisi dei log semplifica il lavoro.
Un errore 404 è sempre un problema?
No. Un bot che prova un indirizzo casuale mai esistito è normale; il vero problema è un link rotto che i visitatori reali incontrano spesso.
Si può bloccare completamente il traffico bot?
Non del tutto, ma schemi di comportamento malevolo noti possono essere bloccati in larga misura a livello di server o di CDN.
La lentezza di una richiesta viene sempre dal server?
No. Può derivare da una query al database, da un'integrazione di terze parti o da un'immagine pesante; il log mostra solo dove rallenta, la causa va comunque indagata a parte.
Si può ottenere un riepilogo rapido invece di leggere riga per riga?
Sì. Un comando semplice che conta e ordina per codice di stato o indirizzo IP mostra l'errore più frequente o una fonte bot insolita senza leggere ogni riga.
