[Web] nginx leikkaa automaattisesti käyttölokit

Web-käyttöloki (access_log) tallentaa kaikkien ulkoisten asiakkaiden pääsykäyttäytymisen web-palvelimelle, mukaan lukien tärkeät tiedot kuten asiakas-IP, käyttöpäivä, käytetty URL-resurssi, palvelimen palauttama HTTP-tilakoodi ja niin edelleen.
Tyypillinen verkkokäyttöloki näyttää tältä:

112.97.37.90 - - [14.9.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, kuten Gecko) Versio/4.0 Mobile Safari/533.1 MicroMessenger/4.5.1.259" -

Suunnittelu:

1. Ongelman ratkaisemiseksi:

Kun sivustolla on paljon käyntejä, lokitietoja on paljon, ja jos kaikki on kirjoitettu lokitiedostoon, tiedosto kasvaa koko ajan. Suurten tiedostojen nopeus hidastuu, kuten satojen megatavujen määrä tiedostoa. Lokitietoja kirjoittaessa se vaikuttaa toimintanopeuteen. Lisäksi, jos haluan katsoa käyttöoikeuslokeja, useiden satojen megabittien tiedosto ladataan ja avautuu hitaasti. Käyttämällä kolmannen osapuolen ilmaista lokianalyysityökalua – Log Treasure – voit ladata lokitiedostoja nginxistä, apacheista ja iis:stä, jotka auttavat analysoimaan verkkosivuston tietoturvan näkökohtia. Loppujen lopuksi erikoistuminen on ammattimaisempaa. Log Baolla on myös kokorajoitus ladatuille tiedostoille, enintään 50 m.

2. Nignx:llä ei ole mekanismia, joka automaattisesti erottaisi tiedostot ja tallentaisi lokit. Koska nginx ei automaattisesti tallenna tiedostoja puolestasi. Siksi sinun täytyy kirjoittaa oma skriptisi toteuttaaksesi sen.

Shell-skriptitiedosto nginx_log_division.sh seuraavat sisällöt:

# /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

tapa -USR1 'kissa ${pid_path}'

Yllä olevan shell-skriptin periaate on ensin siirtää ja nimetä edellinen lokitiedosto yhdeksi, tarkoituksena on varmuuskopioida.

Viimeisen maanantain nimen mukaan, kun skripti ajetaan ajassa "2013-09-16", generoitu tiedostonimi on "xxx.log_ 20130909.log".

Vaikka mv-komento olisi suoritettu tiedostossa ennen tappamista -USR1, 'cat ${{pid_path}' suoritetaanMuutettu tiedostonimi, nginx kirjoittaa edelleen lokitietoja uuteen nimettyyn tiedostoon "xxx.log_20130909" kuten tavallisesti. Syynä on se, että Linux-järjestelmissä ydin etsii tiedostoja tiedostokuvaijien perusteella.

---------------- ymmärrys Linux-tiedostokuvauksista

Tiedostokuvaaja on kokonaislukutunniste, jonka Linux-ydin nimeää jokaiselle avoimelle tiedostolle.

Linux-ydin tuottaa (tai ylläpitää) "TiedostokuvaustaulukkoTämä tiedoston kuvaustaulukko tallentaa "tämän prosessin avaaman tiedoston (tunnistettu)".

Tässä ympäristössä nginx on käynnissä oleva prosessi, joka on jo avannut lokitiedoston ja kirjaa tiedoston tiedostokuvaustauluun.

Vaikka lokitiedoston polku olisi muuttunut, se on silti löydettävissä (se voidaan paikantaa tiedoston kuvaustaulukon mukaan).

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

Kun suoritat komentoa "kill -USR1 'cat ${pid_path}'", nginx.pid-tiedostoon tallennettu tiedosto on itse asiassa numero (voit avata sen ja katsoa, olen täällä 894), ja nginx kirjoittaa pääprosessinsa PID:n (prosessinumeron) nginx.pid-tiedostoon, joten voit saada sen pääprosessin numeron suoraan cat-komennon kautta ja käyttää määritettyä prosessinumeroa.

kill -USR1 'cat ${pid_path}' vastaa

kill –USR1 894 #指定发信号 (USR1) -signaali tämän prosessin numerointiin.

Linux-järjestelmissä Linux kommunikoi "käynnissä olevien prosessien" kanssa signaalien kautta. Linux-järjestelmissä on myös monia ennalta määriteltyjä signaaleja, kuten SIGHUP. USR1 on käyttäjän määrittelemä signaali. Se voidaan ymmärtää niin, että prosessi itse määrittelee, mitä tehdään, kun se vastaanottaa tämän signaalin (eli prosessikirjoittaja itse päättää, vastaanottaako signaali vai ei tehdä mitään, ja jättää täysin kehittäjän päätettäväksi). nginx:ssä se kirjoittaa oman koodinsa hoitaakseen nginxin log-tiedoston avaamisen uudelleen, kun saan USR1-signaalin. Tarkka periaate on seuraava:

1. nginxin pääprosessi vastaanottaa USR1-signaalin ja avaa lokitiedoston uudelleen (nimetty nginx-konfiguraatiotiedoston lokinimen mukaan, joka on access_log-kohteen asettama arvo konfiguraatiotiedostossa, ja jos tiedostoa ei ole, uusi tiedosto luodaan automaattisesti xxx.log).

2. Sitten muuta lokitiedoston omistaja muotoon "työntekijäprosessi", jolloin työntekijäprosessilla on luku- ja kirjoitusoikeudet lokitiedostoon (master ja työntekijä toimivat yleensä eri käyttäjinä, joten omistaja täytyy vaihtaa).

3. nginx-pääprosessi sulkee kaksoislokitiedoston (eli tiedoston, joka nimettiin uudelleen xxx.log_:ksi 20130909.log juuri käyttäen mv-komentoa),ja ilmoittaa työntekijäprosessille käyttää juuri avattua lokitiedostoa(xxx.log tiedosto, jonka pääprosessi juuri avasi). Tarkka toteutus on yksityiskohtaisempi, pääprosessi lähettää USR1-signaalin työntekijälle, ja saatuaan tämän signaalin työntekijä avaa lokitiedoston uudelleen (eli konfiguraatiotiedostossa sovitun xxx.log)

=================================== Suorita skriptejä säännöllisin välein

Aseta yllä oleva shell-skriptitiedosto lisättäväksi ajoitettuun tehtävään. crontab on aikataulutettu tehtäväprosessi Linuxilla. Tämä prosessi käynnistyy, kun käynnistät sen, ja se menee silloin tällöin listalleen nähdäkseen, onko tehtäviä, jotka täytyy suorittaa.

crontab -e

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

Tiedosto avautuu, kun yllä oleva koodi on lisätty

Muoto on "Shell file path to be executed". * voidaan ymmärtää "jokainen", joka minuutti, joka tunti, kuukausi jne.

Asetin skriptin, joka ajaa nginx_log_division.sh maanantaina klo 4 aamulla, ja skriptin sisältö on uuden lokitiedoston uudelleengenerointi.

Liitteenä:PystyttäänginxMiten lokit on konfiguroitu

log_format sivusto '$remote_addr - $remote_käyttäjä [$time_paikallinen] "$request" '

             '$status $body_bytes_sent "$http_referer" '

             '"$http_user_agent" $http_x_forwarded_for';

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

#第二个参数表示使用那个日志格式 jokaiselle lokimuodolle tunnistetaan nimi, ja paikka vastaa log_format

Edellä mainittu sisältää crontab-ajoitetun tehtävienhallinnan käyttöä.

On myös paikkoja, joissa ei ole täydellistä ymmärrystä ja virheitä. Toivottavasti päivitän tilannetta tulevaisuudessa.