Diagnosi e salute del web server. Quali log guardare?

Nell’informatica, un file di log è un file che registra eventi che si verificano in un sistema operativo o altri software in esecuzione. Per monitorare lo stato di salute di un web server è necessario analizzare i vari log disponibili nel sistema per individuare eventuali problematiche, incompatibilità, errori critici oppure rallentamenti e colli di bottiglia.

Quali log dobbiamo analizzare per avere un quadro quanto più completo della situazione? La risposta dipende da che tipo di server stai usando. In un web server condiviso in genere hai accesso al solo file di log del web server, in certi casi anche di PHP e nulla di più.

Questo sito WordPress è ospitato su un server cloud di DigitalOcean. Essendo un servizio non managed ho pieno accesso via SSH alla macchina e posso gestire tutti i software installati, come il web server, PHP, MySQL, applicativi vari ed eventuali. In pratica posso farci quello che voglio.

Quando si lavora in un ambiente del genere, not-managed, è importante tenere d’occhio la stabilità del sistema e questo si traduce nel controllare i vari log degli applicativi in uso. Ubuntu o qualsiasi sistema operativo si aggiorna, WordPress si aggiorna, i plugin cambiano versione, può capitare che nascano nuove incompatibilità e nuovi errori di sistema che possono rallentare la macchina rendendola meno efficace.

In questa guida ti mostro il processo che seguo per analizzare lo stato di salute di un web server, è sicuramente migliorabile ma per iniziare è più che sufficiente. Vediamo quali sono i log che monitoro in media ogni tre/quattro mesi e dopo modifiche ai software.

WordPress log

Il debug del codice PHP fa parte di qualsiasi progetto, WordPress viene fornito con uno specifico sistema di debug progettato per semplificare il processo e standardizzare il codice su core, plugin e temi. Per abilitare questo log è necessario modificare il file wp-config.php (che trovi nella cartella principale di WordPress) aggiungendo il seguente codice:

// DEBUGGING

// Abilitare la modalità WP_DEBUG
define('WP_DEBUG', true);

// Abilitare il salvataggio del log nel file /wp-content/debug.log
define('WP_DEBUG_LOG', true);

// Abilitare la stampa di errori e avvisi
define('WP_DEBUG_DISPLAY', true);
@ini_set('display_errors',1);

La riga define(‘WP_DEBUG’, true) abilita WP_DEBUG, funzione che permette di mostrare nel backend di WP tutti gli errori, le notifiche e gli avvisi di PHP. WP_DEBUG è una costante PHP (una variabile globale permanente) che può essere utilizzata per attivare la modalità “debug” in WordPress. Si presume che sia false per impostazione predefinita e di solito è impostato su true nel file wp-config.php sulle copie di sviluppo di WordPress.

Possono capitare messaggi di errore per cose che funzionano correttamente ma che non seguono le convenzioni appropriate di validazione dei dati in PHP. Questi avvisi sono facili da correggere quando il codice problematico è stato identificato; il codice risultante è quasi sempre più resistente ai bug e più facile da mantenere.

La riga define(‘WP_DEBUG_LOG’, true) abilita il log degli errori che viene salvato in /wp-content/debug.log.

Le ultime due righe define(‘WP_DEBUG_DISPLAY’, true) e @ini_set(‘display_errors’,1) abilitano la stampa degli errori nel backend di WP. Puoi disabilitare questa funzione semplicemente impostando i due valori in false e 0 (zero).

WP_DEBUG_DISPLAY è un altro compagno di WP_DEBUG che controlla se i messaggi di debug vengono mostrati o meno all’interno dell’HTML delle pagine. L’impostazione predefinita è true, che mostra errori e avvisi man mano che vengono generati. L’impostazione su false nasconderà tutti gli errori. Questo dovrebbe essere usato insieme a WP_DEBUG_LOG in modo che gli errori possano essere rivisti in seguito.

PHP log

WordPress gira su PHP è quindi fondamentale verificare ogni tanto la comparsa di nuovi errori per risolverli.

Per visualizzare eventuali problemi devi fare riferimento al log dedicato a PHP dove puoi trovare errori relativi a comandi obsoleti, errori di memoria, processi che vanno in errore e dettagli sui file che hanno generato il problema.

Il file di log ha un nome che varia in base alla versione di PHP che stai usando, in ogni caso lo trovi nella cartella /var/log/.

Il log del web server

Nella guida per l’analisi del log del web server abbiamo focalizzato l’attenzione sul file access.log, ma gli errori generati dal web server non si trovano nel file access ma nel file error.log.

I registri errori Apache/Nginx vengono utilizzati per registrare i messaggi di errore generali. Se si verifica un errore nell’applicazione Web, è sempre buona norma controllare il file di registro degli errori del web server per verificare se sono presenti ulteriori informazioni sul motivo dell’errore.

Nel caso in cui il web server riscontri situazioni particolari salva le informazioni relative nel registro degli errori (error.log). Queste “situazioni” rientrano in diversi livelli di gravità definiti da una convenzione:

• Debug – Informazioni utili per determinare dove si trova il problema.
• Info – Messaggi informativi che non sono necessari da leggere ma che possono essere utili da sapere.
• Notice – è successo qualcosa di normale che vale la pena notare.
• Warn – è successo qualcosa di inaspettato, tuttavia non causa instabilità del sistema.
• Error – Qualcosa non ha avuto successo.
• Crit – Problemi che devono essere risolti.
• Alert – È richiesta un’azione rapida.
• Emerg – Il sistema è in uno stato inutilizzabile e richiede attenzione immediata.

In questo esempio puoi vedere l’esportazione del file di log in versione HTML attraverso Goaccess.

Nginx helper log

Per i webmaster che usano web server Nginx ed hanno installato il plugin Nginx Helper in WordPress può essere utile dare un occhio al rispettivo log ogni tanto. Nginx helper è un plugin che abilita funzioni utili a gestire il sito su Nginx, come ad esempio:

• Rimuove index.php dai permalink quando si utilizza WordPress con nginx.
• Aggiunge il supporto per l’eliminazione della cache Redis quando viene utilizzata come cache a pagina intera creata utilizzando nginx-srcache-module.
• Aggiunge il supporto per la direttiva nginx fastcgi_cache_purge e proxy_cache_purge. Fornisce le impostazioni in modo da poter personalizzare le regole di eliminazione.
• Aggiunge il supporto per nginx map {..} su un’installazione di rete multi sito di WordPress.

MySQL log

Anche MySQL tiene traccia degli errori nel suo log se viene attivato. Controllalo ciclicamente soprattutto dopo importanti update.

MySQL genera tre log utili da analizzare durante lo sviluppo di qualsiasi progetto.

• Il registro degli errori. Contiene informazioni sugli errori che si verificano durante l’esecuzione del server (anche avvio e arresto del server).
• Il registro delle query generali. Log generale di ciò che sta facendo mysqld (connessione, disconnessione, query).
• Il registro delle query lente, il mio preferito. Questo log è costituito da istruzioni SQL che richiedono più di long_query_time secondi per l’esecuzione e richiedono almeno le righe min_examined_row_limit da esaminare. Il registro delle query lente può essere utilizzato per trovare query che richiedono molto tempo per essere eseguite e sono quindi ottime candidate all’ottimizzazione. Tuttavia, esaminare un registro delle query lunghe e lente può essere un’attività che richiede tempo. Per semplificare ciò, è possibile utilizzare il comando mysqldumpslow per elaborare un file di registro delle query lente e riepilogarne il contenuto.

Per impostazione predefinita, nessun file di registro è abilitato in MYSQL. Tutti gli errori verranno mostrati nel syslog/var/log/syslog. Per abilitarli basta seguire i passaggi seguenti:

STEP 1: vai a questo file /etc/mysql/conf.d/mysqld_safe_syslog.cnf e rimuovi o commenta queste righe.

[mysqld_safe]
syslog

STEP 2: vai al file conf mysql /etc/mysql/my.cnf e aggiungi le seguenti righe

Per abilitare il registro errori, aggiungere quanto segue:

[Mysqld_safe]
LOG_ERROR=/var/log/mysql/mysql_error.log
[Mysqld]
LOG_ERROR=/var/log/mysql/mysql_error.log

Per abilitare il registro generale delle query, aggiungi quanto segue:

general_log_file=/var/log/mysql/mysql.log
general_log=1

Per abilitare il Registro delle query lente aggiungere quanto segue:

log_slow_queries=/var/log/mysql/mysql-slow.log
long_query_time=2
log-queries-not-using-indexes

STEP 3: salva il file e riavvia mysql usando i seguenti comandi

service mysql restart

Per abilitare i log in fase di esecuzione, accedi al client mysql con il comando:

mysql -u root -p

poi digita i seguenti comandi:

SET GLOBAL general_log = 'ON';
SET GLOBAL slow_query_log = 'ON';

Cronjob log

Cron è uno degli strumenti più utili che puoi trovare in qualsiasi sistema operativo simile a Unix. Viene utilizzato per pianificare i comandi in un momento specifico. Questi comandi o attività pianificate sono noti come “Cron Jobs”. Cron viene generalmente utilizzato per eseguire backup pianificati, monitorare lo spazio su disco, eliminare periodicamente file (ad esempio file di registro) che non sono più necessari, eseguire attività di manutenzione del sistema e molto altro. Nel caso la tua macchina avesse cron job attivi è utile monitorare lo status per individuare eventuali problemi.

Cron logga tutto in syslog, puoi filtrare solo i messaggi di Cron con il comando GREP:

grep CRON /var/log/syslog

Oppure se vuoi proprio fare il NERD, puoi monitorare via shell il log in tempo reale con il comando TAIL -f:

tail -f /var/log/syslog | grep CRON

Fail2ban log

Hai installato Fail2ban per proteggere il tuo server? Bene, allora dovrai anche tenere d’occhio il suo log per controllare se qualcuno viene bannato.

Anche in questo caso il comando tail risulta particolarmente NERD:

tail -f /var/log/fail2ban.log

Let’s Encrypt log

Usi Certbot oppure Let’s Encrypt per gestire ed aggiornare i certificati dei tuoi siti? Ogni tanto dai un occhio al file di log per capire se gli aggiornamenti dei certificati sono avvenuti con successo oppure se ci sono problemi tecnici che bloccano l’aggiornamento.

UFW log

Hai abilitato il firewall UFW nel tuo web server? Benissimo, ogni tanto controlla il log per capire cosa sta succedendo.

Vuoi aggiungere altro? Mi piacerebbe sapere quali altri log analizzi, lascia un commento!