[Veeb] nginx lõikab automaatselt ligipääsulogid

Veebipääsu logi (access_log) salvestab kõigi väliste klientide ligipääsukäitumise veebiserverisse, sealhulgas olulised andmed nagu kliendi IP, ligipääsu kuupäev, ligipääsetav URL-i ressurss, serveri tagastatud HTTP staatuskood jne.
Tüüpiline veebilogi näeb välja selline:

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

Planeerimine:

1. Probleemi lahendamiseks:

Kui veebilehel on palju külastusi, tekib palju logiandmeid ja kui kõik on logifaili kirjutatud, muutub fail järjest suuremaks. Suurte failide kiirus aeglustub, näiteks sadu megabaite faili. Logide kirjutamisel mõjutab see töökiirust. Samuti, kui tahan ligipääsu logisid vaadata, siis mitusada megabiti suurune fail on aeglane allalaadimiseks ja avamiseks. Kasutades kolmanda osapoole tasuta logianalüüsi tööriista Log Treasure, saad üles laadida logifaile nginxist, apache'ist ja iis-ist, mis aitavad analüüsida veebisaidi turvalisuse aspekte. Lõppude lõpuks on spetsialiseerumine professionaalsem. Log Baol on ka üleslaaditud failide suurusepiirang, mis ei ületa 50 miljonit.

2. Nignx-il puudub mehhanism failide automaatseks eraldamiseks ja logide salvestamiseks. Kuna nginx ei salvesta automaatselt faile sinu eest. Seetõttu pead kirjutama oma skripti, et seda rakendada.

Shelli skriptifail nginx_log_division.sh järgmised sisud:

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

tappa -USR1 'kass ${pid_path}'

Ülaltoodud shell-skripti põhimõte on esmalt eelmine logifail ümber nimetada ja ümber nimetada, eesmärk on varundada.

Viimase esmaspäeva nime järgi, kui skript käivitatakse ajahetkel "2013-09-16", siis genereeritud failinimi on "xxx.log_ 20130909.log".

Isegi kui mv käsk on failis enne -USR1 tapmist täidetud, siis 'cat ${{pid_path}'Muudetud failinimi, nginx kirjutab endiselt logiandmed uude faili "xxx.log_20130909" nagu tavaliselt. Põhjus on selles, et Linuxi süsteemides otsib tuum faile failide kirjeldajate põhjal.

---------------- arusaam Linuxi failikirjeldustest

Failikirjeldaja on täisarvuline identifikaator, mille Linuxi tuum nimetab iga avatud faili jaoks.

Linuxi tuum genereerib (või haldab) "Failikirjelduste tabelSee faili kirjeldustabel salvestab "selle protsessi käigus avatud faili (tuvastatud)".

Selles keskkonnas on nginx töötav protsess, mis on juba avanud logifaili ja logib faili faili kirjeldustabelisse.

Isegi kui logifaili tee on muutunud, on see siiski leitav (see on paigutatav vastavalt faili kirjeldustabelile).

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

Kui täita käsku "kill -USR1 'cat ${pid_path}'", on nginx.pid failis salvestatud tegelikult number (saad selle avada ja vaadata, olen siin 894), ning nginx kirjutab oma põhiprotsessi pid-i (protsessinumbri) nginx.pid faili, nii et saad otse selle põhiprotsessi numbri cat-käsu kaudu ja kasutada määratud protsessi numbrit.

kill -USR1 'cat ${pid_path}' on ekvivalentne

Kill –USR1 894 #指定发信号 (USR1) signaal selle protsessi nummerdamiseks.

Linuxi süsteemides suhtleb Linux "töötavate protsessidega" signaalide kaudu. Linuxi süsteemides on samuti palju eelmääratletud signaale, näiteks SIGHUP. USR1 on kasutaja määratletud signaal. Seda võib mõista kui protsessi enda määramist, mida teha, kui ta selle signaali vastu võtab (st protsessikirjutaja otsustab ise, kas signaali vastu võtta või mitte midagi teha, ning jätab selle täielikult arendajale). nginx-is kirjutab see ise oma koodi, mis haldab nginx-i logifaili taasavamist, kui saan USR1 signaali. Konkreetne põhimõte on järgmine:

1. nginx peamine protsess võtab vastu USR1 signaali ja avab logifaili uuesti (nimetatud nginx konfiguratsioonifaili loginime järgi, mis on access_log elemendi poolt seatud väärtus konfiguratsioonifailis, ja kui faili ei eksisteeri, luuakse automaatselt uus fail xxx.log).

2. Seejärel muuda logifaili omanik "töötaja protsessiks", nii et töötaja protsessil oleks logifailile lugemis- ja kirjutamisõigused (master ja töötaja töötavad tavaliselt erinevate kasutajatena, seega tuleb omanik vahetada).

3. nginx põhiprotsess sulgeb duplikaatlogifaili (st faili, mis nimetati ümber xxx.log_ 20130909.log just mv käsu abil),ja teavitab töötajaprotsessi, et kasutada äsja avatud logifaili(xxx.log fail, mille avas just peamine protsess). Konkreetne rakendus on detailsem, põhiprotsess saadab USR1 signaali töötajale ning pärast selle signaali saamist avab töötaja logifaili uuesti (st konfiguratsioonifailis kokku lepitud xxx.log)

=================================== Täida skripte regulaarsete intervallidega

Määra ülaltoodud shell-skriptifail, et see lisataks ajastatud ülesandele. crontab on Linuxis ajastatud ülesannete protsess. See protsess algab siis, kui sa selle sisse lülitad, ja aeg-ajalt läheb see oma nimekirja, et näha, kas on veel ülesandeid, mida tuleb täita.

crontab -e

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

Fail avaneb koos ülaltoodud koodiga

Formaat on "Shell file path to be executed". * võib mõista kui "iga", iga minut, iga tund, iga kuu jne.

Seadsin skripti, mis käivitab nginx_log_division.sh esmaspäeval kell 4 hommikul, ja skripti sisu on uue logifaili taasgenereerimine.

Lisatud:SeadistadanginxKuidas logid on seadistatud

log_format sait '$remote_addr - $remote_kasutaja [$time_kohalik] "$request" '

             '$status $body_bytes_sent "$http_referer" '

             '"$http_user_agent" $http_x_forwarded_for';

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

#第二个参数表示使用那个日志格式 iga logivormingu jaoks tuvastatakse nimi ning asukoht vastab log_format

Eelnev hõlmab crontabi ajastatud ülesandehalduri kasutamist.

On ka kohti, kus puudub täielik arusaam ja vead. Loodan tulevikus uuendada.