[Web] nginx fjerner automatisk adgangslogfiler

Webadgangsloggen (access_log) registrerer adgangsadfærden for alle eksterne klienter til webserveren, inklusive vigtig information som klientens IP, adgangsdato, URL-ressource tilgået, HTTP-statuskode returneret af serveren osv.
En typisk webadgangslog ser sådan ud:

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, ligesom Gecko) Version/4.0 Mobile Safari/533.1 MicroMessenger/4.5.1.259" -

Planlægning:

1. At løse problemet:

Når hjemmesiden har mange besøg, vil der være mange logdata, og hvis det hele er skrevet ind i en logfil, vil filen blive større og større. Hastigheden på store filer vil blive langsommere, såsom hundredvis af megabyte af en fil. Når man skriver logs, påvirker det driftshastigheden. Hvis jeg også vil kigge på adgangsloggene, er en fil på flere hundrede megabit langsom at downloade og åbne. Ved at bruge et tredjeparts gratis loganalyseværktøj – Log Treasure – kan du uploade logfiler fra nginx, apache og iis, som hjælper med at analysere sikkerhedsaspekter af hjemmesider. Specialisering er trods alt mere professionelt. Log Bao har også en størrelsesgrænse for uploadede filer, højst 50 m.

2. Nignx har ikke en mekanisme til automatisk at adskille filer og gemme logfiler. Da nginx ikke automatisk gemmer filer for dig. Derfor skal du skrive dit eget script for at implementere det.

Shell-scriptfilen nginx_log_division.sh følgende indhold:

# /bin/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="SIDSTE UGE" +"%Y-%m-d").log

dræb -USR1 'kat ${pid_path}'

Princippet i ovenstående shell-script er først at flytte og omdøbe den tidligere logfil til én, formålet er at tage backup af.

Ifølge navnet på den sidste mandag, når scriptet køres på tidspunktet "2013-09-16", er det genererede filnavn "xxx.log_ 20130909.log".

Selv hvis mv-kommandoen er blevet udført på filen før kill -USR1 'cat ${{pid_path}' udføresÆndret filnavn, vil nginx stadig skrive logdata til den nynavngivne fil "xxx.log_20130909" som sædvanligt. Årsagen er, at i Linux-systemer leder kernen efter filer baseret på filbeskrivelser.

---------------- forståelse af Linux-filbeskrivelser

En filbeskrivelse er en heltalsidentifikator, som Linux-kernen navngiver for hver åben fil.

Linux-kernen genererer (eller vedligeholder) en "FilbeskrivelsestabelDenne filbeskrivelsestabel, registrerer "filen, der åbnes af denne proces (identificeret)".

I dette miljø er nginx en kørende proces, der allerede har åbnet en logfil og logger filen i filbeskrivelsestabellen.

Selv hvis stien for logfilen er ændret, kan den stadig findes (den kan findes ifølge filbeskrivelsestabellen).

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

Når kommandoen "kill -USR1 'cat ${pid_path}'" udføres, er det gemte nummer i nginx.pid-filen faktisk et tal (du kan åbne det og kigge, jeg er 894 her), og nginx skriver pid (procesnummer) for sin hovedproces til nginx.pid-filen, så du kan få dens hovedprocesnummer direkte via cat-kommandoen og direkte betjene det specificerede procesnummer.

kill -USR1 'cat ${pid_path}' svarer til

Slå af –USR1 894 #指定发信号 (USR1) signalet for at nummerere denne proces.

I Linux-systemer kommunikerer Linux med "kørende processer" gennem signaler. I Linux-systemer findes der også mange foruddefinerede signaler, såsom SIGHUP. USR1 er et brugerdefineret signal. Det kan forstås som processen, der selv definerer, hvad der skal gøres, når den modtager dette signal (det vil sige, at procesforfatteren selv beslutter, om signalet skal modtages eller ikke skal gøres, og overlader det helt til udvikleren at afgøre). I nginx skriver den sin egen kode for at håndtere håndteringen af, at nginx genåbner logfilen, når jeg modtager et USR1-signal. Det specifikke princip er som følger:

1. Hovedprocessen i nginx modtager USR1-signalet og genåbner logfilen (opkaldt efter lognavnet i nginx-konfigurationsfilen, som er værdien sat af det access_log element i konfigurationsfilen, og hvis filen ikke eksisterer, oprettes en ny fil automatisk xxx.log).

2. Derefter ændre ejeren af logfilen til "worker process", så worker-processen har læse- og skriverettigheder til logfilen (master og worker kører normalt som forskellige brugere, så ejeren skal ændres).

3. nginx-hovedprocessen lukker den duplikerede logfil (det vil sige filen, der netop blev omdøbt til xxx.log_ 20130909.log ved at bruge mv-kommandoen),og giver arbejderprocessen besked om at bruge den nyåbnede logfil(xxx.log filen åbnet af hovedprocessen lige nu). Den specifikke implementering er mere detaljeret, hovedprocessen sender USR1-signalet til arbejderen, og efter at have modtaget dette signal, vil arbejderen genåbne logfilen (det vil sige den xxx.log, der er aftalt i konfigurationsfilen)

=================================== Udfør scripts med regelmæssige intervaller

Sæt shell-scriptfilen ovenfor til at blive tilføjet til den planlagte opgave. crontab er en planlagt opgaveproces under Linux. Denne proces starter, når du tænder den, og den går ind på sin liste en gang imellem for at se, om der er opgaver, der skal udføres.

Crontab -e

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

En fil åbner med ovenstående kode tilføjet

Formatet er "Shell file path to be executed". * kan forstås som "hvert", hvert minut, hver time, hver måned osv.

Jeg satte et script op til at køre nginx_log_division.sh kl. 4 om morgenen mandag, og indholdet af scriptet er at gengenerere en ny logfil.

Vedhæftet:RejsenginxHvordan logs konfigureres

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

             '$status $body_bytes_sent "$http_referer" '

             '"$http_user_agent" $http_x_forwarded_for';

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

#第二个参数表示使用那个日志格式 identificeres et navn for hvert logformat, og stedet svarer til navnet i log_format

Ovenstående involverer brugen af Crontab Scheduled Task Manager.

Der er også steder, hvor der ikke er fuldstændig forståelse og fejl. Håber at opdatere i fremtiden.