[Web] nginx knipt automatisch toegangslogboeken

Het webtoegangslogboek (access_log) registreert het toegangsgedrag van alle externe clients tot de webserver, inclusief belangrijke informatie zoals het client-IP, toegangsdatum, geraadpleegde URL-bron, HTTP-statuscode die door de server wordt teruggegeven, enzovoort.
Een typisch webtoegangslogboek ziet er als volgt uit:

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

Planning:

1. Het probleem oplossen:

Wanneer de website veel bezoeken heeft, zal er veel logdata zijn, en als alles in een logbestand wordt geschreven, wordt het bestand steeds groter. De snelheid van grote bestanden zal vertragen, zoals honderden megabytes van een bestand. Bij het schrijven van logs beïnvloedt dit de werksnelheid. Ook, als ik de toegangslogs wil bekijken, is een bestand van enkele honderden megabits traag om te downloaden en te openen. Met een gratis loganalysetool van derden - Log Treasure - kunt u logbestanden uploaden van nginx, apache en iis, die helpen bij het analyseren van websitebeveiligingsaspecten. Specialiseren is immers professioneler. Log Bao heeft ook een limiet op de grootte van geüploade bestanden, niet meer dan 50 meter.

2. Nignx heeft geen mechanisme om bestanden automatisch te scheiden en logs op te slaan. Omdat nginx bestanden niet automatisch voor je opslaat. Daarom moet je je eigen script schrijven om het te implementeren.

Het shell-scriptbestand nginx_log_division.sh de volgende inhoud:

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

kill -USR1 'cat ${pid_path}'

Het principe van het bovenstaande shell-script is om eerst het vorige logbestand te verplaatsen en te hernoemen naar één, met als doel een back-up.

Volgens de naam van de afgelopen maandag, wanneer het script wordt uitgevoerd op het tijdstip "2013-09-16", is de gegenereerde bestandsnaam "xxx.log_ 20130909.log".

Zelfs als het mv-commando op het bestand is uitgevoerd vóór kill -USR1 'cat ${{pid_path}' wordt uitgevoerdGewijzigde bestandsnaam, nginx zal nog steeds loggegevens schrijven naar het nieuw benoemde bestand "xxx.log_20130909" zoals gewoonlijk. De reden is dat de kernel in Linux-systemen zoekt naar bestanden op basis van bestandsbeschrijvingen.

---------------- begrip van Linux-bestandsdescriptors

Een bestandsdescriptor is een gehele getal-identificatie die de Linux-kernel voor elk geopend bestand benoemt.

De Linux-kernel genereert (of onderhoudt) een "BestandsdescriptortabelDeze bestandsbeschrijvingstabel registreert "het bestand dat door dit proces is geopend (geïdentificeerd)".

In deze omgeving is nginx een lopend proces dat al een logbestand heeft geopend en het bestand registreert in de bestandsdescriptor-tabel.

Zelfs als het pad van het logbestand is veranderd, kan het nog steeds worden gevonden (het kan worden gelokaliseerd volgens de bestandsdescriptor-tabel).

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

Bij het uitvoeren van het commando "kill -USR1 'cat ${pid_path}'", is het opgeslagen bestand in het nginx.pid-bestand eigenlijk een nummer (je kunt het openen en bekijken, ik ben hier 894), en nginx schrijft het pid (procesnummer) van zijn hoofdproces naar het nginx.pid-bestand, zodat je direct het hoofdprocesnummer via het cat-commando kunt krijgen en het opgegeven procesnummer direct kunt bedienen.

kill -USR1 'cat ${pid_path}' is gelijk aan

doe – USR1 894 #指定发信号 (USR1) signaal om dit proces te nummeren.

In Linux-systemen communiceert Linux met "lopende processen" via signalen. In Linux-systemen zijn er ook veel vooraf gedefinieerde signalen, zoals SIGHUP. USR1 is een door de gebruiker gedefinieerd signaal. Het kan worden opgevat als het proces zelf dat bepaalt wat er moet gebeuren wanneer het dit signaal ontvangt (dat wil zeggen, de processchrijver zelf beslist of hij dit signaal ontvangt of niets doet, en laat het volledig aan de ontwikkelaar over om te beslissen). In nginx schrijft het zijn eigen code om de afhandeling te regelen waarbij nginx het logbestand opnieuw opent wanneer ik een USR1-signaal ontvang. Het specifieke principe is als volgt:

1. Het hoofdproces van nginx ontvangt het USR1-signaal en opent het logbestand opnieuw (genoemd naar de lognaam in het nginx-configuratiebestand, de waarde die door het access_log item in het configuratiebestand wordt ingesteld, en als het bestand niet bestaat, wordt er automatisch een nieuw bestand xxx.log aangemaakt).

2. Verander vervolgens de eigenaar van het logbestand naar "worker process", zodat het worker-proces lees- en schrijfrechten heeft voor het logbestand (master en worker draaien meestal als verschillende gebruikers, dus de eigenaar moet worden gewijzigd).

3. Het hoofdproces nginx sluit het duplicaat logbestand (dat wil zeggen, het bestand dat net is hernoemd naar xxx.log_ 20130909.log met het mv-commando),en geeft het werkproces de melding om het nieuw geopende logbestand te gebruiken(xxx.log het net geopende bestand dat door het hoofdproces is geopend). De specifieke implementatie is gedetailleerder: het hoofdproces stuurt het USR1-signaal naar de worker, en na ontvangst van dit signaal opent de worker het logbestand opnieuw (dat wil zeggen, de xxx.log afgesproken in het configuratiebestand)

=================================== Voer scripts uit op regelmatige intervallen

Stel het bovenstaande shell-scriptbestand in om aan de geplande taak toe te voegen. crontab is een gepland taakproces onder Linux. Dit proces begint zodra je het aanzet, en het gaat af en toe naar zijn lijst om te zien of er taken zijn die uitgevoerd moeten worden.

crontab -e

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

Er wordt een bestand geopend met bovenstaande code toegevoegd

Het formaat is "Shell-bestandspad te uitvoeren". * kan worden begrepen als "elke", elke minuut, elk uur, elke maand, enzovoort.

Ik heb een script ingesteld om nginx_log_division.sh om 4 uur 's ochtends op maandag uit te voeren, en de inhoud van het script is om een nieuw logbestand te regenereren.

Bijgevoegd:OprichtennginxHoe logs worden geconfigureerd

log_format site '$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 site

#第二个参数表示使用那个日志格式 wordt voor elk logformaat een naam geïdentificeerd, en de site komt overeen met de naam in de log_format

Bovenstaande betreft het gebruik van de geplande taken van Crontab.

Er zijn ook plekken waar geen volledig begrip is en fouten. Hopelijk kan ik in de toekomst een update geven.