[Веб] 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 Mobile 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 також існує багато заздалегідь визначених сигналів, таких як SIGHUP. USR1 — це сигнал, визначений користувачем. Його можна розуміти як сам процес, який визначає, що робити, коли отримує цей сигнал (тобто сам автор процесу вирішує, чи приймати цей сигнал, чи нічого не робити, і повністю залишає це на розсуд розробника). У nginx він пише власний код для обробки повторного відкриття log файлу nginx при отриманні сигналу USR1. Конкретний принцип такий:

1. Основний процес nginx отримує сигнал USR1 і повторно відкриває файл журналу (названий на честь імені журналу у конфігураційному файлі 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-скрипту вище для додавання до запланованого завдання. crontab — це запланований процес завдання в Linux. Цей процес почнеться, коли ви його увімкнете, і час від часу він звертається до списку, щоб перевірити, чи є якісь завдання, які потрібно виконати.

crontab -e

* 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.

Є також місця, де немає повного розуміння і є помилки. Сподіваюся оновити інформацію в майбутньому.