[Web] NGinx samodejno prekine dostopne dnevnike

Dnevnik spletnega dostopa (access_log) beleži vedenje dostopa vseh zunanjih odjemalcev do spletnega strežnika, vključno z pomembnimi informacijami, kot so IP odjemalca, datum dostopa, dostop do URL-ja, ki ga strežnik vrne, HTTP statusna koda, ki jo strežnik vrne, in podobno.
Tipičen dnevnik spletnega dostopa izgleda takole:

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 sestava/GRK39F) AppleWebKit/533.1 (KHTML, kot Gecko) različica/4.0 Mobile Safari/533.1 MicroMessenger/4.5.1.259" -

Načrtovanje:

1. Za rešitev problema:

Ko ima spletna stran veliko obiskov, bo veliko podatkov o dnevniku, in če je vse zapisano v dnevnik, bo datoteka postajala vedno večja. Hitrost velikih datotek se bo upočasnila, na primer stotine megabajtov datoteke. Pri zapisovanju dnevnikov to vpliva na hitrost delovanja. Prav tako, če želim pogledati dnevnike dostopa, je datoteka z več sto megabiti počasna za prenos in odpiranje. Z uporabo brezplačnega orodja za analizo dnevnikov tretje strani – Log Treasure, lahko naložite dnevnike iz nginx, apache in iis, ki pomagajo analizirati varnostne vidike spletne strani. Navsezadnje je specializacija bolj profesionalna. Log Bao ima tudi omejitev velikosti za naložene datoteke, ki ne presega 50 m.

2. Nignx nima mehanizma za samodejno ločevanje datotek in shranjevanje dnevnikov. Ker nginx samodejno ne shranjuje datotek namesto vas. Zato morate napisati svoj skript, da to implementirate.

Shell skriptna datoteka nginx_log_division.sh naslednjo vsebino:

# /smeti/udarec

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}_$(datum --date="LAST WEEK" +"%Y-%m-d").log

kill -USR1 'cat ${pid_path}'

Načelo zgornjega shell skripta je najprej premakniti in preimenovati prejšnjo datoteko dnevnika v eno, namen je varnostno kopiranje.

Po imenu zadnjega ponedeljka, ko se skripta zažene ob času "2013-09-16", je generirano ime datoteke "xxx.log_ 20130909.log".

Tudi če je bil ukaz mv izveden na datoteki pred ukinitvijo -USR1, se izvede 'cat ${{pid_path}'Spremenjeno ime datoteke, nginx bo še vedno zapisoval podatke o logu v novo poimenovano datoteko "xxx.log_20130909" kot običajno. Razlog je v tem, da jedro v Linux sistemih išče datoteke na podlagi deskriptorjev datotek.

---------------- razumevanje Linux opisov datotek

Deskriptor datoteke je celoštevilski identifikator, ki ga Linux jedro poimenuje za vsako odprto datoteko.

Linux jedro generira (ali vzdržuje) "Tabela opisovanja datotekTa tabela opisa datoteke beleži "datoteko, odprto s tem procesom (identificirano)".

V tem okolju je nginx tekoči proces, ki je že odprl dnevniško datoteko in jo beleži v tabeli opisnikov datotek.

Tudi če se je pot dnevniške datoteke spremenila, jo je še vedno mogoče najti (lahko jo najdemo glede na tabelo opisnikov datotek).

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

Ko izvedete ukaz "kill -USR1 'cat ${pid_path}'", je shranjeno v datoteki nginx.pid dejansko številka (lahko jo odprete in pogledate, jaz sem tukaj 894), nginx pa zapiše pid (številko procesa) svojega glavnega procesa v datoteko nginx.pid, tako da lahko neposredno pridobite njegovo glavno številko procesa preko ukaza cat in neposredno upravljate določeno številko procesa.

kill -USR1 'cat ${pid_path}' je ekvivalent

kill – signal USR1 894 #指定发信号 (USR1) za oštevilčenje tega postopka.

V Linux sistemih Linux komunicira z "tekočimi procesi" preko signalov. V Linux sistemih obstaja tudi veliko vnaprej določenih signalov, kot je SIGHUP. USR1 je uporabniško definiran signal. Razumemo ga lahko kot proces, ki sam določa, kaj storiti, ko prejme ta signal (to pomeni, da pisec procesa sam odloči, ali bo ta signal prejel ali nič ne storil, in odločitev prepusti razvijalcu). V nginx napiše svojo lastno kodo za upravljanje ponovnega odpiranja dnevnika nginx, ko prejmem signal USR1. Specifično načelo je naslednje:

1. Glavni proces nginx prejme signal USR1 in ponovno odpre datoteko dnevnika (poimenovano po imenu dnevnika v konfiguracijski datoteki nginx, ki je vrednost, ki jo določi access_log element v konfiguracijski datoteki, in če datoteka ne obstaja, se samodejno ustvari xxx.log nova datoteka).

2. Nato spremenite lastnika dnevnika v "delavski proces", tako da ima delovni proces dovoljenja za branje in pisanje v dnevnik datoteko (glavni in delavec običajno delujeta kot različni uporabniki, zato je treba lastnika spremeniti).

3. Glavni proces nginx bo zaprl podvojeno datoteko dnevnika (torej datoteko, ki je bila preimenovana v xxx.log_ 20130909.log z uporabo ukaza mv pravkar zdaj),in obvesti delavski proces, naj uporabi na novo odprto datoteko dnevnika(xxx.log datoteko, ki jo je pravkar odprl glavni proces). Specifična izvedba je bolj podrobna, glavni proces pošlje signal USR1 delavcu, in po prejemu tega signala delavec ponovno odpre datoteko dnevnika (torej xxx.log, dogovorjeno v konfiguracijski datoteki)

=================================== Izvajanje skript v rednih intervalih

Nastavite zgornjo shell script datoteko, da se doda v načrtovano nalogo. crontab je načrtovan proces nalog pod Linuxom. Ta postopek se začne, ko ga vklopite, in občasno gre na svoj seznam, da preveri, ali je treba opraviti kakšne naloge.

crontab -e

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

Odprla se bo datoteka z dodano zgornjo kodo

Format je "Shell file path to be executed". * lahko razumemo kot "vsako", vsako minuto, vsako uro, vsak mesec itd.

Nastavil sem skripto, ki nginx_log_division.sh zažene ob 4. uri zjutraj v ponedeljek, vsebina skripte pa je za ponovno generiranje nove dnevniške datoteke.

Priloženo:PripravitinginxKako so dnevniki konfigurirani

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

             '$status $body_bajti_poslani "$http_referer" '

             '"$http_user_agent" $http_x_posredovano_za';

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

#第二个参数表示使用那个日志格式 se za vsak format dnevnika določi ime, lokacija pa ustreza imenu v log_format

Zgoraj navedeno vključuje uporabo upravljalnika načrtovanih opravil crontab.

Obstajajo tudi kraji, kjer ni popolnega razumevanja in napak. Upam, da bom v prihodnosti posodobil.