NGINX è un server Web affidabile e ad alte prestazioni, in grado di gestire enormi quantità di traffico per i siti Web più trafficati di Internet. Durante la risoluzione dei problemi, è necessario un modo per dare un senso al traffico e NGINX offre funzionalità di registrazione flessibili per acquisire dettagli preziosi e aiutarti a capire il comportamento del tuo server Web.
NGINX offre due file diversi per la registrazione di dati importanti del server web., Questi due file sono error_log e access_log. access_log viene utilizzato per memorizzare informazioni sulle richieste dei client webe error_log memorizza altri messaggi imprevisti o informativi.
Configurazione di access_log
Il file access_log raccoglie tutte le richieste client immediatamente dopo l’elaborazione della richiesta, fornendo un ottimo modo per registrare le pagine che gli utenti richiedono dal server Web., Si può scegliere dove acess_log i dati vengono scritti utilizzando la seguente sintassi del file di configurazione:
access_log path ] ];access_log off;Specifyingformat consente di utilizzare un formato personalizzato nel tuo log utilizzando variabili come il numero di bytessent al client ($bytes_sent) ola lunghezza richiesta ($request_length).
Normalmente, NGINX registrerà ogni transazione che elabora in access_log. Il parametro if=condition fornisce un powerfulway per eseguire la registrazione condizionale in modo che onlystores log access log messaggi se qualche condizione è vera., Per esempio, se youonly desidera registrare le richieste di restituzione di un codice di stato HTTP 404 è possibile utilizzare i seguenti istruzioni:
map $status $should_log {404 1;default 0;}access_log logs/access.log combined if=$should_log;Con questo cambiamento eventuali richieste completedsuccessfully (2xx), reindirizzato a un’altra pagina (3xx) o incontrato un servererror (5xx) non saranno registrati nel log/accesso.log-only404 errori verranno registrati.
Se si dispone di più di un host virtuale omultiple http, server o directivesthensometimes posizione è utile essere in grado di disabilitare la registrazione per al livello di direttiva corrente, e lo speciale off valore è stato creato per questo scopo.,La seguente riga di configurazione mostra come è possibile impedire a NGINX di scrivere informazioni di accesso a qualsiasi target access_log al livello corrente:
access_log off;Per una spiegazione più completa delle opzioni di configurazione, controlla la documentazione di NGINX access_log.
NGINX Log Severity Levels
NGINX supporta una vasta gamma di livelli di severitàper semplificare la registrazione delle informazioni che ti interessano. Ciascuno di questi livelli può essere utilizzato con la direttiva error_log per impostare il livello minimo al quale vengono registrati i messaggi., Ecco i supportedlevels in ordine dal più basso al più alto, insieme a una guida su come vengono utilizzati:
- Debug – Debug messaggi che non sono utili la maggior parte del tempo.
- Info-Messaggi informativi che potrebbero essere buoni da sapere.
- Avviso-Qualcosa di normale ma significativo è successo e dovrebbe essere notato.
- Warn-È successo qualcosa di inaspettato, tuttavia non è motivo di preoccupazione.
- Errore-Qualcosa non è riuscito.
- Crit-Si è verificata una condizione critica.
- Alert-È necessaria un’azione immediata.
- Emerg-Il sistema è inutilizzabile.,
Configurazione di error_log
Per impostazione predefinita, il file error_log cattura tutti i messaggi di log a livello di gravità dell’errore, il che significa che è usato principalmente per comprendere i messaggi fatali o critici per aiutare con lo shooting. Il percorso predefinito per error_logis logs / error.log. Il modo in cui i messaggi di errore NGINXstores sono flessibili e, oltre a consentire di scrivere messaggi su un file, supporta anche l’invio di error_logmessages a stderr o al demone syslog. Se stai eseguendo NGINXopen source 1.5.,2 o più recente, è anche possibile inviare messaggi error_log a più di un luogo alla volta specificando più direttive error_log sullo stesso livello di configurazione.
Se si desidera registrare tutti i messaggi in corrispondenza o al di sopra della gravità del log di avviso, effettuare la seguente modifica di configurazione:
error_log logs/error.log warn;Logging su Syslog Con NGINX
Entrambe le direttive access_log e error_log supportano l’invio di messaggi a un demone syslog utilizzando la stringa syslog: nella configurazione., Il frammento di codice seguente viene illustrata la sintassi per l’utilizzo di direttive con un demone syslog:
http {error_log syslog:server;…}Per esempio, se si desidera indirizzare tutte error_log messaggi con warn o maggiore gravità per il syslogdaemon utilizzare questa direttiva riga:
error_log syslog:server=192.168.1.1 severity=warn;È possibile personalizzare ulteriormente il syslogconfiguration per soddisfare il vostro ambiente utilizzando il syslog parametri descritti al il NGINXsyslog documentazione.
Gestione dei log senza frustrazione. (È una cosa.,)
Aggregare, organizzare e gestire i log con Papertrail
Cose a cui prestare attenzione
La flessibilità che NGINX logging fornisce a un costo, e ci sono alcune cose a cui prestare attenzione quando si scrive il file di configurazione. Abbiamo già coperto la capacità di NGINX di ignorare loggingconfigurations a livello di direttiva, e questa funzione è estremamente utile per la registrazione di informazioni aggiuntive ogni volta che gli utenti accedono a percorsi specifici, ad esempio, loggingextra informazioni sul traffico per tutti gli utenti che accedono all’URI /privato., Tuttavia, l’utilizzo dei registri di accesso nidificati può diventare rapidamentecomplesso e si dovrebbe fare attenzione a non utilizzare troppo questa funzione.
La scrittura di access_logentries su un file su disco può degradare le prestazioni del server e aumentare la latenza di risposta per le richieste degli utenti. Per i server Web che necessitano di mantenere prestazioni elevate, NGINX fornisce un modo per scrivere messaggi di log in un buffer ciclico inmemory, ignorando completamente il disco. L’estrazione di questi registri è più implicata della lettura di un file, quindi è necessario utilizzarla solo se le prestazioni sono critiche per il carico di lavoro.,
Per utilizzare questa funzione, la versione di NGINX deve essere configurata utilizzando l’opzione—with-debug. È possibile verificare se questo è il caso in questo modo:
$ nginx -V 2>&1 | grep—‘—with-debug’configure arguments: --with-debugAll’interno del file di configurazione è possibile abilitare la scrittura di voci di log in memoria con il seguente snippet:
error_log memory:32m debug;...http {...}Questo scriverà tutti i messaggi di log a livello di debug. L’estrazione dei messaggi di log dalla memoria comporta l’utilizzo di gdb per connettersi al processo NGINX e copiare e incollare il seguente script al prompt:
set $log = ngx_cycle->logwhile $log->writer != ngx_log_memory_writerset $log = $log->nextendset $buf = (ngx_log_memory_buf_t *) $log->wdatadump binary memory debug_log.txt $buf->start $buf->endQuindi uscire da GDB usando Ctrl-D., Lo script di cui soprascriverà il contenuto della memoria nel debug_log.txtfile dove puoi leggerlo come normale.
Conclusione
NGINX consente di raccogliere i registri per gli accessi bothoutine e gli errori imprevisti in file separati per l’analisi successiva e la risoluzione dei problemi. Il formato del file access_log può essere ampiamente personalizzato per includere informazioni dettagliate sulle richieste, come il numero di byte inviati al client o la lunghezza della richiesta,e la direttiva error_log consente di controllare il livello minimo di gravità richiesto per i messaggi da registrare.,Entrambe le direttive access_log e error_log possono trasmettere logentries a un demone syslog, che può essere estremamente utile per gli sviluppatori che lavorano con più server Web.
E se tutte queste funzionalità non sono sufficienti per te, puoi persino scrivere error_logentries su un buffer di memoria per evitare di scrivere su disco e ridurre l’impatto delle prestazioni per i server occupati.