NGINX Ingress Controller 로깅, 모니터링 가이드

NGINX Ingress Controller 로깅, 모니터링 가이드입니다.

목차

1. 로깅
  1-1. Ingress Controller 프로세스 로그
  1-2. NGINX 로그
2. 상태 페이지
  2-1. stub 상태 액세스
  2-2. 라이브 모니터링 대시보드에 액세스하기
3. Prometheus
  3-1. 메트릭 활성화
  3-2. Helm 사용하기
  3-3. 메트릭 정보
4. Service Insight
  4-1. Service Insight 엔드포인트 활성화
  4-2. 통계 및 HTTP 응답코드

1. 로깅

NGINX Ingress Controller는 Ingress Controller 프로세스(NGINX 구성을 생성하고 NGINX를 다시 로드하여 적용하는 프로세스)의 로그와 NGINX 액세스 및 오류 로그를 출력합니다. 모든 로그는 Ingress Controller 프로세스의 표준 출력 및 오류로 전송됩니다. 로그를 보려면 아래와 같이 명령을 실행합니다.

kubectl logs <nginx-ingress-pod> -n nginx-ingress

1-1. Ingress Controller 프로세스 로그

프로세스 로그는 Ingress Controller cli 인수를 통해 구성되며 로그의 세부 수준을 성정합니다. 기본값은 1이며, 최소 로그 양이 보고됩니다. Ingress Controller가 Kubernetes API에서 업데이트를 가져오고, NGINX 구성을 생성하고, NGINX를 다시 로드하는 방법을 볼 수 있습니다.
Ingress Controller cli 인수에 대한 문서도 참조해보세요.

1-2. NGINX 로그

NGINX에는 두 개의 로그가 포함됩니다.

• 액세스 로그 , NGINX가 요청이 처리된 직후에 액세스 로그에 클라이언트 요청에 대한 정보를 기록합니다. 액세스 로그는 로깅 관련 ConfigMap 키를 통해 구성됩니다.
  
  • log-format : HTTP 및 HTTPS 트래픽의 경우.
  • stream-log-format : TCP, UDP, TLS 패스스루 트래픽용입니다.
  • access-log-off : ConfigMap 키를 사용하여 액세스 로깅을 비활성화할 수 있습니다.
    
• 오류 로그 , NGINX가 다양한 심각도 수준의 발생한 문제에 대한 정보를 기록합니다. 
  error-log-level ConfigMap 키를 통해 구성됩니다.
  디버그 로깅을 활성화하려면 수준을 설정하고 cli 인수 debug 도 설정하여 NGINX가 디버그 바이너리로 시작되도록 합니다 .

NGINX 관리자 가이드에서 NGINX 로그 에 대한 문서도 참조하세요 .

2. 상태 페이지

NGINX stub_status와 NGINX Plus의 대시보드에 액세스하는 방법을 설명합니다.

2-1. stub 상태 액세스

조건 :
1. stub 상태는 기본적으로 활성화 되어있습니다. nginx-status cli 인수가 false로 설정되어 있는지 확인하세요.
2. stub 상태는 기본적으로 8080포트에서 사용할 수 있습니다. nginx-status-port cli 인수로 사용자 정의할 수 있습니다. 8080에 없는경우 아래의 kubectl proxy 명령을 수정하세요.

stub 상태에 액세스 :
1. 다음 명령을 사용하여 로컬 8080포트와 NGINX Ingress Controller pod 8080포트를 연결합니다.

kubectl port-forward <nginx-ingress-pod> 8080:8080 --namespace=nginx-ingress

2. http://127.0.0.1:8080/stub_status 로 브라우저를 열어서 상태를 확인하세요.

외부에서 스텁 상태에 액세스하려는 경우( kubectl port-forward)
상태에 대한 액세스를 허용하려는 IP/CIDR로 -nginx-status-allow-cidrs cli 인수를 구성합니다 .
기본적으로 액세스는 127.0.0.1,::1 에 대해 허용됩니다.
Ingress Controller Pod가 사용 가능한 IP/포트를 사용하여 /stub_status 경로에서 스텁 상태를 연결합니다. (http://127.0.0.1/stub_status)

2-2. 라이브 모니터링 대시보드에 액세스하기

조건 :
1. stub 상태는 기본적으로 활성화 되어있습니다. nginx-status cli 인수가 false로 설정되어 있는지 확인하세요.
2. stub 상태는 기본적으로 8080포트에서 사용할 수 있습니다. nginx-status-port cli 인수로 사용자 정의할 수 있습니다. 8080에 없는경우 아래의 kubectl proxy 명령을 수정하세요.

stub 상태에 액세스 :
1. 다음 명령을 사용하여 로컬 8080포트와 NGINX Ingress Controller pod 8080포트를 연결합니다.

kubectl port-forward <nginx-ingress-pod> 8080:8080 --namespace=nginx-ingress

2. 브라우저에서 http://127.0.0.1:8080/dashboard.html을 열어 대시보드에 접속하세요.

외부에서 대시보드에 액세스하려는 경우( kubectl port-forward)
상태에 대한 액세스를 허용하려는 IP/CIDR로 -nginx-status-allow-cidrs cli 인수를 구성합니다 .
기본적으로 액세스는 127.0.0.1,::1 에 대해 허용됩니다.

Ingress Controller Pod가 사용 가능한 IP/포트를 사용하여 /dashboard.html 경로에서 대시보드를 연결합니다.

참고 : 
대시보드가 ​​메트릭을 가져오는 데 사용하는 /api 도 액세스할 수 있습니다. 경로를 사용하세요.
App Protect DoS의 경우 경로를 사용하세요 /api/dos. API가 읽기 전용 모드로 구성되어 있다는 점에 유의하세요.

3. Prometheus

NGINX Ingress Controller는 Prometheus 형식으로 메트릭을 노출합니다. 여기에는 NGINX/NGINX Plus 및 Ingress Controller 메트릭이 포함됩니다.

3-1. 메트릭 활성화

매니페스트 사용

Ingress Controller를 설치하기 위해 Kubernetes 매니페스트 (Deployment 또는 DaemonSet)를 사용하는 경우 Prometheu 메트릭을 활성화 하려면 다음과 같이 수행해야합니다.

1. -enable-prometheus-metrics cli 인수로 Ingress Controller를 실행합니다. Ingress Controller는 /metrics의 경로와 9113 포트로 Prometheus 형식으로 NGINX 또는 NGINX Plus 메트릭을 노출합니다. (-prometheus-metrics-listen-port cli 인수로 포트를 사용자 정의할 수 있습니다.)
2. Prometheus 엔드포인트에 TLS를 활성화하려면 -prometheus-tls-secret cli 인수를 통하여 구성합니다.
3. Ingress Controller Pod yaml에서 Ingress Controller 컨테이너 포트 목록에 Prometheus 포트를 추가합니다.

- name: prometheus
  containerPort: 9113

4. Ingress Controller Pod yaml에서 다음을 추가하여 Prometheus가 Ingress Controller를 인식하도록 합니다. (Prometheus가 Pod의 주석을 분석하여 대상을 검색하도록 구성되어 있다고 가정합니다.)

annotations:
    prometheus.io/scrape: "true"
    prometheus.io/port: "9113"
    prometheus.io/scheme: http

3-2. Helm 사용하기

Helm을 사용 하여 Ingress Controller를 설치하는 경우 Prometheus 메트릭을 활성화하려면  prometheus.*Helm 차트의 매개변수를 구성합니다. Helm으로 설치 문서를 참조하세요.

ServiceMonitor 사용

Helm 으로 배포할 때 및 매개변수를 사용하여 Service및 리소스를 배포할 수 있습니다 . 이러한 리소스가 배포되면 NGINX Ingress Controller에서 노출된 Prometheus 메트릭을 Prometheus Operator 배포와 함께 리소스를 사용하여 확인할 수 있습니다.. ServiceMonitorprometheus.service.*prometheus.serviceMonitor.*Prometheus

Prometheus-operator ServiceMonitor CRD

$ LATEST=$(curl -s https://api.github.com/repos/prometheus-operator/prometheus-operator/releases/latest | jq -cr .tag_name)

$ curl https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/$LATEST/example/prometheus-operator-crd/monitoring.coreos.com_servicemonitors.yaml | kubectl create -f -

3-3. 메트릭 정보

ngress Controller는 다음과 같은 메트릭을 내보냅니다.

• NGINX/NGINX Plus 메트릭:
  • NGINX/NGINX Plus에서 내보낸 메트릭에 대한 자세한 내용은 NGINX Prometheus Exporter 개발자 문서를 참조하세요 .
    
  • 루트 저장소 폴더에 NGINX Plus 메트릭에 대한 Grafana 대시보드가 있습니다.
    
  • Ingress Controller에서 계산됨:
    • controller_upstream_server_response_latency_ms_count : NGINX가 업스트림 서버에 연결을 설정한 후부터 NGINX가 응답 본문의 마지막 바이트를 수신할 때까지의 버킷 응답 시간. 참고 : 업스트림에 대한 메트릭은 트래픽이 업스트림으로 전송될 때까지 사용할 수 없습니다. 메트릭은 기본적으로 활성화되지 않습니다. 메트릭을 활성화하려면 enable-latency-metrics cli 인수를 설정합니다.
      
• Ingress Controller 메트릭
  • controller_nginx_reloads_totalreasonendpointsother : 성공적인 NGINX 재로드 횟수. 여기에는 2가지 가능한 값이 있는 항목이 포함됩니다. (재로드의 이유는 엔드포인트 업데이트입니다.) 및 x(재로드는 인그레스 업데이트와 같은 엔드포인트 업데이트가 아닌 다른 것으로 인해 발생했습니다).
    
  • controller_nginx_reload_errors_total : 실패한 NGINX 재로드 횟수.
    
  • controller_nginx_last_reload_status : 마지막 NGINX 재로드 상태, 0은 down, 1은 up을 의미합니다.
    
  • controller_nginx_last_reload_milliseconds : 마지막 NGINX 재로드부터의 지금까지의 시간입니다. (ms)
    
  • controller_nginx_worker_processes_total : NGINX 워커 프로세스 수. 이 메트릭에는 두 가지 가능한 값 (이전 의 종료 프로세스) 또는 (현재 세대의 프로세스)이 있는 상수 레이블이 포함됩니다.
    
  • controller_ingress_resources_total : 처리된 Ingress 리소스 수. 이 메트릭에는 Ingress 리소스를 유형(regular, minion or master)별로 그룹화하는 레이블 유형이 포함됩니다. 참고 : 이 메트릭은 master가 없는 minion은 계산하지 않습니다.
    
  • controller_virtualserver_resources_total : 처리된 VirtualServer 리소스의 수.
    
  • controller_virtualserverroute_resources_total : 처리된 VirtualServerRoute 리소스의 수. 참고 : 이 메트릭은 VirtualServer에서 참조가 있는 VirtualServerRoutes만 계산합니다.
    
  • location_zone(upstream 서비스) 메트릭:
    • location_zone_sent : 클라이언트에 전송된 바이트 수.
      
    • location_zone_received : 클라이언트로부터 수신된 바이트 수.
      
    • location_zone_requests : 클라이언트 요청의 총 수.
      
    • location_zone_responses : 클라이언트에게 전송된 응답의 총 수.
      
    • location_zone_responses_codes : 클라이언트에게 전송된 응답의 총 수.
      
    • location_zone_sent : 클라이언트에 전송된 바이트 수.
      
  • controller_transportserver_resources_total : 처리된 TransportServer 리소스의 수. 이 메트릭에는 TransportServer 리소스를 유형(패스스루, TCP 또는 UDP)별로 그룹화하는 레이블 유형이 포함됩니다.
    
  • 작업 대기열 메트릭.: 작업 대기열은 Ingress Controller가 클러스터의 관련 리소스(예: Ingress 리소스)에 대한 변경 사항을 처리하는 데 사용하는 대기열입니다. Ingress Controller는 대기열을 하나만 사용합니다. 해당 대기열의 메트릭에는 레이블이 있습니다. name="taskQueue"
    • workqueue_depth : 작업 대기열의 현재 깊이.
    • workqueue_queue_duration_second : 항목이 요청되기 전에 작업 대기열에 머무르는 시간(초)입니다.
    • workqueue_work_duration_seconds : 작업 대기열에서 항목을 처리하는 데 걸리는 시간(초)입니다.

참고 : 모든 메트릭에는 네임스페이스가 있습니다. (nginx_ingress) /
예시) nginx_ingress_controller_nginx_reloads_total.

참고 : 모든 메트릭에는 Ingress Controller의 클래스로 설정된 레이블이 포함됩니다 .
클래스는 -ingress-class cli 인수를 통해 구성됩니다.

4. Service Insight

Service Insight 기능은 F5 NGINX Plus에서만 사용할 수 있습니다. F5 NGINX Ingress Controller는 VirtualServer(VS) 및 TransportServer(TS) 리소스를 사용하여 노출된 서비스에 대한 호스트 통계를 제공하는 엔드포인트를 노출합니다.

JSON 형식으로 데이터를 제공하고 HTTP 상태 코드를 반환합니다.

응답 본문에는 구성된 호스트 이름과 연관된 총, 다운 및 비정상적 upstream pod 수에 대한 정보가 들어 있습니다. 반환된 HTTP 코드는 서비스의 상태를 나타냅니다.

NGINX Plus에서 모든 upstream(pod)이 비정상으로 판단되면 서비스는 정상이 아닌 것으로 표시됩니다(HTTP 응답 코드가 200 OK와 다름). NGINX Plus에서 판단한 대로 적어도 하나의 upstream pod가 정상이면 서비스는 정상입니다. 이 경우 엔드포인트는 HTTP 코드 200 OK를 반환합니다.

NGINX Plus의 건강 상태 결정은 고급 건강 검사를 사용하여 조정할 수 있으며, 포드 응답 및 반응성과 동적으로 연관시킬 수도 있습니다. Upstream Healthcheck upstream을 참조하세요.

4-1. Service Insight 엔드포인트 활성화

Kubernetes 매니페스트 (Deployment 또는 DaemonSet)를 사용하여 Ingress Controller를 설치하고 Service Insight 엔드포인트를 활성화하는 경우:

1. -enable-service-insight cli 인수 로 Ingress Controller를 실행합니다 .
   이렇게 하면 /probe/{hostname}가상 서버와 /probe/ts/{service_name}포트의 전송 서버에 대한 경로를 통해 Ingress Controller 엔드포인트가 노출됩니다 
   9114( -service-insight-listen-port cli 인수로 사용자 정의 가능).
   service_name 매개변수는 배포된 서비스( 전송 서버에서 upstream 아래에 지정된 서비스)의 이름을 참조합니다 .
2. Service Insight 엔드포인트에 TLS를 활성화하려면 -service-insight-tls-secretTLS 비밀의 네임스페이스와 이름으로 cli 인수를 구성합니다.
3. Ingress Controller Pod yaml에 Ingress Controller 컨테이너 포트 목록에 Service Insight 포트를 추가합니다.

- name: service-insight
  containerPort: 9114

4-2. 통계 및 HTTP 응답 코드

Service Insight는 다음과 같은 통계를 제공합니다.

• VS 또는 TS pods의 총 수
• ‘Up’ 상태의 VS 또는 TS pods 수
• ‘Unhealthy’ 상태의 VS 또는 TS pods 수

이러한 통계는 JSON으로 반환됩니다.

{ "Total": <int>, "Up": <int>, "Unhealthy": <int>  }

응답 코드:

• HTTP 200 OK – 서비스가 정상적입니다.
• HTTP 404 Not Found – 요청된 호스트 이름/이름에 대한 upstream/VS/TS를 찾을 수 없습니다.
• HTTP 418 I’m a teapot 서비스가 다운되었습니다(모든 upstream/VS/TS가 “비정상”입니다)

참고 : 호스트 이름의 와일드카드는 현재 지원되지 않습니다.

NGINX Ingress Controller의 더 많은 정보를 알고싶으시다면 NGINX STORE Blog를 방문해주세요.