Logging

Nginx ci permette di registrare gli errori e anche più genericamente gli esiti delle richieste che processa.

In staging, non distinguere fra la gravità degli errori potrebbe essere una cosa buona e giusta, perché registrare ogni tipo di errore, anche i warning, permetterebbe di arrivare a una estrema pulizia di codice. In produzione è una buona idea, specie se le risorse sono estremamente ridotte, e più seriamente per una più facile lettura, abbassare il livello di guardia, e per esempio rinunciare ai warning.

Tutto questo naturalmente cambia nel momento in cui ci sono problemi strani da individuare su produzione, ma a quel punto bisogna rivedere qualcosa nei nostri standard di similarità fra produzione e staging e nella nostra capacità di testare su staging i reali casi di utilizzo, ma questa è tutta un’altra storia.

Quindi se vogliamo essere più paranoici, possiamo definire il livello degli errori con questa formula, che vi riporto per staging e per produzione:

In staging

error_log /var/log/nginx/error.log debug;

In produzione 

error_log /var/log/nginx/error.log error;

Naturalmente possiamo inserire queste notazioni nel nostro main context del nginx.

Per essere più completi, questi sono tutti i livelli di error log identificabili, dal nulla all’emergenza assoluta. Per essere molto chiari potremmo anche decidere di impostare error log su emerg, ma in sostanza, almeno a mio modo di vedere, ce ne faremmo molto poco.

• debug - informazioni di debug utili per determinare dove si trova il problema
• info - informazioni che non abbiamo bisogno immediato di conoscere, ma che potrebbero risultare utili
• notice - va tutto bene, comportamento normale, ma meglio darci occhio, perchè è comunque degno di nota
• warn - è successo qualcosa che non ci si sarebbe aspettati, ma non è ancora un vero problema( però potrebbe diventarlo)
• error - c’è stato un errore, non per essere pessimisti ma è possibile che nginx sia giù
• crit - c’è stato un errore critico, bisogna assolutamente indagare, e non per essere pessimisti, ma potrebbe essere un errore più rognoso di una cattiva configurazione
• alert - meglio intervenire, perché qualcosa decisamente non va
• emerg - il sistema è completamente inutilizzabile, senza un intervento deciso non si può fare nulla.

Non scordiamoci che possiamo cambiare il percorso standard su cui finisce l’error log, non rimettendo nel secondo parametro della formula appena data /var/log/nginx/error.log ma un altro nome, per esempio /var/log/nginx/error2.log 

A cosa potrebbe mai servire? Non farà confusione una cosa del genere? 

Se uniamo la sacrosanta possibilità di ridefinire i comportamenti standard all’interno di definite location, la cosa diventa molto carina e potente: possiamo infatti specificare un file diverso solo per alcune location che ci interessano, come ad esempio una area di amministrazione del sito.

location /areasicura {
     error_log /var/log/nginx/secure-area-error.log warning;
} 

Non scordiamo l’access log, altro strumento utilissimo, potremmo decidere con la stessa logica di stabilire un access log separato per l’area di amministrazione

location /areasicura {
   access_log /var/log/nginx/secure-area-access.log
   error_log /var/log/nginx/secure-area-error.log warning;
}

In questa maniera, possiamo vedere chi decide di entrare sull’area di amministrazione molto più facilmente, e avere log più specifici e completi.

Facendo molta attenzione, possiamo anche decidere di mettere i log a off in certe parti del sito, perché per esempio sappiamo già che sono accessibili solo da un set ristrettissimo di ip 

location /areasicura {
   allow my.public.ip.here; 
   deny all;
   error_log /var/log/nginx/secure-area-error.log warning;
   access_log off;
}

Se volete approfondire l’uso di access e error log, con parametri condizionali, tipo per registrare gli accessi o gli errori solo di una determinata tipologia, potete trovare un’impostazione del discorso utilissima su queste due risorse:

nginx.com blog

loginradius.com blog

Leggere i file di log

Diciamocelo, non ripeto nulla di straordinario qui, ma può tornare utile segnarlo da qualche parte, magari un file txt, per averli sempre sotto mano se non si padroneggia bene la bash.

[per leggere gli error log da quando nginx è su]

cat /var/log/nginx/error.log

[per leggere solo gli ultimi error log]

tail -f /var/log/nginx/error.log

[leggiamo quanti responsi ci sono globalmente, separati per esito]

awk '{print $9}' access.log | sort | uniq -c | sort -rn

ritornerà qualcosa di simile, per esempio 

600 200

150 500

20 404

9 400

2 301

Io mi preoccuperei subito per quel numero alto di 500 e quindi userei il comando successivo.

[Controllare le url che riportano uno status code desiderato]

awk '($9 ~ /500/)' access.log | awk '{print $7}' | sort | uniq -c | sort -rn

Così avremo una visione di insieme di quali sono le url che generano tutti quei 500.

Cosa dire infine? Con un po’ di progettazione, e facendo un po’ di prove, si può personalizzare molto il sistema di log, e bisogna farlo ovviamente con criterio, per utilizzare al meglio un’arma che funziona benissimo anche se lasciata alle impostazioni base, ma che come sempre, se usata con un po’ di raziocinio in più, regala grandi soddisfazioni.