[Web] nginx automatycznie przecina logi dostępu

Dziennik dostępu do sieci (access_log) rejestruje zachowanie dostępu wszystkich zewnętrznych klientów do serwera WWW, w tym ważne informacje, takie jak IP klienta, data dostępu, dostęp do zasobu URL, kod statusu HTTP zwracany przez serwer i inne.
Typowy dziennik dostępu do sieci wygląda tak:

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, podobnie jak Gecko) Wersja/4.0 Mobile Safari/533.1 MicroMessenger/4.5.1.259" -

Planowanie:

1. Aby rozwiązać problem:

Gdy strona ma dużą liczbę odwiedzin, pojawia się dużo danych logowych, a jeśli wszystko zostanie zapisane w pliku logu, plik będzie się coraz większy. Prędkość dużych plików zwalnia, na przykład o setki megabajtów pliku. Podczas zapisywania logów wpływa to na szybkość pracy. Jeśli chcę przejrzeć logi dostępu, plik o kilkuset megabitach pobiera się i otwiera wolno. Korzystając z zewnętrznego darmowego narzędzia do analizy logów – Log Treasure, możesz przesyłać pliki logów z nginx, apache i ii, które pomagają analizować aspekty bezpieczeństwa strony. W końcu specjalizacja jest bardziej profesjonalna. Log Bao ma też limit rozmiaru dla przesyłanych plików, nie więcej niż 50m.

2. Nignx nie posiada mechanizmu automatycznego rozdzielania plików i przechowywania logów. Ponieważ nginx nie zapisuje automatycznie plików za ciebie. Dlatego musisz napisać własny skrypt, aby to zaimplementować.

Plik skryptu powłoki nginx_log_division.sh następującą zawartość:

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

zabij -USR1 'kot ${pid_path}'

Zasada powyższego skryptu powłoki polega najpierw na przeniesieniu i przemianowaniu poprzedniego pliku loga na jeden, a celem jest wykonanie kopii zapasowej.

Według nazwy ostatniego poniedziałku, gdy skrypt jest uruchamiany w czasie "2013-09-16", generowana nazwa pliku to "xxx.log_ 20130909.log".

Nawet jeśli polecenie mv zostało wykonane na pliku przed zabiciem -USR1, wykonywane jest 'cat ${{pid_path}'Zmieniona nazwa pliku, nginx nadal zapisuje dane logowe do nowo nazwanego pliku "xxx.log_20130909" jak zwykle. Powodem jest to, że w systemach Linux jądro szuka plików na podstawie deskryptorów plików.

---------------- rozumienie deskryptorów plików Linux

Deskryptor pliku to identyfikator całkowitoliczbowy, który jądro Linuksa nazywa dla każdego otwartego pliku.

Jądro Linuksa generuje (lub utrzymuje) "Tabela deskryptorów plikówTen deskryptor tabeli pliku rejestruje "plik otwarty przez ten proces (zidentyfikowany)".

W tym środowisku nginx jest działającym procesem, który już otworzył plik loga i loguje plik w tabeli deskryptorów plików.

Nawet jeśli ścieżka pliku loga się zmieniła, nadal można go znaleźć (można go znaleźć zgodnie z tabelą deskryptorów plików).

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

Podczas wykonywania polecenia "kill -USR1 'cat ${pid_path}'" zapisane w pliku nginx.pid to w rzeczywistości liczba (możesz ją otworzyć i zobaczyć, mam tu 894), a nginx zapisuje pid (numer procesu) swojego głównego procesu do pliku nginx.pid, dzięki czemu możesz bezpośrednio uzyskać główny numer procesu przez polecenie cat i bezpośrednio obsłużyć określony numer procesu.

kill -USR1 'cat ${pid_path}' jest równoważny

kill – sygnał USR1 894 #指定发信号 (USR1) do numerowania tego procesu.

W systemach Linux komunikuje się z "działającymi procesami" za pomocą sygnałów. W systemach Linux istnieje także wiele predefiniowanych sygnałów, takich jak SIGHUP. USR1 jest sygnałem zdefiniowanym przez użytkownika. Można go rozumieć jako sam proces definiujący, co zrobić, gdy otrzymuje ten sygnał (czyli sam autor procesu decyduje, czy go otrzymać, czy nic nie robić, i pozostawia to całkowicie deweloperowi). W nginx pisze on własny kod, aby obsłużyć ponowne otwarcie pliku logu nginx, gdy otrzymam sygnał USR1. Zasada jest następująca:

1. Główny proces nginx otrzymuje sygnał USR1 i ponownie otwiera plik logu (nazwany od nazwy logu w pliku konfiguracyjnym nginx, która jest wartością ustawioną przez access_log element w pliku konfiguracyjnym, a jeśli plik nie istnieje, automatycznie zostanie utworzony nowy plik xxx.log).

2. Następnie zmień właściciela pliku logu na "worker process", tak aby proces worker miał uprawnienia do odczytu i zapisu do pliku loga (master i worker zwykle działają jako różni użytkownicy, więc właściciel musi zostać zmieniony).

3. Główny proces nginx zamknie duplikowany plik loga (czyli plik, który został przemianowany na xxx.log_ 20130909.log właśnie za pomocą polecenia mv),i powiadamia proces roboczy o użyciu nowo otwartego pliku loga(xxx.log plik właśnie otwarty przez główny proces). Konkretna implementacja jest bardziej szczegółowa, główny proces wysyła sygnał USR1 do pracownika, a po jego otrzymaniu pracownik ponownie otwiera plik logu (czyli xxx.log uzgodniony w pliku konfiguracyjnym)

=================================== Wykonuj skrypty w regularnych odstępach czasu

Ustaw plik skryptu powłoki powyżej, aby został dodany do zaplanowanego zadania. crontab to zaplanowany proces zadań na Linuksie. Proces ten zaczyna się po włączeniu i co jakiś czas przechodzi do swojej listy, aby sprawdzić, czy są jakieś zadania do wykonania.

crontab -e

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

Otworzy się plik z dodanym powyższym kodem

Format to "ścieżka pliku powłoki do wykonania (Shell file path to be executed". * można rozumieć jako "każdy", każdą minutę, każdą godzinę, każdy miesiąc itd.

Ustawiłem skrypt, który nginx_log_division.sh uruchamia o 4 rano w poniedziałek, a jego treść polega na wygenerowaniu nowego pliku loga.

Załączone:ZakładaćnginxJak konfigurowane są logi

log_format strona '$remote_addr - $remote_user [$time_local] "$request" '

             '$status $body_bajtów_wysłanych "$http_referer" '

             '"$http_user_agent" $http_x_forwarded_for';

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

#第二个参数表示使用那个日志格式 dla każdego formatu logu identyfikowana jest nazwa, a miejsce odpowiada nazwie w log_format

Powyższe wiąże się z użyciem harmonogramowego menedżera zadań crontab.

Są też miejsca, gdzie nie ma pełnego zrozumienia i błędów. Mam nadzieję, że w przyszłości będę aktualizować.