NGINX 액세스 로그 및 오류 로그
전제 조건
- 여기에서 튜토리얼을 따라 이미 NGINX를 설치했습니다.
NGINX에 로그인
기본적으로 NGINX는 오류 로그와 액세스 로그라는 두 가지 유형의 로그에 이벤트를 기록합니다. Ubuntu, CentOS 또는 Debian과 같은 대부분의 인기 있는 Linux 배포판에서 액세스 및 오류 로그를 /var/log/nginx에서 찾을 수 있습니다. 핵심 NGINX 구성 파일. NGINX 액세스 로그, 오류 로그 및 이전에 활성화하지 않은 경우 활성화하는 방법에 대해 자세히 알아보십시오.
NGINX 액세스 로그란 무엇입니까?
NGINX는 사이트에 대한 모든 방문자의 활동을 액세스 로그에 기록합니다. 여기에서 어떤 파일에 액세스했는지, NGINX가 요청에 어떻게 응답했는지, 클라이언트가 사용 중인 브라우저, 클라이언트의 IP 주소 등을 확인할 수 있습니다. 액세스 로그의 정보를 사용하여 트래픽을 분석하여 시간 경과에 따른 사이트 사용량을 찾을 수 있습니다. 또한 액세스 로그를 제대로 모니터링하면 배포된 웹 애플리케이션의 결함을 찾기 위해 사용자가 비정상적인 요청을 보내는지 확인할 수 있습니다.
NGINX 오류 로그란 무엇입니까?
반면에 NGINX에 결함이 있으면 오류 로그에 이벤트를 기록합니다. 이는 구성 파일에 오류가 있는 경우 발생할 수 있습니다. 따라서 NGINX가 시작되지 않거나 갑자기 실행이 중지된 경우 오류 로그를 확인하여 자세한 내용을 확인해야 합니다. 또한 오류 로그에서 몇 가지 경고를 찾을 수 있지만 문제가 발생했음을 나타내지는 않지만 이벤트가 가까운 장래에 심각한 문제를 일으킬 수 있습니다.
NGINX 액세스 로그를 활성화하는 방법은 무엇입니까?
일반적으로 액세스 로그는 http 또는 서버 섹션에서 access_log 지시문을 사용하여 활성화할 수 있습니다. 첫 번째 인수 log_file은 필수이며 두 번째 인수 log_format은 선택 사항입니다. 형식을 지정하지 않으면 로그가 기본 결합 형식으로 작성됩니다.
access_log log_file log_format;
액세스 로그는 핵심 NGINX 구성 파일의 http 컨텍스트에서 기본적으로 활성화됩니다. 즉, 모든 가상 호스트의 액세스 로그가 동일한 파일에 기록됩니다.
http {
...
...
access_log /var/log/nginx/access.log;
...
...
}
모든 가상 호스트의 액세스 로그를 별도의 파일에 기록하여 분리하는 것이 항상 더 좋습니다. 이를 위해서는 http 섹션에 정의된 access_log 지시문을 서버 컨텍스트의 다른 access_log 지시문으로 재정의해야 합니다.
http {
...
...
access_log /var/log/nginx/access.log;
server {
listen 80;
server_name domain1.com
access_log /var/log/nginx/domain1.access.log;
...
...
}
}
NGINX를 다시 로드하여 새 설정을 적용합니다. /var/log/nginx/domain1.access.log 파일에서 domain1.com 도메인에 대한 액세스 로그를 보려면 터미널에서 다음 tail 명령을 사용하십시오.
# tail -f /var/log/nginx/domain1.access.log
액세스 로그에 사용자 정의 형식 적용
액세스 로그에 이벤트를 기록하는 데 사용되는 기본 로그 형식은 결합 로그 형식입니다. 고유한 사용자 지정 로그 형식을 만든 다음 access_log 지시문에서 사용자 지정 형식의 이름을 지정하여 기본 동작을 재정의할 수 있습니다. 다음 예는 응답의 gzip 압축률 값으로 미리 정의된 결합 형식을 확장하여 사용자 지정 로그 형식을 정의합니다. 그런 다음 access_log 지시문으로 로그 형식을 표시하여 형식이 적용됩니다.
http {
log_format custom '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" "$gzip_ratio"';
server {
gzip on;
...
access_log /var/log/nginx/domain1.access.log custom;
...
}
}
환경에 위의 로그 형식을 적용했으면 NGINX를 다시 로드합니다. 이제 액세스 로그를 추적하여 로그 이벤트의 끝에서 gzip 비율을 찾으십시오.
# tail -f /var/log/nginx/domain1.access.log
47.29.201.179 - - [28/Feb/2019:13:17:10 +0000] "GET /?p=1 HTTP/2.0" 200 5316 "https://domain1.com/?p=1" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.119 Safari/537.36" "2.75"
NGINX 오류 로그를 활성화하는 방법은 무엇입니까?
error_log 지시문은 기록할 오류 메시지의 최소 심각도 수준을 지정하여 파일, stderr 또는 syslog에 대한 오류 기록을 설정합니다. error_log 지시문의 구문은 다음과 같습니다.
error_log log_file log_level;
첫 번째 인수 log_file은 로그 파일의 경로를 정의하고 두 번째 인수 log_level은 기록할 로그 이벤트의 심각도 수준을 정의합니다. log_level을 지정하지 않으면 기본적으로 심각도 수준이 오류인 로그 이벤트만 기록됩니다. 예를 들어, 다음 예에서는 기록할 오류 메시지의 심각도 수준을 crit로 설정합니다. 또한 http 컨텍스트의 error_log 지시문은 모든 가상 호스트에 대한 오류 로그가 단일 파일에서 사용 가능함을 의미합니다.
http {
...
error_log /var/log/nginx/error_log crit;
...
}
서버 컨텍스트에서 error_log 지시문을 재정의하여 모든 가상 호스트에 대한 오류 로그를 개별적으로 기록할 수도 있습니다. 다음 예제는 서버 컨텍스트에서 error_log 지시문을 재정의하여 정확히 수행합니다.
http {
...
...
error_log /var/log/nginx/error_log;
server {
listen 80;
server_name domain1.com;
error_log /var/log/nginx/domain1.error_log warn;
...
}
server {
listen 80;
server_name domain2.com;
error_log /var/log/nginx/domain2.error_log debug;
...
}
}
위에서 설명한 모든 예는 로그 이벤트를 파일에 기록합니다. 로그 이벤트를 syslog 서버로 전송하기 위해 error_log 지시문을 구성할 수도 있습니다. 다음 error_log 지시문은 오류 로그를 디버그 형식으로 IP 주소가 192.168.10.11인 syslog 서버로 보냅니다.
error_log syslog:server=192.168.10.11 debug;
경우에 따라 오류 로그를 비활성화할 수 있습니다. 이렇게 하려면 로그 파일 이름을 /dev/null로 설정합니다.
error_log /dev/null;
Nginx 오류 로그 심각도 수준
로그 이벤트와 연결되고 우선 순위가 다른 여러 유형의 로그 수준이 있습니다. 모든 로그 수준은 아래에 나열되어 있습니다. 다음 로그 수준에서는 디버그가 최우선 순위이며 나머지 수준도 포함됩니다. 예를 들어 error를 로그 수준으로 지정하면 crit, alert 및 emergency로 레이블이 지정된 로그 이벤트도 캡처합니다.
- emerg: 시스템이 불안정할 때 긴급 메시지입니다.
- 경고: 심각한 문제에 대한 경고 메시지입니다.
- 심각한 문제: 즉시 처리해야 하는 중요한 문제입니다.
- 오류: 오류가 발생했습니다. 페이지를 처리하는 동안 문제가 발생했습니다.
- 경고: 조사해야 한다는 경고 메시지입니다.
- 알림: 무시할 수 있는 간단한 로그 알림입니다.
- 정보: 알고 싶은 정보 메시지입니다.
- 디버그: 오류 위치를 정확히 찾아내는 데 사용되는 디버깅 정보.
요약
NGINX의 액세스 및 오류 로그는 사용자 활동에 대한 탭을 유지할 뿐만 아니라 디버깅 프로세스에서 시간과 노력을 절약해 줍니다. 또한 원하는 대로 더 많은 정보가 필요한 경우 액세스 로그를 사용자 지정할 수도 있습니다. 이 두 파일에는 NGINX 서버의 더 나은 유지 관리를 위한 모든 단서가 포함되어 있으므로 액세스 및 오류 로그를 활성화하는 것이 항상 더 좋습니다.