[Уеб] nginx автоматично изрязва логовете за достъп

Логът за уеб достъп (access_log) записва поведението на всички външни клиенти към уеб сървъра, включително важна информация като IP адрес на клиента, дата на достъп, достъп до URL ресурс, HTTP статус код, върнат от сървъра и други.
Типичен лог за уеб достъп изглежда така:

112.97.37.90 - - [14/сеп/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, като Gecko) Версия/4.0 Мобилен Safari/533.1 MicroMessenger/4.5.1.259" -

Планиране:

1. За решаване на проблема:

Когато уебсайтът има голям брой посещения, ще има много лог данни, и ако всичко е записано в лог файл, файлът става все по-голям. Скоростта на големи файлове ще се забави, като стотици мегабайти от един файл. При записване на логове това влияе на скоростта на работа. Също така, ако искам да разгледам логовете за достъп, файл от няколкостотин мегабита се изтегля и отваря бавно. С помощта на безплатен инструмент за анализ на логове от трета страна - Log Treasure, можете да качвате лог файлове от nginx, apache и iis, които помагат за анализ на аспектите на сигурността на уебсайта. В крайна сметка, специализацията е по-професионална. Log Bao също има ограничение на размера за качени файлове, не повече от 50 м.

2. Nignx няма механизъм за автоматично разделяне на файлове и съхранение на логове. Тъй като nginx не запазва автоматично файлове за теб. Затова трябва да напишете собствен скрипт, за да го реализирате.

Shell скриптният файл nginx_log_division.sh следното съдържание:

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

Принципът на горния shell скрипт е първо да се премести и преименува предишният лог файл в такъв, като целта е да се направи архивиране.

Според името на последния понеделник, когато скриптът се изпълнява в момента "2013-09-16", генерираното име на файла е "xxx.log_ 20130909.log".

Дори ако командата mv е изпълнена върху файла преди kill -USR1 'cat ${{pid_path}' се изпълняваПроменено име на файла, nginx все още ще записва лог данни към новоименувания файл "xxx.log_20130909" както обикновено. Причината е, че в Linux системите ядрото търси файлове въз основа на файлови дескриптори.

---------------- разбиране на Linux файлови дескриптори

Файловият дескриптор е цялочислен идентификатор, който ядрото на Linux наименува за всеки отворен файл.

Linux ядрото генерира (или поддържа) "Таблица с дескриптори на файловеТази таблица с дескриптори на файла записва "файла, отворен чрез този процес (идентифициран)".

В тази среда nginx е работещ процес, който вече е отворил лог файл и го записва в таблицата с дескриптори на файла.

Дори ако пътят на лог файла се е променил, той все още може да бъде намерен (може да бъде локализиран според таблицата с дескриптори на файла).

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

При изпълнение на командата "kill -USR1 'cat ${pid_path}'", запазеният файл в nginx.pid всъщност е число (можете да го отворите и да погледнете, аз съм 894 тук), а nginx записва pid (номера на процеса) на основния си процес във файла nginx.pid, така че можете директно да получите основния му номер на процеса чрез cat командата и директно да управлявате посочения номер на процеса.

kill -USR1 'cat ${pid_path}' е еквивалентно на

kill –USR1 894 #指定发信号 (USR1) сигнал за номериране на този процес.

В Linux системите Linux комуникира с "работещи процеси" чрез сигнали. В Linux системите има и много предварително дефинирани сигнали, като SIGHUP. USR1 е потребителски дефиниран сигнал. Той може да се разбере като самият процес, който определя какво да се направи, когато получи този сигнал (т.е. самият автор на процеса решава дали да получи този сигнал или да не прави нищо и оставя изцяло на разработчика да реши). В nginx той пише собствен код, който обработва обработката при повторно отваряне на log файла от nginx, когато получа USR1 сигнал. Конкретният принцип е следният:

1. Основният процес на nginx получава USR1 сигнала и ще отвори отново лог файла (наречен на името на log в конфигурационния файл nginx, което е стойността, зададена от access_log елемент в конфигурационния файл, и ако файлът не съществува, автоматично ще се създаде нов файл xxx.log).

2. След това сменете собственика на лог файла на "worker process", така че worker process да има права за четене и запис на лог файла (master и worker обикновено работят като различни потребители, така че собственикът трябва да бъде сменен).

3. Основният процес nginx ще затвори дублиращия се лог файл (тоест файла, който току-що беше преименуван на xxx.log_ 20130909.log с командата mv),и уведомява работния процес да използва новоотворения лог файл(xxx.log файла, отворен от основния процес току-що). Конкретната реализация е по-подробна, основният процес изпраща USR1 сигнала на работника, а след получаване на този сигнал работникът отваря отново лог файла (т.е. xxx.log, договорен в конфигурационния файл)

=================================== Изпълнение на скриптове на редовни интервали

Задайте shell script файла по-горе да бъде добавен към планираната задача. crontab е планиран процес на задача в Linux. Този процес ще започне, когато го включите, и той ще влиза в списъка си от време на време, за да провери дали има задачи, които трябва да се изпълнят.

Кронтаб -е

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

Файл ще се отвори с добавения горен код

Форматът е "Shell file path to be execute". * може да се разбира като "всяка", всяка минута, всеки час, всеки месец и т.н.

Настроих скрипт да изпълнява nginx_log_division.sh в 4 сутринта в понеделник, а съдържанието на скрипта е да се генерира нов лог файл.

Прикачено:СлагамnginxКак са конфигурирани логовете

log_format сайт '$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

#第二个参数表示使用那个日志格式, за всеки формат на лог се идентифицира име, а сайтът съответства на името в log_format

Горното включва използването на crontab Scheduled Task Manager.

Има и места, където няма пълно разбиране и грешки. Надявам се да актуализирам в бъдеще.