[Web] Nginx taglia automaticamente i log di accesso

Il registro di accesso web (access_log) registra il comportamento di accesso di tutti i client esterni al server web, incluse informazioni importanti come l'IP del client, la data di accesso, la risorsa URL accessibile, il codice di stato HTTP restituito dal server e così via.
Un tipico registro di accesso web appare così:

112.97.37.90 - - [14/Set 2013:14:37:39 +0800] "GET / HTTP/1.1" 301 5 "-" "Mozilla/5.0 (Linux; U; Android 2.3.6; zh-cn; Lenovo A326 Build/GRK39F) AppleWebKit/533.1 (KHTML, come Gecko) Versione/4.0 Mobile Safari/533.1 MicroMessenger/4.5.1.259" -

Pianificazione:

1. Per risolvere il problema:

Quando il sito web ha un gran numero di visite, ci saranno molti dati di log, e se tutti sono scritti in un file di log, il file diventerà sempre più grande. La velocità dei file grandi rallenterà, ad esempio centinaia di megabyte di un file. Quando scrivono i log, questo influisce sulla velocità di operazione. Inoltre, se voglio guardare i log di accesso, un file di diverse centinaia di megabit è lento a scaricarsi e aprirsi. Utilizzando uno strumento gratuito di analisi dei log di terze parti - Log Treasure, puoi caricare file di log da nginx, apache e iis, che aiutano ad analizzare gli aspetti della sicurezza dei siti web. Dopotutto, specializzarsi è più professionale. Log Bao ha anche un limite di dimensione per i file caricati, non più di 50 metri.

2. Nignx non dispone di un meccanismo per separare automaticamente file e archiviare log. Dato che nginx non salva automaticamente i file per te. Perciò, devi scrivere il tuo script per implementarlo.

Il file script della shell nginx_log_division.sh i seguenti contenuti:

# /bash/bash

logs_path="/data/wwwlogs/"

#以前的日志文件.

log_name="xxx.log"   

pid_path="/usr/local/nginx/logs/nginx.pid"

mv ${logs_path}${log_name} ${logs_path}${log_name}_$(date --date="SETTIMANA PRECEDENTE" +"%Y-%m-d").log

uccidi -USR1 'gatto ${pid_path}'

Il principio dello script shell sopra descritto è prima spostare e rinominare il file di log precedente in uno, lo scopo è fare il backup.

Secondo il nome dell'ultimo lunedì, quando lo script viene eseguito nel momento "2013-09-16", il nome del file generato è "xxx.log_ 20130909.log".

Anche se il comando mv è stato eseguito sul file prima che kill -USR1 'cat ${{pid_path}' venga eseguitoNome del file modificato, nginx scriverà comunque i dati di log nel file appena nominato "xxx.log_20130909" come di consueto. Il motivo è che nei sistemi Linux il kernel cerca i file basandosi sui descriptori dei file.

---------------- comprensione dei descrittori di file Linux

Un descrittore di file è un identificatore intero che il kernel Linux nomina per ogni file aperto.

Il kernel Linux genera (o mantiene) un "Tabella dei Descrittori del FileQuesta tabella dei descrittori del file registra "il file aperto da questo processo (identificato)".

In questo contesto, nginx è un processo in esecuzione che ha già aperto un file di log e lo loga nella tabella dei descrittori del file.

Anche se il percorso del file di log è cambiato, può comunque essere trovato (può essere localizzato secondo la tabella dei descriptori del file).

----------------------------------------------

Quando esegui il comando "kill -USR1 'cat ${pid_path}'", il file salvato nel file nginx.pid è in realtà un numero (puoi aprirlo e dare un'occhiata, sono 894 qui), e nginx scrive il pid (numero di processo) del suo processo principale nel file nginx.pid, così puoi ottenere direttamente il suo numero di processo principale tramite il comando cat e operare direttamente il numero di processo specificato.

kill -USR1 'cat ${pid_path}' equivale a

kill –USR1 894 #指定发信号 (USR1) segnale per numerare questo processo.

Nei sistemi Linux, Linux comunica con "processi in esecuzione" tramite segnali. Nei sistemi Linux ci sono anche molti segnali predefiniti, come SIGHUP. USR1 è un segnale definito dall'utente. Può essere inteso come il processo stesso che definisce cosa fare quando riceve questo segnale (cioè, lo stesso autore del processo decide se ricevere questo segnale o non fare nulla, lasciando interamente lo sviluppatore a decidere). In nginx, scrive il proprio codice per gestire la gestione della riapertura del file di log di nginx quando ricevo un segnale USR1. Il principio specifico è il seguente:

1. Il processo principale di nginx riceve il segnale USR1 e riaprirà il file di log (chiamato così dal nome del log nel file di configurazione nginx, che è il valore impostato dall'elemento access_log nel file di configurazione, e se il file non esiste, un nuovo file xxx.log verrà creato automaticamente).

2. Poi cambia il proprietario del file di log in "processo lavorista", così che il processo di lavoro abbia i permessi di lettura e scrittura per il file di log (master e worker di solito si eseguono come utenti diversi, quindi il proprietario deve essere modificato).

3. Il processo principale nginx chiude il file di log duplicato (cioè il file che è stato rinominato in xxx.log_ 20130909.log usando il comando mv poco fa),e notifica al processo worker di utilizzare il nuovo file di log aperto(xxx.log il file appena aperto dal processo principale). L'implementazione specifica è più dettagliata: il processo principale invia il segnale USR1 al lavoratore e, dopo aver ricevuto questo segnale, il lavoratore riaprirà il file di log (cioè il xxx.log concordato nel file di configurazione)

=================================== Eseguire script a intervalli regolari

Imposta il file script shell sopra per essere aggiunto al compito programmato. crontab è un processo di attività programmata sotto Linux. Questo processo inizierà quando lo attivi e ogni tanto andrà nella sua lista per vedere se ci sono compiti da svolgere.

crontab -e

* 04 * * 1 /data/wwwlogs/nginx_log_division.sh

Un file si aprirà con il codice sopra aggiunto

Il formato è "Percorso del file shell da eseguire". * può essere inteso come "ogni", ogni minuto, ogni ora, ogni mese, ecc.

Ho impostato uno script per eseguire nginx_log_division.sh alle 4 del mattino di lunedì, e il contenuto dello script è quello di rigenerare un nuovo file di log.

Allegato:ImpostarenginxCome sono configurati i log

log_format sito '$remote_addr - $remote_user [$time_local] "$request" '

             '$status $body_bytes_inviati "$http_referer" '

             '"$http_user_agent" $http_x_forwarded_for';

access_log /data/wwwlogs/xxxx.com.log sito

#第二个参数表示使用那个日志格式, un nome viene identificato per ogni formato di log e il sito corrisponde al nome indicato nel log_format

Quanto sopra riguarda l'uso del task manager crontab scheduled.

Ci sono anche aspetti in cui non c'è una comprensione completa e ci sono errori. Spero di aggiornare in futuro.