[Web] A nginx automatikusan vágja a hozzáférési naplókat

A webhozzáférési napló (access_log) rögzíti az összes külső kliens hozzáférési viselkedését a webszerverhez, beleértve fontos információkat, mint például kliens IP-cím, hozzáférési dátum, elért URL erőforrás, a szerver által visszaadott HTTP státuszkód és így tovább.
Egy tipikus webes hozzáférési napló így néz ki:

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, mint a Gecko) Verzió/4.0 Mobile Safari/533.1 MicroMessenger/4.5.1.259" -

Tervezés:

1. A probléma megoldása:

Ha a weboldal sok látogatást kap, rengeteg naplóadat lesz, és ha mindez egy naplófájlba van írva, a fájl egyre nagyobb lesz. A nagy fájlok sebessége lassul, például egy fájl több száz megabájtja esetében. Naplóíráskor ez befolyásolja a működési sebességet. Ha meg akarom nézni a hozzáférési naplókat, egy több száz megabites fájl lassan letöltheti és nyitható. Egy harmadik féltől származó ingyenes naplóelemző eszközzel – a Log Treasure-szel feltölthetsz naplófájlokat nginx, apache és iis oldalakról, amelyek segítenek elemezni a weboldal biztonsági szempontjait. Végül is a specializáció professzionálisabb. A Log Bao-nak is van egy méretkorlátja a feltöltött fájlokra, legfeljebb 50 méter.

2. A Nignx-nek nincs olyan mechanizmusa, amely automatikusan elkülönítené a fájlokat és tárolná a naplókat. Mivel az nginx nem automatikusan menti el a fájlokat. Ezért saját szkriptet kell írnod a megvalósításhoz.

A shell szkript fájl nginx_log_division.sh a következő tartalmak:

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

kill -USR1 'cat ${pid_path}'

A fenti shell szkript elve az, hogy először áthelyezzük és átnevezzük az előző naplófájlt egyre, a cél a biztonsági mentés.

Az utolsó hétfő neve szerint, amikor a szkriptet a "2013-09-16" időpontban futják, akkor a generált fájlnév "xxx.log_ 20130909.log".

Még ha az mv parancsot a fájlon is végrehajtották a -USR1 -1 'cat ${{pid_path}'Fájlnév megváltoztatása, nginx továbbra is naplóadatokat ír az újonnan elnevezett "xxx.log_20130909" fájlba, ahogy szokás. Ennek oka, hogy Linux rendszerekben a kernel fájlleírók alapján keres fájlokat.

---------------- a Linux fájlleírók megértése

A fájlleíró egy egész számazonosító, amelyet a Linux kernel minden nyitott fájlhoz nevez el.

A Linux kernel generál (vagy karbantartja) egy "Fájlleíró táblaEz a fájlleíró tábla rögzíti a "a folyamat által megnyitott fájlt (azonosítva)".

Ebben a környezetben a nginx egy futó folyamat, amely már megnyitott egy naplófájlt, és bebontja a fájlt a fájlleíró táblában.

Még ha a naplófájl útja megváltozott is, akkor is megtalálható (a fájlleíró tábla szerint is megtalálható).

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

Amikor a "kill -USR1 'cat ${pid_path}'" parancsot futtatjuk, a nginx.pid fájlban tárolt példány valójában egy szám (ki tudod nyitni és megnézni, itt 894-es vagyok), és a nginx a fő folyamat pidjét (folyamatszámot) írja az nginx.pid fájlba, így közvetlenül megkaphatod a fő folyamatszámot a cat parancson keresztül, és közvetlenül a megadott folyamatszámot irányíthatod.

kill -USR1 'cat ${pid_path}' ekvivalena jelent

Kill –USR1 894 #指定发信号 (USR1) jelzést adj a folyamat számozására.

A Linux rendszerekben a Linux jeleken keresztül kommunikál a "futó folyamatokkal". A Linux rendszerekben sok előre definiált jel is létezik, például a SIGHUP. Az USR1 egy felhasználó által definiált jel. Érthető, hogy maga a folyamat határozza meg, mit kell tenni, amikor megkapja ezt a jelet (vagyis a folyamatíró maga dönti el, hogy fogadja-e ezt a jelet vagy semmit, és teljes egészében a fejlesztőre bízza a döntést). A nginx-ben saját kódot ír, hogy kezelje a nginx naplófájl újranyitását, amikor USR1 jelet kapok. A konkrét elv a következő:

1. A nginx fő folyamata megkapja az USR1 jelet, és újranyitja a naplófájlt (a nginx konfigurációs fájlban szereplő naplónévről kapta a nevét, amely az access_log elem által a konfigurációs fájlban beállított érték, és ha a fájl nem létezik, akkor automatikusan létrehoznak egy új fájl xxx.log).

2. Ezután változtasd a naplófájl tulajdonosát "worker process"-re, hogy a munkafolyamat olvasási és írási jogokkal rendelkezzen a naplófájlhoz (a master és a worker általában különböző felhasználóként futnak, így a tulajdonost kell megváltoztatni).

3. Az nginx fő folyamat lezárja a duplikált naplófájlt (azaz azt a fájlt, amelyet xxx.log_ névre neveztek át 20130909.log az mv parancs használatával),és értesíti a dolgozófolyamatot, hogy használja az újonnan megnyitott naplófájlt(xxx.log a fájl, amit a fő folyamat most nyitott meg). A konkrét megvalósítás részletesebb: a fő folyamat az USR1 jelet küldi a dolgozónak, és miután megkapta ezt a jelet, a dolgozó újra megnyitja a naplófájlt (azaz a konfigurációs fájlban elfogadott xxx.log)

=================================== Rendszeres időközönként hajtson végre szkripteket

Állítsd be a fenti shell script fájlt, hogy hozzáadják az ütemezett feladathoz. a crontab egy ütemezett feladatfolyamat, amely Linux alatt működik. Ez a folyamat akkor indul, amikor bekapcsolod, és időnként a listájára megy, hogy megnézze, van-e valami feladat, amit el kell végezni.

crontab -e

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

Egy fájl nyílik meg, amelyhez a fenti kód hozzáadódik

A formátum: "Shell fájlút végrehajtható". * érthető úgy, hogy "minden", minden perc, minden óra, minden hónap stb.

Beállítottam egy szkriptet, hogy hétfőn hajnali 4-kor futtassa nginx_log_division.sh, és a szkript tartalma egy új naplófájl újragenerálása.

Csatolva:FelállítnginxHogyan konfigurálják a naplókat

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

#第二个参数表示使用那个日志格式 minden naplóformátumhoz egy nevet jelölnek, és a hely megfelel a log_format

A fentiek a crontab ütemezett feladatkezelő használatát is tartalmazzák.

Vannak olyan helyek is, ahol nincs teljes megértés és hibák. Remélem, a jövőben frissíthetem.