[Web] nginx kutter automatisk tilgangslogger

Webtilgangsloggen (access_log) registrerer tilgangsatferden til alle eksterne klienter til webserveren, inkludert viktig informasjon som klient-IP, tilgangsdato, URL-ressurs som ble aksessert, HTTP-statuskode returnert av serveren, og så videre.
En typisk netttilgangslogg ser slik ut:

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

Planlegging:

1. For å løse problemet:

Når nettsiden har mange besøk, vil det være mye loggdata, og hvis alt skrives inn i en loggfil, vil filen bli større og større. Hastigheten på store filer vil avta, som hundrevis av megabyte av en fil. Når man skriver logger, påvirker det operasjonshastigheten. Også, hvis jeg vil se på tilgangsloggene, er en fil på flere hundre megabit treg å laste ned og åpne. Ved å bruke et tredjeparts gratis logganalyseverktøy – Log Treasure, kan du laste opp loggfiler fra nginx, apache og iis, som hjelper til med å analysere nettsidens sikkerhetsaspekter. Tross alt er spesialisering mer profesjonelt. Log Bao har også en størrelsesgrense for opplastede filer, ikke mer enn 50 m.

2. Nignx har ikke en mekanisme for automatisk å separere filer og lagre logger. Siden nginx ikke automatisk lagrer filer for deg. Derfor må du skrive ditt eget skript for å implementere det.

Shell-skriptfilen nginx_log_division.sh følgende innhold:

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

drep -USR1 'cat ${pid_path}'

Prinsippet i shell-skriptet ovenfor er først å flytte og gi nytt navn på den forrige loggfilen til én, formålet er å ta backup av.

Ifølge navnet på forrige mandag, når skriptet kjøres på tidspunktet "2013-09-16", er det genererte filnavnet "xxx.log_ 20130909.log".

Selv om mv-kommandoen er utført på filen før kill -USR1 'cat ${{pid_path}' utføresEndret filnavn, vil nginx fortsatt skrive loggdata til den nylig navngitte filen "xxx.log_20130909" som vanlig. Årsaken er at i Linux-systemer leter kjernen etter filer basert på filbeskrivelser.

---------------- forståelse av Linux-filbeskrivelser

En filbeskrivelse er en heltallsidentifikator som Linux-kjernen navngir for hver åpne fil.

Linux-kjernen genererer (eller vedlikeholder) en "FilbeskrivelsestabellDenne filbeskrivelsestabellen registrerer "filen som åpnes av denne prosessen (identifisert)".

I dette miljøet er nginx en kjørende prosess som allerede har åpnet en loggfil og logger filen i filbeskrivelsestabellen.

Selv om stien til loggfilen har endret seg, kan den fortsatt finnes (den kan finnes i henhold til filbeskrivelsestabellen).

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

Når du kjører kommandoen "kill -USR1 'cat ${pid_path}'", er lagret i nginx.pid-filen faktisk et nummer (du kan åpne det og ta en titt, jeg er 894 her), og nginx skriver pid (prosessnummer) til hovedprosessen til nginx.pid-filen, så du kan få hovedprosessnummeret direkte via cat-kommandoen og operere det angitte prosessnummeret.

drep -USR1 'cat ${pid_path}' tilsvarer

drep –USR1 894 #指定发信号 (USR1) signalet for å nummerere denne prosessen.

I Linux-systemer kommuniserer Linux med «kjørende prosesser» gjennom signaler. I Linux-systemer finnes det også mange forhåndsdefinerte signaler, som SIGHUP. USR1 er et brukerdefinert signal. Det kan forstås som at prosessen selv definerer hva den skal gjøre når den mottar dette signalet (det vil si at prosessforfatteren selv bestemmer om signalet skal mottas eller ikke gjøres, og overlater det helt til utvikleren å avgjøre). I nginx skriver den sin egen kode for å håndtere håndteringen av at nginx åpner loggfilen på nytt når jeg mottar et USR1-signal. Det spesifikke prinsippet er som følger:

1. Hovedprosessen i nginx mottar USR1-signalet og vil åpne loggfilen på nytt (oppkalt etter loggnavnet i nginx-konfigurasjonsfilen, som er verdien satt av access_log-elementet i konfigurasjonsfilen, og hvis filen ikke eksisterer, vil en ny fil xxx.log automatisk opprettes).

2. Deretter endre eieren av loggfilen til "worker process", slik at worker-prosessen har lese- og skrivetillatelser til loggfilen (master og worker kjører vanligvis som forskjellige brukere, så eieren må endres).

3. nginx-hovedprosessen vil lukke den dupliserte loggfilen (det vil si filen som nettopp ble omdøpt til xxx.log_ 20130909.log ved å bruke mv-kommandoen),og varsler arbeiderprosessen om å bruke den nylig åpnede loggfilen(xxx.log filen som nettopp ble åpnet av hovedprosessen). Den spesifikke implementeringen er mer detaljert, hovedprosessen sender USR1-signalet til arbeideren, og etter å ha mottatt dette signalet, vil arbeideren åpne loggfilen på nytt (det vil si xxx.log avtalt i konfigurasjonsfilen)

=================================== Kjør skript med jevne mellomrom

Sett shell-skriptfilen ovenfor til å legges til i den planlagte oppgaven. crontab er en planlagt oppgaveprosess under Linux. Denne prosessen starter når du slår den på, og den går til listen sin av og til for å se om det er noen oppgaver som må utføres.

Crontab -e

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

En fil åpnes med koden ovenfor lagt til

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

Jeg satte opp et skript til å kjøre nginx_log_division.sh klokken 04.00 på mandag, og innholdet i skriptet er å generere en ny loggfil.

Vedlagt:DefinerenginxHvordan logger konfigureres

log_format siden '$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 nettsted

#第二个参数表示使用那个日志格式 identifiseres et navn for hvert loggformat, og stedet tilsvarer navnet i log_format

Ovenstående innebærer bruk av Crontab planlagt oppgavebehandling.

Det finnes også steder hvor det ikke er fullstendig forståelse og feil. Håper å oppdatere i fremtiden.