[Web] nginx tar automatiskt bort åtkomstloggar

Webbåtkomstloggen (access_log) registrerar åtkomstbeteendet för alla externa klienter till webbservern, inklusive viktig information som klientens IP, åtkomstdatum, URL-resurs som åtkoms, HTTP-statuskod som returneras av servern och så vidare.
En typisk webbåtkomstlogg ser ut så här:

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

Planering:

1. För att lösa problemet:

När webbplatsen har många besök kommer det att finnas mycket loggdata, och om allt skrivs in i en loggfil blir filen större och större. Hastigheten på stora filer kommer att sakta ner, till exempel hundratals megabyte av en fil. När man skriver loggar påverkar det drifthastigheten. Dessutom, om jag vill titta på åtkomstloggarna, är en fil på flera hundra megabit långsam att ladda ner och öppna. Med ett tredjeparts gratis logganalysverktyg – Log Treasure – kan du ladda upp loggfiler från nginx, apache och iis, som hjälper till att analysera webbplatsens säkerhetsaspekter. Specialisering är ju trots allt mer professionellt. Log Bao har också en storleksgräns för uppladdade filer, högst 50 m.

2. Nignx har ingen mekanism för att automatiskt separera filer och lagra loggar. Eftersom nginx inte automatiskt sparar filer åt dig. Därför behöver du skriva ditt eget skript för att implementera det.

Shell-skriptfilen nginx_log_division.sh följande innehåll:

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

döda -USR1 'katt ${pid_path}'

Principen för ovanstående shell-skript är att först flytta och byta namn på den tidigare loggfilen till ett, syftet är att säkerhetskopiera.

Enligt namnet på den senaste måndagen, när skriptet körs vid tidpunkten "2013-09-16", är det genererade filnamnet "xxx.log_ 20130909.log".

Även om mv-kommandot har körts på filen innan kill -USR1 'cat ${{pid_path}' körsÄndrat filnamn, kommer nginx fortfarande att skriva loggdata till den nynamngivna filen "xxx.log_20130909" som vanligt. Anledningen är att i Linux-system söker kärnan efter filer baserat på filbeskrivningar.

---------------- förståelse av Linux-filbeskrivningar

En filbeskrivare är en heltalsidentifierare som Linux-kärnan namnger för varje öppen fil.

Linux-kärnan genererar (eller underhåller) en "FilbeskrivningstabellDenna filbeskrivningstabell registrerar "filen som öppnats av denna process (identifierad)".

I denna miljö är nginx en pågående process som redan har öppnat en loggfil och loggar filen i filbeskrivningstabellen.

Även om vägen för loggfilen har ändrats kan den fortfarande hittas (den kan lokaliseras enligt filbeskrivningstabellen).

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

När du kör kommandot "kill -USR1 'cat ${pid_path}'" är det sparade i nginx.pid-filen faktiskt ett nummer (du kan öppna det och titta, jag är 894 här), och nginx skriver pid (processnummer) för sin huvudprocess till nginx.pid-filen, så du kan direkt få dess huvudprocessnummer via cat-kommandot och direkt använda det angivna processnumret.

döda -USR1 'cat ${pid_path}' motsvarar

döda –USR1 894 #指定发信号 (USR1) signalen för att numrera denna process.

I Linux-system kommunicerar Linux med "löpande processer" via signaler. I Linux-system finns det också många fördefinierade signaler, såsom SIGHUP. USR1 är en användardefinierad signal. Det kan förstås som att processen själv definierar vad som ska göras när den tar emot denna signal (det vill säga, processförfattaren själv bestämmer om signalen ska tas emot eller inget, och lämnar det helt till utvecklaren att avgöra). I nginx skriver den sin egen kod för att hantera hanteringen av att nginx öppnar loggfilen igen när jag tar emot en USR1-signal. Den specifika principen är följande:

1. Huvudprocessen nginx tar emot USR1-signalen och öppnar loggfilen igen (namngiven efter loggnamnet i nginx-konfigurationsfilen, vilket är värdet som sätts av access_log punkt i konfigurationsfilen, och om filen inte finns kommer en ny fil xxx.log automatiskt att skapas).

2. Byt sedan ägaren till loggfilen till "worker process", så att worker-processen har läs- och skrivbehörigheter till loggfilen (master och worker körs vanligtvis som olika användare, så ägaren måste ändras).

3. nginx huvudprocess stänger den dubbla loggfilen (det vill säga filen som just nu bytte namn till xxx.log_ 20130909.log med mv-kommandot),och meddelar arbetsprocessen att använda den nyöppnade loggfilen(xxx.log filen som just öppnades av huvudprocessen). Den specifika implementationen är mer detaljerad, huvudprocessen skickar USR1-signalen till arbetaren, och efter att ha mottagit denna signal öppnar arbetaren loggfilen igen (det vill säga den xxx.log överenskommen i konfigurationsfilen)

=================================== Kör skript med regelbundna intervaller

Ställ in shell-skriptfilen ovan att läggas till i den schemalagda uppgiften. crontab är en schemalagd uppgiftsprocess under Linux. Denna process startar när du slår på den, och den går då och då till sin lista för att se om det finns några uppgifter som behöver utföras.

Crontab -e

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

En fil öppnas med koden ovanstående tillagd

Formatet är "Shell file path to be executed". * kan förstås som "varje", varje minut, varje timme, varje månad, osv.

Jag satte upp ett skript för att köra nginx_log_division.sh klockan 4 på måndagen, och innehållet i skriptet är att återskapa en ny loggfil.

Bifogat:FörberedanginxHur loggar konfigureras

log_format sidan '$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 webbplats

#第二个参数表示使用那个日志格式 identifieras ett namn för varje loggformat, och platsen motsvarar namnet i log_format

Ovanstående innebär användning av Crontab Scheduled Task Manager.

Det finns också platser där det inte finns fullständig förståelse och misstag. Hoppas kunna uppdatera i framtiden.