[Web] nginx automaticky přerušuje přístupové záznamy

Logy přístupu k webu (access_log) zaznamenávají přístupové chování všech externích klientů k webovému serveru, včetně důležitých informací jako IP klienta, datum přístupu, přístup k URL zdroji, HTTP kód vracený serverem a podobně.
Typický logový přístup na web vypadá takto:

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, podobně jako Gecko) Verze/4.0 Mobile Safari/533.1 MicroMessenger/4.5.1.259" -

Plánování:

1. K vyřešení problému:

Když má web velký počet návštěv, bude tam hodně log dat, a pokud je vše zapsáno do log souboru, soubor se stále zvětšuje. Rychlost velkých souborů se zpomalí, například stovky megabajtů souboru. Při zápisu logů to ovlivňuje rychlost provozu. Také, pokud se chci podívat do přístupových logů, soubor s několika stovkami megabitů se stahuje a otevírá pomalu. Pomocí bezplatného nástroje pro analýzu logů od třetí strany – Log Treasure – můžete nahrávat logy z nginx, apache a iis, které pomáhají analyzovat bezpečnostní aspekty webu. Koneckonců, specializace je profesionálnější. Log Bao má také limit velikosti pro nahrané soubory, maximálně 50 m.

2. Nignx nemá mechanismus pro automatické oddělení souborů a ukládání logů. Protože nginx automaticky neukládá soubory za vás. Proto musíte napsat vlastní skript, abyste to implementovali.

Skriptový soubor shell nginx_log_division.sh následující obsah:

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

zabít -USR1 'kočka ${pid_path}'

Princip výše uvedeného shell skriptu spočívá v tom, že se předchozí log soubor nejprve přesune a přejmenuje na jedno, účelem je zálohování.

Podle názvu posledního pondělí, když je skript spuštěn v čase "2013-09-16", je generovaný název souboru "xxx.log_ 20130909.log".

I když byl příkaz mv vykonán na souboru před zabitím -USR1, je vykonán 'cat ${{pid_path}'Změněný název souboru, nginx bude stále zapisovat logovací data do nově pojmenovaného souboru "xxx.log_20130909" jako obvykle. Důvodem je, že v linuxových systémech jádro hledá soubory na základě popisů souborů.

---------------- porozumění popisům souborů v Linuxu

Souborový deskriptor je celočíselný identifikátor, který Linux kernel pojmenovává pro každý otevřený soubor.

Linuxové jádro generuje (nebo udržuje) "Tabulka popisů souborůTento tabulkový deskriptor souboru zaznamenává "soubor otevřený tímto procesem (identifikovaný)".

V tomto prostředí je nginx běžící proces, který již otevřel logovací soubor a zaznamenává ho v tabulce descriptorů souborů.

I když se cesta logovacího souboru změnila, stále jej lze najít (lze jej najít podle tabulky popisů souborů).

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

Při spuštění příkazu "kill -USR1 'cat ${pid_path}'" je uložené číslo v souboru nginx.pid ve skutečnosti číslo (můžete ho otevřít a podívat se, já jsem zde 894) a nginx zapisuje pid (číslo procesu) svého hlavního procesu do souboru nginx.pid, takže můžete přímo získat hlavní číslo procesu příkazem cat a přímo ho ovládat.

kill -USR1 'cat ${pid_path}' je ekvivalent

kill – signál USR1 894 #指定发信号 (USR1) pro číslo tohoto procesu.

V linuxových systémech Linux komunikuje s "běžícími procesy" prostřednictvím signálů. V linuxových systémech existuje také mnoho předdefinovaných signálů, například SIGHUP. USR1 je uživatelsky definovaný signál. Lze jej chápat jako samotný proces, který definuje, co má dělat, když tento signál přijme (to znamená, že samotný zapisovatel procesu rozhodne, zda tento signál přijme, nebo nic neudělá, a rozhodnutí ponechává zcela na vývojáři). V nginx píše vlastní kód, který zvládne zpracování opětovného otevření logu nginx, když přijmu signál USR1. Konkrétní princip je následující:

1. Hlavní proces nginx přijme signál USR1 a znovu otevře logovací soubor (pojmenovaný podle logu v konfiguračním souboru nginx, což je hodnota nastavená access_log položkou v konfiguračním souboru, a pokud soubor neexistuje, automaticky se vytvoří nový xxx.log).

2. Poté změnit vlastníka logovacího souboru na "pracovní proces", aby pracovní proces měl oprávnění ke čtení a zápisu do logovacího souboru (master a worker obvykle běží jako různí uživatelé, takže je třeba změnit vlastníka).

3. Hlavní proces nginx uzavře duplicitní logovací soubor (tedy soubor, který byl přejmenován na xxx.log_ 20130909.log právě nyní pomocí příkazu mv),a upozorňuje pracovní proces, aby použil nově otevřený logovací soubor(xxx.log souboru, který právě otevřel hlavní proces). Konkrétní implementace je podrobnější, hlavní proces odešle USR1 signál pracovníkovi a po jeho přijetí pracovník znovu otevře logovací soubor (tj. xxx.log dohodnutý v konfiguračním souboru)

=================================== Spouštějte skripty v pravidelných intervalech

Nastavte výše přidaný shell skriptový soubor do plánované úlohy. crontab je plánovaný úkolový proces v Linuxu. Tento proces začne při zapnutí a občas se objeví na svém seznamu, aby zjistil, zda je potřeba něco vykonat.

crontab -e

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

Soubor se otevře s přidaným výše uvedeným kódem

Formát je "Shell file path to be executed". * lze chápat jako "každé", každou minutu, každou hodinu, každý měsíc atd.

Nastavil jsem skript, který nginx_log_division.sh spustí v pondělí ve 4 ráno, a jeho obsahem je znovu vygenerovat nový logovací soubor.

Přikládané:UstavitnginxJak jsou logy konfigurovány

log_format stránka '$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 stránka

#第二个参数表示使用那个日志格式 je pro každý formát logu určen název a místo odpovídá názvu v log_format

Výše uvedené zahrnuje použití správce plánovaných úloh crontab.

Jsou také místa, kde není úplné pochopení a chyby. Doufám, že v budoucnu budu aktualizovat.