[Web] Nginx taie automat jurnalele de acces

Jurnalul de acces web (access_log) înregistrează comportamentul de acces al tuturor clienților externi către serverul web, incluzând informații importante precum IP-ul clientului, data accesului, resursa URL accesată, codul de stare HTTP returnat de server și așa mai departe.
Un jurnal tipic de acces la web arată astfel:

112.97.37.90 - - [14/Sep/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, ca Gecko) Versiunea/4.0 Mobile Safari/533.1 MicroMessenger/4.5.1.259" -

Planificare:

1. Pentru a rezolva problema:

Când site-ul are un număr mare de vizite, vor exista multe date de jurnal, iar dacă toate sunt scrise într-un fișier de jurnal, fișierul va deveni tot mai mare. Viteza fișierelor mari va încetini, cum ar fi sute de megabytes dintr-un fișier. La scrierea jurnalelor, acest lucru afectează viteza de funcționare. De asemenea, dacă vreau să mă uit la jurnalele de acces, un fișier de câteva sute de megabiți se descarcă și deschide lent. Folosind un instrument gratuit de analiză a logurilor de la terți - Log Treasure, poți încărca fișiere de log de la nginx, apache și iis, care ajută la analizarea aspectelor de securitate ale site-ului. La urma urmei, specializarea este mai profesională. Log Bao are, de asemenea, o limită de dimensiune pentru fișierele încărcate, de cel mult 50m.

2. Nignx nu are un mecanism de separare automată a fișierelor și a jurnalelor. Deoarece nginx nu salvează automat fișierele pentru tine. Prin urmare, trebuie să scrii propriul tău script pentru a o implementa.

Fișierul script shell nginx_log_division.sh următoarele conținuturi:

# /bătaie/bătaie

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="SĂPTĂMÂNA TRECUTĂ" +"%Y-%m-d").log

kill -USR1 'cat ${pid_path}'

Principiul scriptului shell de mai sus este să muti mai întâi și să redenumești fișierul log anterior în unu, scopul fiind backup-ul.

Conform numelui ultimei zile de luni, când scriptul este rulat la momentul "2013-09-16", atunci numele fișierului generat este "xxx.log_ 20130909.log".

Chiar dacă comanda mv a fost executată pe fișier înainte ca kill -USR1 'cat ${{pid_path}' să fie executatăNume de fișier schimbat, nginx va continua să scrie date de jurnal în fișierul nou denumit "xxx.log_20130909" ca de obicei. Motivul este că, în sistemele Linux, nucleul caută fișiere pe baza descriptorilor de fișier.

---------------- înțelegerea descriptoarelor de fișiere Linux

Un descriptor de fișier este un identificator de întreg pe care nucleul Linux îl denumește pentru fiecare fișier deschis.

Nucleul Linux generează (sau menține) un "Tabelul Descriptor de FișiereAcest tabel descriptor de fișiere înregistrează "fișierul deschis de acest proces (identificat)".

În acest mediu, nginx este un proces care a deschis deja un fișier de jurnal și îl loghează în tabelul de descriptori de fișier.

Chiar dacă traseul fișierului de jurnal s-a modificat, acesta poate fi încă găsit (poate fi localizat conform tabelului de descriptori de fișier).

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

Când executi comanda "kill -USR1 'cat ${pid_path}'", fișierul salvat în nginx.pid este de fapt un număr (îl poți deschide și verifica, eu sunt 894 aici), iar nginx scrie PID-ul (numărul procesului) al procesului principal în fișierul nginx.pid, astfel încât poți obține direct numărul procesului principal prin comanda cat și să operezi direct numărul procesului specificat.

kill -USR1 'cat ${pid_path}' este echivalent cu

kill –USR1 894 #指定发信号 (USR1) pentru a numerota acest proces.

În sistemele Linux, Linux comunică prin "procese în rulare" prin semnale. În sistemele Linux, există și multe semnale predefinite, cum ar fi SIGHUP. USR1 este un semnal definit de utilizator. Poate fi înțeleasă ca procesul însuși care definește ce trebuie făcut atunci când primește acest semnal (adică, scriitorul procesului decide însuși dacă primește acest semnal sau nu face nimic, lăsând în întregime dezvoltatorului să decidă). În nginx, scrie propriul cod pentru a gestiona modul în care nginx redeschide fișierul de jurnal atunci când primesc un semnal USR1. Principiul specific este următorul:

1. Procesul principal al nginx primește semnalul USR1 și va redeschide fișierul log (denumit după numele logului din fișierul de configurare nginx, care este valoarea setată de access_log element din fișierul de configurare, iar dacă fișierul nu există, un nou fișier xxx.log va fi creat automat).

2. Apoi schimbă proprietarul fișierului de jurnal în "proces de lucru", astfel încât procesul de lucru să aibă permisiuni de citire și scriere pentru fișierul de jurnal (master și worker rulează de obicei ca utilizatori diferiți, deci proprietarul trebuie schimbat).

3. Procesul principal nginx va închide fișierul log duplicat (adică fișierul redenumit xxx.log_ 20130909.log folosind comanda mv chiar acum),și notifică procesul worker să folosească fișierul de jurnal nou deschis(xxx.log fișierul deschis de procesul principal de acum). Implementarea specifică este mai detaliată, procesul principal trimite semnalul USR1 către lucrător, iar după ce primește acest semnal, lucrătorul va redeschide fișierul log (adică xxx.log agreat în fișierul de configurare)

=================================== Executarea scripturilor la intervale regulate

Setează fișierul de script shell de mai sus pentru a fi adăugat la sarcina programată. crontab este un proces de sarcină programată sub Linux. Acest proces va începe când îl pornești și va merge din când în când la lista sa pentru a vedea dacă există sarcini care trebuie îndeplinite.

crontab -e

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

Un fișier se va deschide cu codul de mai sus adăugat

Formatul este "Calea fișierului shell de executat". * poate fi înțeles ca "fiecare", fiecare minut, fiecare oră, fiecare lună etc.

Am configurat un script să ruleze nginx_log_division.sh la ora 4 dimineața luni, iar conținutul scriptului este să regenerez un nou fișier de log.

Atașat:ConfiguratnginxCum sunt configurate jurnalele

log_format site-ul '$remote_addr - $remote_user [$time_local] "$request" '

             '$status $body_bytes_sent "$http_referer" '

             '"$http_agent_utilizator" $http_x_forwarded_for';

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

#第二个参数表示使用那个日志格式, un nume este identificat pentru fiecare format de jurnal, iar site-ul corespunde numelui din log_format

Cele de mai sus implică utilizarea managerului de sarcini programate crontab.

Există și locuri unde nu există o înțelegere completă și greșeli. Sper să dau un update în viitor.