[웹] nginx는 자동으로 접근 로그를 차단합니다

웹 액세스 로그(access_log)는 클라이언트 IP, 접근 날짜, 접근 URL 자원, 서버가 반환한 HTTP 상태 코드 등 중요한 정보를 포함한 모든 외부 클라이언트의 웹 서버에 대한 접근 동작을 기록합니다.
일반적인 웹 접속 로그는 다음과 같습니다:

112.97.37.90 - - [2013년 9월 14일:14:37:39 +0800] "GET / HTTP/1.1" 301 5 "-" "Mozilla/5.0 (Linux; U; 안드로이드 2.3.6; zh-cn; Lenovo A326 빌드/GRK39F) AppleWebKit/533.1 (KHTML, Gecko와 유사) 버전/4.0 모바일 사파리/533.1 MicroMessenger/4.5.1.259" -

계획:

1. 문제를 해결하기 위해:

방문자가 많으면 로그 데이터가 많아지고, 모두 로그 파일에 기록되면 파일이 점점 커집니다. 수백 메가바이트 크기의 파일 같은 대용량 파일 속도는 느려집니다. 로그를 쓸 때는 작업 속도에 영향을 줍니다. 또한, 접근 로그를 보고 싶을 때, 수백 메가비트 파일 다운로드와 열기가 느립니다. 서드파티 무료 로그 분석 도구인 Log Treasure를 사용하면 nginx, apache, iis 등에서 로그 파일을 업로드하여 웹사이트 보안 측면을 분석하는 데 도움을 줍니다. 결국 전문화하는 것이 더 전문적이니까요. 로그 바오는 업로드된 파일 크기에도 제한이 있으며, 최대 5천만 명을 초과하지 않습니다.

2. Nignx는 파일을 자동으로 분리하고 로그를 저장하는 메커니즘이 없습니다. nginx가 자동으로 파일을 저장하지 않기 때문입니다. 따라서 구현하려면 직접 스크립트를 작성해야 합니다.

셸 스크립트 파일은 다음 내용을 nginx_log_division.sh합니다:

# /빈/쾅

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 '캣 ${pid_path}''

위 셸 스크립트의 원리는 먼저 이전 로그 파일을 이동하고 이름을 1로 바꾸는 것이며, 목적은 백업입니다.

지난 월요일 이름에 따르면, 스크립트가 "2013-09-16" 시점에서 실행되면 생성된 파일 이름은 "xxx.log_ 20130909.log"입니다.

mv 명령어가 kill -USR1 전에 파일에서 실행되더라도 'cat ${{pid_path}'가 실행됩니다파일 이름 변경nginx는 평소처럼 새로 이름 붙여진 파일 "xxx.log_20130909"에 로그 데이터를 기록합니다. 그 이유는 리눅스 시스템에서 커널이 파일 디스크립터를 기반으로 파일을 찾기 때문입니다.

리눅스 파일 디스크립터에 대한 ---------------- 이해

파일 디스크립터는 리눅스 커널이 각 열린 파일에 대해 이름 붙이는 정수 식별자입니다.

리눅스 커널은 "파일 디스크립터 테이블이 파일 디스크립터 테이블은 "이 프로세스에 의해 열린 파일(식별됨)"을 기록합니다.

이 환경에서 nginx는 이미 로그 파일을 열어 파일 디스크립터 테이블에 기록하는 실행 중인 프로세스입니다.

로그 파일의 경로가 변경되었더라도 여전히 찾을 수 있습니다(파일 디스크립터 테이블에 따라 찾을 수 있습니다).

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

"kill -USR1 'cat ${pid_path}'" 명령을 실행할 때, nginx.pid 파일에 저장된 것은 실제로 숫자입니다(열어보면 저는 894입니다). nginx는 메인 프로세스의 pid(프로세스 번호)를 nginx.pid 파일에 기록하므로, cat 명령어를 통해 메인 프로세스 번호를 직접 얻고 지정된 프로세스 번호를 직접 조작할 수 있습니다.

kill -USR1 'cat ${pid_path}'는 다음과 같다.

이 과정을 번호 매기기 위한 신호는 –USR1 89#指定发信号4 (USR1) 신호를 보냅니다.

리눅스 시스템에서 리눅스는 신호를 통해 "실행 중인 프로세스"와 통신합니다. 리눅스 시스템에서는 SIGHUP과 같은 많은 미리 정의된 신호도 존재합니다. USR1은 사용자 정의 신호입니다. 이는 프로세스 자체가 이 신호를 받았을 때 무엇을 할지 정의하는 것으로 이해할 수 있습니다(즉, 프로세스 작성자가 직접 이 신호를 받을지 아무것도 하지 않을지 결정하고, 전적으로 개발자에게 맡깁니다). nginx에서는 USR1 신호를 받을 때 nginx가 로그 파일을 다시 열도록 하는 자체 코드를 작성합니다. 구체적인 원리는 다음과 같습니다:

1. nginx의 메인 프로세스는 USR1 신호를 수신하여 로그 파일을 다시 엽니다(nginx 구성 파일의 로그 이름에서 따온 이름으로, 구성 파일 내 access_log 항목이 설정한 값이며, 파일이 존재하지 않으면 자동으로 새 파일 xxx.log가 생성됩니다).

2. 로그 파일의 소유자를 "워커 프로세스"로 변경하여 워커 프로세스가 로그 파일에 대한 읽기 및 쓰기 권한을 가지게 합니다(마스터와 워커는 보통 서로 다른 사용자로 실행되므로 소유자를 변경해야 합니다).

3. nginx 메인 프로세스는 중복 로그 파일(방금 mv 명령어로 xxx.log 20130909.log 이름이 변경된 파일)을 닫습니다.그리고 워커 프로세스에 새로 열린 로그 파일을 사용하도록 알립니다(방금 메인 프로세스가 열린 파일을 xxx.log 말입니다). 구체적인 구현은 더 상세하며, 메인 프로세스가 USR1 신호를 작업자에게 보내고, 이 신호를 받은 후 작업자는 로그 파일(즉, 설정 파일에 합의된 xxx.log)을 다시 엽니다

=================================== 정기적으로 스크립트를 실행

위에 있는 셸 스크립트 파일을 예약된 작업에 추가하도록 설정하세요. crontab은 리눅스에서 예약된 작업 프로세스입니다. 이 과정은 전원을 켜는 시점부터 시작되며, 가끔씩 목록에 들어가 수행해야 할 작업이 있는지 확인합니다.

크론탭 -e

* 04 * * 1 /데이터/www로그/nginx_log_division.sh

위 코드가 추가된 파일이 열립니다

형식은 "실행할 셸 파일 경로"입니다. * 는 "매", 매분, 매 시간, 매달 등으로 이해할 수 있습니다.

월요일 새벽 4시에 nginx_log_division.sh 실행하도록 스크립트를 설정했고, 스크립트의 내용은 새 로그 파일을 다시 생성하는 것입니다.

첨부:설립하다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 예약 작업 관리자의 사용과 관련이 있습니다.

또한 완전한 이해가 부족하거나 실수가 있는 부분도 있습니다. 앞으로 업데이트할게요.