[Веб] nginx автоматически пересекает логи доступа

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

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, как 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

убить -USR1 'cat ${pid_path}'

Принцип вышеуказанного shell-скрипта заключается в том, чтобы сначала переместить и переименовать предыдущий файл журнала в один, цель которой — сделать резервное копирование.

Согласно названию последнего понедельника, когда скрипт запускается в момент «2013-09-16», сгенерированное имя файла — «xxx.log_ 20130909.log».

Даже если команда mv была выполнена на файле до убийства -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 он пишет собственный код, чтобы обрабатывать процесс повторного открытия файла журнала nginx при получении сигнала USR1. Конкретный принцип таков:

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

2. Затем измените владельца файла журнала на «worker process», чтобы рабочий процесс имел права на чтение и запись в файл журнала (мастер и рабочий обычно работают как разные пользователи, поэтому нужно сменить владельца).

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

Откроется файл с добавленным вышеуказанным кодом

Формат — «Путь к выполнению файла оболочки». * можно понимать как «каждый», каждую минуту, каждый час, каждый месяц и так далее.

Я настроил скрипт на запуск 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.

Есть и места, где нет полного понимания и ошибок. Надеюсь обновить информацию в будущем.