Nginx 로그 모니터링: 웹 트래픽 및 오류 분석을 위한 주요 명령어

Nginx 로그 모니터링은 장애 발생 시 사람들이 묻는 질문인 "지금 실제로 무슨 일이 일어나고 있나요?"에 가장 빠르게 답할 수 있는 방법인 경우가 많습니다. 메트릭은 5xx 오류가 증가했음을 알려줄 수 있습니다. 로그는 실패한 요청의 경로, 업스트림, 상태 코드, 클라이언트 IP 및 타이밍 세부 정보를 보여줄 수 있습니다.

여기에 소개된 명령어는 일반적인 Linux 도구인 tail, grep, awk, sort, uniq, less 및 압축 로그 변형을 사용합니다. 이는 실제 로그 플랫폼을 대체하는 것은 아니지만, 서버에 SSH로 접근할 수 있고 빠르고 설득력 있는 답변이 필요할 때 정확히 필요한 도구입니다.

Nginx 로그 유형 이해

Nginx는 일반적으로 nginx.conf 또는 관련 구성 파일 내에서 구성되는 두 가지 주요 로그 유형을 생성합니다.

액세스 로그 (access.log): 서버에서 처리된 모든 요청을 기록합니다. 이 로그는 사용자 행동, 트래픽 양, 지리적 분포 및 응답 시간을 이해하는 데 중요합니다. 기본적으로 필드에는 IP 주소, 요청 메서드, URI, HTTP 상태 코드, 요청 크기 및 사용자 에이전트가 포함되는 경우가 많습니다.
오류 로그 (error.log): Nginx 자체에서 발생한 진단 정보, 경고 및 심각한 오류(예: 구성 문제, 업스트림 시간 초과, 리소스 고갈)를 기록합니다. 이 로그는 서버 측 오류를 해결하기 위한 첫 번째 단계입니다.

표준 로그 위치

위치는 사용자 지정할 수 있지만, Nginx 로그는 일반적으로 대부분의 배포판에서 다음 디렉터리에서 찾을 수 있습니다.

배포판 유형	기본 로그 경로
Debian/Ubuntu	`/var/log/nginx/`
RHEL/CentOS	`/var/log/nginx/`
사용자 설치 (소스)	다름, `nginx.conf` 확인

기본 예제로 /var/log/nginx/access.log 및 /var/log/nginx/error.log를 사용하겠습니다.

1. `tail`을 사용한 실시간 모니터링

tail 명령어는 현재 서버 활동을 실시간으로 확인하는 데 필수적입니다. -f(follow) 플래그는 출력이 실시간으로 스크롤되도록 유지합니다.

실시간 액세스 트래픽 모니터링

서버에 들어오는 새 요청을 보려면 액세스 로그에 tail -f를 사용하세요.

tail -f /var/log/nginx/access.log

동시 오류 모니터링

구성 변경이나 배포를 테스트하는 동안 오류를 모니터링하는 것이 유용한 경우가 많습니다. 이는 두 개의 별도 터미널 세션을 실행하거나 multitail과 같은 도구(설치된 경우)를 사용하여 수행할 수 있습니다.

tail -f /var/log/nginx/error.log

팁: 새 항목을 따라가기 전에 마지막 100줄을 확인해야 하는 경우 tail -n 100 -f /var/log/nginx/access.log를 사용하세요.

2. `grep`을 사용한 검색 및 필터링

grep(Global Regular Expression Print)은 로그 파일 내에서 특정 줄을 찾는 데 가장 많이 사용되는 도구입니다. 상태 코드, IP 주소, 메서드 등을 기준으로 로그를 신속하게 필터링할 수 있습니다.

특정 HTTP 상태 코드 찾기

문제 해결 시 특정 오류가 발생한 모든 요청을 신속하게 식별하는 것이 중요합니다. 유사한 숫자로 인한 잘못된 일치를 방지하기 위해 상태 코드 주위에 공백을 사용합니다(예: 2000에서 200 일치 방지).

모든 404 (찾을 수 없음) 오류 찾기:

grep " 404 " /var/log/nginx/access.log

모든 5xx 서버 오류 찾기:

grep -E " 50[0-9] " /var/log/nginx/access.log

요청 경로 또는 IP 주소로 필터링

특정 클라이언트 IP 주소의 모든 요청 또는 특정 경로(예: /admin)에 대한 모든 액세스 시도를 확인하려면 다음을 수행하세요.

# 클라이언트 IP 주소로 필터링
grep "192.168.1.10" /var/log/nginx/access.log

# 특정 URL 액세스 시도 필터링
grep "/wp-login.php" /var/log/nginx/access.log

실시간 필터링

tail -f의 출력을 grep으로 파이프하여 발생하는 특정 이벤트만 실시간으로 모니터링할 수 있습니다.

# 5xx 오류만 실시간 피드
tail -f /var/log/nginx/access.log | grep -E " 50[0-9] "

3. 크고 로테이션된 로그 처리

로그 파일은 빠르게 방대해질 수 있습니다. Nginx는 일반적으로 로그 로테이션 유틸리티(logrotate)를 사용하여 gzip으로 오래된 로그를 압축합니다.

`less`로 대용량 파일 검토

전체 파일을 메모리에 로드하는 대신(터미널 세션이 중단될 수 있음) less를 사용하여 페이지별로 살펴보세요. less는 뒤로 탐색과 효율적인 검색도 지원합니다.

less /var/log/nginx/access.log
# less 내에서 'G'를 누르면 끝으로, 'g'를 누르면 처음으로 이동하며, '/'를 누르면 검색합니다.

`zgrep`으로 압축 로그 검색

수동으로 압축을 풀지 않고 로테이션된 로그(.gz 파일)를 검색하려면 일반 명령어의 z 변형(zcat, zgrep)을 사용하세요.

# 압축된 로그 파일에서 403 오류 검색
zgrep " 403 " /var/log/nginx/access.log.1.gz

4. `awk`, `cut` 및 `sort`를 사용한 구조화된 분석

특히 표준 결합 형식을 사용하는 Nginx 로그는 공백으로 구조화됩니다. 이 구조를 통해 awk 및 cut과 같은 도구가 통계 분석을 위해 특정 데이터 필드를 추출할 수 있습니다.

기본 결합 형식에서 주요 필드는 일반적으로 다음과 같습니다.

$1: 원격 IP 주소
$7: 요청된 URI
$9: HTTP 상태 코드
$10: 전송된 바이트
$12: HTTP 리퍼러
$14: 사용자 에이전트

가장 많이 요청된 페이지 찾기

이 파이프라인은 awk를 사용하여 URI($7)를 추출하고, sort로 동일한 항목을 그룹화하고, uniq -c로 개수를 세고, sort -nr로 숫자의 내림차순(가장 높은 개수 우선)으로 나열합니다.

awk '{print $7}' /var/log/nginx/access.log | \
sort | uniq -c | sort -nr | head -10

상태 코드 계산

로그에 기록된 모든 상태 코드의 분석을 신속하게 얻으려면 다음을 수행하세요.

awk '{print $9}' /var/log/nginx/access.log | \
sort | uniq -c | sort -nr

출력 예시:

높은 지연 시간 요청 식별 (기록된 경우)

Nginx 구성이 업스트림 응답 시간($upstream_response_time)을 기록하는 경우 awk를 사용하여 느린 요청(예: 1초보다 느린 요청)을 찾을 수 있습니다.

참고: 응답 시간이 12번째 필드($12)라고 가정합니다. 필드 번호를 신뢰하기 전에 log_format 구성을 확인하세요.

awk '($12 > 1.0) {print $12, $7}' /var/log/nginx/access.log | sort -nr

로그 분석 모범 사례

`grep -v`를 사용한 제외

때로는 상태 확인이나 알려진 무해한 봇과 같은 일반적인 노이즈를 필터링해야 합니다. grep의 -v 플래그는 일치를 반전시켜 패턴과 일치하지 않는 줄을 표시합니다.

# 성공적인 200 응답을 제외한 액세스 로그 보기
grep -v " 200 " /var/log/nginx/access.log

# 알려진 Googlebot 사용자 에이전트를 제외한 로그 보기
grep -v "Googlebot" /var/log/nginx/access.log

액세스 로그와 오류 로그 비교

502 또는 504 응답이 급증하는 것을 발견하면 동일한 시간대의 오류 로그를 확인하세요. 액세스 로그는 클라이언트 측 결과를 보여줍니다. 오류 로그는 종종 프록시 측 이유를 설명합니다.

grep "upstream" /var/log/nginx/error.log | tail -50
grep -E "connect\\(\\) failed|upstream timed out|no live upstreams" /var/log/nginx/error.log

예를 들어, 액세스 로그의 502와 오류 로그의 connect() failed (111: Connection refused)는 연결을 수락하지 않는 업스트림 서비스를 가리킵니다. 504와 upstream timed out은 느린 업스트림 또는 해당 요청 경로에 비해 너무 낮은 시간 초과 설정을 가리킵니다.

필드 번호 주의

많은 예제가 Nginx의 결합 로그 형식을 가정합니다. 실제 프로덕션 구성은 종종 $request_time, $upstream_response_time, $host, $request_id 또는 전달된 IP 필드를 추가합니다. 심각한 조사에서 awk '{print $9}' 명령을 사용하기 전에 활성 형식을 확인하세요.

nginx -T 2>/dev/null | grep -A3 "log_format"

로그 형식이 요청을 따옴표로 묶는 경우 공백으로 구분된 awk 필드는 간단한 확인에 여전히 작동하지만, 사용자 에이전트와 리퍼러는 값에 공백이 포함되어 있으므로 잘못 읽기 쉽습니다. 더 깊은 분석을 위해서는 로그를 파서로 보내거나 전용 액세스 로그에서 JSON 이스케이프와 같은 형식을 사용하세요.

안전한 처리

Nginx 액세스 로그에는 IP 주소 및 잠재적으로 요청 매개변수와 같은 민감한 데이터가 포함됩니다. 분석을 위해 로그를 전송할 때는 보안 프로토콜(SCP/SFTP)을 사용하고 로그 디렉터리에 대한 액세스를 권한 있는 사람(일반적으로 root 또는 syslog 사용자)으로 제한하세요.

# 권한 확인
ls -l /var/log/nginx/

실용적인 워크플로

증상부터 시작하세요. 사용자가 오류를 보고하면 상태 코드를 계산하고 실패한 경로를 분리하세요. 서버가 느리게 느껴지면 요청 타이밍 필드를 찾거나 다음 장애 발생 전에 로그 형식에 추가하세요. 특정 IP가 시끄럽다면 상위 클라이언트 주소를 계산하세요.

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

그런 다음 광범위에서 좁은 범위로 이동하세요: 상태 코드, 경로, 업스트림 오류, 시간 창, 클라이언트 패턴. 장애 기록에 사용한 정확한 명령어를 보관하세요. 그러면 다음 검토가 훨씬 쉬워지고, 다른 엔지니어가 로그가 "어땠는지"에 대한 막연한 기억에 의존하는 대신 결과를 재현하는 데 도움이 됩니다.

Nginx 로그는 일반 텍스트이며, 이는 적절한 도구를 가까이에 두었을 때 강점이 됩니다. 로그 형식을 알고, 복사된 필드 번호를 과도하게 신뢰하지 말며, 무슨 일이 일어났는지 결정하기 전에 액세스 로그 패턴과 오류 로그 메시지를 함께 짝지으세요.