Nginx 관측 가능성 모범 사례¶

배경 소개¶

Nginx는 오픈소스, 무료, 고성능 HTTP 및 리버스 프록시 서버이며, IMAP/POP3 프록시 서버로도 사용할 수 있습니다. Nginx는 비동기 논블로킹(Asynchronous Non-blocking) 작업 모델을 채택하여 높은 동시성과 낮은 리소스 소비를 제공하며, 고도로 모듈화된 설계로 확장성이 뛰어납니다. 정적 파일 처리, 리버스 프록시 요청 등에서 큰 장점을 보이며, 배포 및 유지보수가 간편하여 대부분의 기업에서 Nginx를 사용합니다. 현재 Nginx가 가장 많이 사용되는 몇 가지 사례는 다음과 같습니다.

• 웹 서버(정적 리소스 서버)

• 로드 밸런싱(트래픽 분산 부하)

• 리버스 프록시
• 기타

Nginx는 단순하지만, 적용 범위가 넓기 때문에 기업 내에서 상대적으로 매우 중요합니다. 따라서 Nginx의 상태와 안정성을 보장하는 것은 기업의 운영 담당자가 매우 관심을 가지는 사항입니다. Nginx 자체에 내장된 성능 지표 모듈 with-http_stub_status_module을 사용하면 Nginx 관련 데이터(예: 요청 연결 수, 처리 연결 수 등)를 직접 얻을 수 있습니다. 또한 Nginx 로그(access.log, error.log)를 사용하여 구체적인 요청 수준의 분석(예: PV 수, UV 수, 요청 오류 통계 등)을 수행할 수 있습니다. 이 두 가지 데이터를 결합하면 Nginx 자체의 상태를 빠르게 파악할 수 있습니다.

• Nginx(with-http_stub_status_module)

• Nginx 로그:

예시는 다음과 같습니다.

Nginx 자체에서 Nginx 상태를 파악할 수 있는 충분한 데이터 소스를 제공하지만, 텍스트 형식의 데이터나 로그 형식의 데이터는 먼저 보기에 불편하고 미관상 좋지 않습니다. 또한 이러한 데이터 형식은 Nginx 관련 요청 수나 서버 요청 상태의 변화 추세를 실시간으로 파악할 수 없습니다. 그렇다면 이러한 데이터나 지표를 빠르게 시각화할 수 있는 유용한 도구는 무엇일까요? 현재 기업 내에서는 로그 처리 도구(ELK, Splunk)를 사용하여 Nginx 로그를 처리하고 시각화하는 경우가 많으며, Nginx 성능 데이터는 시각화 도구를 사용하여 데이터를 표시합니다. 이 두 가지 방식은 데이터가 분리되거나 솔루션 비용이 높아지는 문제가 있을 수 있습니다. 이 문제를 해결하기 위해 DataKit은 소스에서 처리하기로 결정했습니다. 예를 들어 데이터 수집은 동일한 구성 항목을 사용하여 Nginx 성능 상태와 로그를 동시에 수집하고, 데이터 표시도 동일한 플랫폼의 동일한 인터페이스에서 이루어져 사용자의 작업 효율성을 높입니다.

DataKit 구성 인터페이스 및 최종 모니터링 효과:

Nginx 모니터링 Guance 연동 전제 조건¶

계정 등록¶

Guance로 이동하여 계정을 등록하고, 등록된 계정/비밀번호로 로그인합니다.

Datakit 설치¶

명령어 가져오기¶

[통합] 모듈을 클릭하고 오른쪽 상단의 [DataKit 설치 명령어 빠르게 가져오기]를 클릭한 후, 운영 체제 및 시스템 유형에 따라 적절한 설치 명령어를 선택합니다.

설치 실행¶

DataKit 설치 명령어를 복사하여 모니터링 대상 서버에서 직접 실행합니다.

• 설치 디렉터리 /usr/local/datakit/

• 로그 디렉터리 /var/log/datakit/

• 메인 설정 파일 /usr/local/datakit/conf.d/datakit.conf
• 플러그인 설정 디렉터리 /usr/local/datakit/conf.d/

DataKit 설치가 완료되면 기본적으로 Linux 호스트 일반 플러그인이 활성화됩니다. 이는 인프라-기본 제공 보기에서 확인할 수 있습니다.

[인프라] 모듈을 클릭하면 DataKit이 설치된 모든 호스트 목록 및 기본 정보(호스트명, CPU, 메모리 등)를 확인할 수 있습니다.

모니터링 시나리오 생성:¶

DataFlux에 로그인하여 특정 프로젝트 워크스페이스로 이동합니다. 시나리오 생성 -> 빈 시나리오 생성 -> 보기 템플릿을 클릭합니다(DF 시스템 보기의 Nginx 보기 템플릿을 직접 선택하는 것을 권장합니다).

모니터링 보기:

Nginx 수집 관련 설정 활성화 단계:¶

datakit.inputs에서 Nginx.conf 활성화 전제 조건:¶

Nginx(with-http_stub_status_module) 모듈이 활성화되어 있는지 확인합니다. 해당 모듈이 설치되지 않은 경우 설치해야 합니다.

Linux 환경:¶

yum으로 설치된 Nginx는 콘솔에서 nginx -V를 입력하여 with-http_stub_status_module 모듈이 활성화되어 있는지 확인합니다. 모듈이 이미 존재하는 경우 Datakit에서 Nginx.inputs 활성화 단계로 바로 이동할 수 있습니다.

$ nginx -V

사용자 정의 설치된 Nginx의 경우 콘솔에서 /usr/local/nginx/sbin/nginx -V를 입력하여 확인합니다. 모듈이 이미 존재하는 경우 Datakit에서 Nginx.inputs 활성화 단계로 바로 이동할 수 있습니다.

$ /usr/local/nginx/sbin/nginx -V

Windows 환경:¶

powershell에서 .\nginx.exe -V를 실행하여 확인합니다. 모듈이 이미 존재하는 경우 Datakit에서 Nginx.inputs 활성화 단계로 바로 이동할 수 있습니다.

$  .\nginx.exe -V

with-http_stub_status_module 모듈 설치(Linux):¶

이미 모듈이 설치된 경우 이 단계를 건너뛰십시오.

이 모듈을 활성화하려면 Nginx를 다시 컴파일해야 합니다. 구체적인 명령어는 다음과 같습니다.

./configure --with-http_stub_status_module

configure 파일 위치 확인 방법: find /| grep configure |grep nginx

$ find /| grep configure |grep nginx
$ cd /usr/local/src/nginx-1.20.0/
$ ./configure --with-http_stub_status_module

nginx.conf에 nginx_status location 추가 (예시)¶

$ cd /etc/nginx   
   //nginx 경로는 실제 상황에 따라 결정
$ vim nginx.conf

$  server{
     listen 80;   
     server_name localhost;
     //포트는 사용자 정의 가능

      location /nginx_status {
          stub_status on;
          allow 127.0.0.1;
          deny all;
                             }

          }

다음으로 nginx -s reload를 실행하여 Nginx를 다시 로드합니다.

모듈이 정상적으로 활성화되었는지 확인합니다.

Linux 환경: curl http://127.0.0.1/nginx_status

Windows 환경: 브라우저에서 http://127.0.0.1/nginx_status 접속

다음과 같은 데이터가 표시됩니다.

Datakit에서 Nginx.inputs 활성화:¶

Linux 환경:¶

$ cd /usr/local/datakit/conf.d/nginx/
$ cp nginx.conf.sample nginx.conf
$ vim nginx.conf

다음 내용을 수정합니다.

[[inputs.nginx]]
    url = http://localhost/nginx_status
[inputs.nginx.log]
    files = ["/var/log/nginx/access.log","/var/log/nginx/error.log"]

pipeline = "nginx.p"
# pipeline 파일은 nginx 로그를 파싱하여 완전한 텍스트 파일을 key-value 형태의 키-값 쌍으로 변환하여 df 플랫폼에서 시각화할 수 있도록 합니다.
# pipeline에 설정된 nginx.p는 기본적으로 /usr/local/datakit/pipeline/ 디렉터리에 위치하며, access 및 error 형식 관련 파싱 구문이 내장되어 있습니다.

nginx.conf 파일을 저장한 후 datakit을 재시작합니다.

# pipeline을 사용자 정의하여 수정해야 하는 경우 [텍스트 처리(Pipeline)]를 참조하십시오.

Windows 환경:¶

$ C:\Program Files\datakit\conf.d\nginx로 이동

$ nginx.conf.sample을 복사하여 nginx.conf로 이름 변경

$ nginx.conf 파일 편집

다음 내용을 수정합니다.

[[inputs.nginx]]
    url = http://localhost/nginx_status
[inputs.nginx.log]
    files = ["/logs/access.log","/ logs/error.log"]

Nginx 및 관련 지표 소개¶

Nginx란 무엇인가?¶

Nginx("engine X"로 발음)는 널리 사용되는 HTTP 서버이자 리버스 프록시 서버입니다. HTTP 서버로서 Nginx는 적은 메모리 소비로 정적 콘텐츠를 매우 효율적이고 안정적으로 제공합니다. 리버스 프록시로서 여러 백엔드 서버 또는 캐시 및 로드 밸런싱과 같은 기타 애플리케이션을 위한 단일 제어 액세스 지점으로 사용할 수 있습니다. Nginx는 오픈소스 버전을 다운로드하여 사용하거나, 기능이 더 풍부한 상용 배포판인 Nginx Plus를 통해 사용할 수 있습니다. Nginx는 메일 프록시 및 범용 TCP 프록시로도 사용할 수 있지만, 이 문서에서는 이러한 시나리오의 모니터링에 대해 직접 다루지 않습니다.

Nginx 주요 지표¶

Nginx를 모니터링하면 두 가지 유형의 문제를 발견할 수 있습니다. 1) Nginx 자체의 리소스 문제, 2) 웹 인프라 내 다른 부분의 개발 문제입니다. 대부분의 Nginx 사용자는 모니터링을 통해 초당 요청 수(requests per second) (최종 사용자 활동 조합에 대한 개괄적인 보기 제공), 서버 오류율(server error rate) (전체 요청 중 서버 요청 처리 실패 또는 무효 비율), 요청 처리 시간(request processing time) (서버가 클라이언트 요청을 처리하는 데 소요되는 시간으로, 환경 내 요청 속도 저하 또는 기타 문제를 나타낼 수 있음)과 같은 지표를 통해 이점을 얻을 수 있습니다.
일반적으로 최소한 세 가지 주요 범주의 지표를 주목해야 합니다.

• 기본 활동 지표

• 오류 지표

• 성능 지표

아래에서는 각 범주에서 가장 중요한 몇 가지 Nginx 지표와 특별히 언급할 가치가 있는 일반적인 사용 사례인 Nginx Plus를 사용한 리버스 프록시 지표에 대해 설명합니다. 또한 선택한 그래프 또는 모니터링 도구를 사용하여 이러한 모든 지표를 모니터링하는 방법도 소개합니다.

기본 활동 지표¶

어떤 Nginx 사용 사례를 사용하든, 서버가 수신하는 클라이언트 요청 수와 해당 요청을 처리하는 방식을 모니터링하려고 할 것입니다.

Nginx Plus는 오픈소스 Nginx와 마찬가지로 기본 활동 지표를 보고할 수 있지만, 약간 다른 지표를 보고하는 보조 모듈도 제공합니다. 먼저 오픈소스 Nginx에 대해 논의한 다음 Nginx Plus에서 제공하는 추가 보고 기능에 대해 논의합니다.

Nginx¶

아래 그림은 클라이언트 연결의 수명 주기와 Nginx의 오픈소스 버전이 연결 중에 지표를 수집하는 방법을 보여줍니다.

Accepts(수락), Handled(처리) 및 Requests(요청)는 카운터가 계속 증가합니다. Active(활성), Waiting(대기), Reading(읽기) 및 Writing(쓰기)은 요청량에 따라 변경됩니다.

Nginx가 운영 체제에서 연결 요청을 가져오면 카운터가 증가합니다. 작업자가 해당 요청에 대한 연결을 가져올 수 없는 경우(새 연결을 설정하거나 열린 연결을 재사용하여) 연결이 끊어집니다. 일반적으로 리소스 제한(예: Nginx의 worker_connections 제한)에 도달했기 때문에 연결이 끊어집니다.

• waiting(대기): 현재 활성 요청이 없으면 활성 연결이 "waiting" 상태가 될 수도 있습니다. 새 연결은 이 상태를 건너뛰고 직접 Reading으로 이동할 수 있습니다. 가장 일반적인 경우는 "accept filter" 또는 "delayed accept"를 사용하는 경우로, Nginx가 응답을 시작하기에 충분한 데이터가 있을 때까지 계속 진행하지 않습니다. 연결이 keep-alive로 설정된 경우 응답 전송 후 연결도 "waiting" 상태가 됩니다.

• reading(읽기): 요청이 수신되면 연결은 대기 상태를 종료하고 요청 자체는 읽기 중인 것으로 간주됩니다. 이 상태에서 Nginx는 클라이언트 요청 헤더를 읽고 있습니다. 요청 헤더는 일반적으로 가벼우므로 일반적으로 빠른 작업입니다.

• writing(쓰기): 요청을 읽은 후 해당 요청은 쓰기 중인 것으로 간주되며, 응답이 클라이언트에 반환될 때까지 이 상태를 유지합니다. 즉, Nginx가 업스트림 시스템(Nginx 뒤에 있는 시스템)의 결과를 기다리는 동안 Nginx가 응답을 처리할 때 요청이 쓰기 중입니다. 요청은 일반적으로 대부분의 시간을 쓰기 상태에서 보냅니다.

일반적으로 연결은 한 번에 하나의 요청만 지원합니다. 이 경우 활성 연결 수 == 대기 연결 + 읽기 요청 + 쓰기 요청입니다. 그러나 HTTP/2는 연결을 통해 여러 개의 동시 요청/응답을 멀티플렉싱할 수 있으므로 Active가 Waiting, Reading 및 Writing의 합계보다 작을 수 있습니다.

Nginx Plus¶

위에서 언급한 바와 같이 Nginx Plus는 오픈소스 Nginx의 모든 지표를 제공하지만, Nginx Plus는 추가 지표도 표시할 수 있습니다. 이 섹션에서는 Nginx Plus에서만 사용할 수 있는 지표를 소개합니다.

Accepted(수락), Dropped(폐기) 및 Total(전체)의 카운터는 계속 증가합니다. Active(활성), Idle(유휴) 및 Current(현재)는 각 상태의 현재 연결 수 또는 총 요청 수를 추적하므로 요청량이 증가하거나 감소함에 따라 증가하거나 감소합니다.

Nginx Plus 작업자가 운영 체제에서 연결 요청을 Accepted(수락)하면 카운터가 증가합니다. 작업자가 해당 요청에 대한 연결을 가져올 수 없는 경우(새 연결을 설정하거나 열린 연결을 재사용하여) 연결은 Dropped(폐기)되고 폐기 횟수가 증가합니다. 일반적으로 리소스 제한(예: Nginx Plus의 worker_connections 제한)에 도달했기 때문에 연결이 끊어집니다.

Active(활성) 및 Idle(유휴)은 위에서 설명한 대로 오픈소스 Nginx의 "active" 및 "waiting" 상태와 동일하지만, 한 가지 중요한 예외가 있습니다. 오픈소스 Nginx에서 "waiting"은 "active" 범위에 포함되지만, Nginx Plus에서는 "idle" 연결이 "active" 수에서 제외됩니다. Current(현재)는 오픈소스 Nginx의 통합된 "Reading+Writing" 상태와 동일합니다.

Total(전체)은 클라이언트 요청의 누적 횟수입니다. 단일 클라이언트 연결이 여러 요청을 포함할 수 있으므로 이 숫자는 연결의 누적 횟수보다 훨씬 클 수 있습니다. 실제로 (total / accepted)는 연결당 평균 요청 수를 나타냅니다.

알림 지표: 연결 끊김¶

Dropped(폐기)된 연결 수는 accept(수락)와 handled(처리) 간의 차이와 같거나 Nginx Plus에서 제공하는 지표를 직접 사용할 수 있습니다. 정상적인 상황에서 끊어진 연결은 0이어야 합니다. 단위 시간당 연결 끊김 비율이 상승하기 시작하면 리소스 포화 상태를 유발할 수 있는 가능한 요인을 찾으십시오.

알림 지표: 초당 요청¶

고정된 시간 간격으로 요청 데이터(Nginx 오픈소스 버전의 Requests, 또는 Nginx Plus의 Total)를 샘플링하면 단위 시간(일반적으로 분 또는 초)당 수신된 요청 수를 알 수 있습니다. 이 지표를 모니터링하면 합법적인 것이든 악의적인 것이든 유입되는 네트워크 트래픽의 급증 또는 갑작스러운 감소(일반적으로 문제가 있음을 나타냄)를 경고할 수 있습니다. 초당 요청의 급격한 변화는 환경 어딘가에서 문제가 발생하고 있음을 알려줄 수 있지만, 문제가 발생한 위치를 정확히 알려주지는 않습니다. URL에 관계없이 모든 요청이 계산됩니다.

활동 지표 수집¶

오픈소스 Nginx는 간단한 상태 페이지에서 이러한 기본 서버 지표를 공개합니다. 상태 정보가 표준화된 형식으로 표시되므로 거의 모든 그래프 또는 모니터링 도구를 구성하여 관련 데이터를 구문 분석하고 분석, 시각화 또는 알림을 보낼 수 있습니다. Nginx Plus는 더 풍부한 데이터를 가진 JSON feed를 제공합니다. 지표 수집 활성화에 대한 자세한 내용은 Nginx 지표 수집에 대한 관련 기사를 참조하십시오.

오류 지표¶

Nginx 오류 측정 기준은 서버가 유효한 요청을 처리하는 대신 오류를 반환했음을 알려줍니다. 클라이언트 오류는 4xx 상태 코드로, 서버 오류는 5xx 상태 코드로 표시됩니다.

알림 지표: 서버 오류율¶

서버 오류율은 단위 시간(일반적으로 1~5분)당 5xx 오류 수(예: "502 Bad Gateway")를 총 요청 수(1xx, 2xx, 3xx, 4xx, 5xx 포함)로 나눈 값과 같습니다. 시간이 지남에 따라 오류율이 상승하기 시작하면 조사가 필요할 수 있습니다. 갑자기 증가하면 긴급 조치가 필요할 수 있습니다. 클라이언트가 최종 사용자에게 오류를 보고할 수 있기 때문입니다.

클라이언트 오류에 대한 참고 사항: 4xx는 클라이언트의 오류를 더 많이 나타내며, 특정 URL에 대한 구체적인 정보를 제공하지 않기 때문에 4xx에서 얻을 수 있는 정보는 제한적입니다. 즉, 4xx의 변화는 노이즈일 수 있습니다. 예를 들어, 웹 스캐너가 취약점을 맹목적으로 찾는 경우입니다.

오류 지표 수집¶

오픈소스 Nginx는 관측 가능성에 사용할 수 있는 오류율을 직접 제공하지 않지만, 이 정보를 캡처하는 두 가지 방법이 있습니다.

1. 상용으로 지원되는 Nginx Plus에 포함된 확장 상태 모듈 사용

2. Nginx의 로그 모듈을 구성하여 액세스 로그에 응답 코드를 기록

이 두 가지 방법에 대한 자세한 내용은 Nginx 지표 수집 관련 기사를 참조하십시오.

성능 지표¶

경고 지표: 요청 처리 시간¶

Nginx가 기록하는 요청 시간 측정 항목은 첫 번째 클라이언트 바이트를 읽는 순간부터 요청이 완료될 때까지 각 요청의 처리 시간을 기록합니다. 긴 응답 시간은 업스트림, 즉 서버 측의 응답 문제를 나타낼 수 있습니다.

처리 시간 지표 수집¶

Nginx 및 Nginx Plus 사용자는 $request_time 변수를 액세스 로그 형식에 추가하여 처리 시간 데이터를 캡처할 수 있습니다. 모니터링을 위한 로그 구성에 대한 자세한 내용은 Nginx 로그 관련 기사를 참조하십시오.

리버스 프록시 지표¶

Nginx의 가장 일반적인 용도는 리버스 프록시입니다. 상용 버전의 Nginx Plus는 리버스 프록시 설정과 관련된 백엔드(또는 "업스트림") 서버에 대한 많은 지표를 공개합니다. 이 섹션에서는 Nginx Plus 사용자가 주목해야 할 몇 가지 주요 업스트림 지표에 중점을 둡니다.

Nginx Plus는 먼저 그룹별로 업스트림의 지표를 세분화한 다음 개별 서버별로 세분화합니다. 예를 들어 리버스 프록시가 요청을 5개의 업스트림 웹 서버에 분산하는 경우, 개별 서버 중 과부하된 서버가 있는지, 업스트림 서버 그룹에 좋은 응답 시간을 보장할 수 있을 만큼 충분한 정상 서버가 있는지 한눈에 확인할 수 있습니다.

활동 지표¶

각 업스트림 서버의 활성 연결 수는 리버스 프록시가 서버 그룹 내에서 작업을 올바르게 분산하고 있는지 확인하는 데 도움이 됩니다. Nginx를 로드 밸런서로 사용하는 경우, 특정 서버가 처리하는 연결 수에 현저한 편차가 있다면 해당 서버가 요청을 제때 처리하는 데 어려움을 겪고 있거나, 사용 중인 로드 밸런싱 방법(예: 라운드 로빈 또는 IP 해시)이 트래픽 패턴에 최적화되지 않았음을 나타낼 수 있습니다.

오류 지표¶

위의 오류 지표 섹션을 다시 살펴보면, "502 Bad Gateway" 또는 "503 Service Temporarily Unavailable"과 같은 5xx(서버 오류) 코드는 전체 응답 코드에서 차지하는 비율을 모니터링할 가치가 있는 지표입니다. Nginx Plus를 사용하면 각 업스트림 서버의 5xx 상태 코드 수와 총 응답 수를 쉽게 확인하여 특정 서버의 오류율을 파악할 수 있습니다.

가용성 지표¶

웹 서버 상태에 대한 또 다른 관점에서, Nginx는 각 그룹에서 현재 사용 가능한 서버 수를 통해 업스트림 그룹의 상태를 쉽게 모니터링할 수 있도록 합니다. 대규모 리버스 프록시 설정에서는 사용 가능한 서버 풀이 부하를 처리할 수 있는 한 개별 서버의 가동 상태에 크게 신경 쓰지 않을 수 있습니다. 그러나 각 업스트림 그룹에서 실행 중인 서버의 총 수를 모니터링하면 웹 서버의 전반적인 상태를 포괄적으로 파악할 수 있습니다.

업스트림 지표 수집¶

Nginx Plus의 업스트림 지표는 Nginx Plus 모니터링 대시보드에 공개되며, JSON 인터페이스를 통해 거의 모든 외부 모니터링 플랫폼에 지표를 제공할 수 있습니다.

결론¶

이 문서에서는 Nginx 서버에서 모니터링할 수 있는 가장 유용한 몇 가지 지표를 다루었습니다. Nginx를 처음 사용하는 경우 아래 목록의 대부분 또는 모든 지표를 모니터링하면 네트워크 인프라의 상태 및 활동 수준에 대한 가시성을 확보할 수 있습니다.

• 연결 끊김

• 초당 요청

• 서버 오류율
• 요청 처리 시간

궁극적으로는 자신의 인프라 및 사용 사례와 특히 관련된 더 전문적인 다른 지표를 인식하게 될 것입니다. 물론 모니터링할 내용은 보유한 도구와 사용 가능한 지표에 따라 달라집니다.

더 자세한 내용은 다음을 참조하십시오.¶

DataKit을 사용하여 Nginx 지표 수집하는 방법