CloudWatch 솔루션: Amazon EC2의 NGINX 워크로드 - Amazon CloudWatch
요구 사항이점비용이 솔루션에 대한 CloudWatch 에이전트 구성솔루션 에이전트 배포NGINX 솔루션 대시보드 생성

CloudWatch 솔루션: Amazon EC2의 NGINX 워크로드

이 솔루션을 사용하면 EC2 인스턴스에서 실행되는 NGINX 애플리케이션용 CloudWatch 에이전트를 사용하여 즉시 사용 가능한 지표 컬렉션을 구성할 수 있습니다. CloudWatch 관찰성 솔루션에서 모든 CloudWatch 관찰성 솔루션에 대한 일반 정보를 참조하세요.

요구 사항

이 솔루션 관련 조건은 다음과 같습니다.

이점

이 솔루션은 NGINX 모니터링을 제공함으로써 다음 사용 사례에 관한 유용한 인사이트를 제공합니다.

  • 연결 지표을 검토하여 잠재적 병목 현상, 연결 문제 또는 예상치 못한 사용량을 식별합니다.

  • HTTP 요청 볼륨을 분석하여 NGINX의 전체 트래픽 부하를 파악합니다.

솔루션의 가장 중요한 장점으로는 다음과 같은 것들이 있습니다.

  • CloudWatch 에이전트 구성을 사용하여 NGINX의 지표 수집을 자동화함으로써 수동 계측 소요를 없앱니다.

  • NGINX 지표에 대해 미리 구성된 통합 CloudWatch 대시보드를 제공합니다. 대시보드는 솔루션을 사용하여 구성된 새 NGINX EC2 인스턴스의 지표을 자동으로 처리하며, 이는 해당 대시보드를 처음 생성할 때 해당 지표이 존재하지 않더라도 마찬가지입니다.

다음 이미지는 해당 솔루션의 대시보드 예시입니다.

NGINX 솔루션에 대한 대시보드 예제입니다.

비용

이 솔루션은 사용자 계정에 리소스를 생성하여 사용합니다. 표준 사용에 대한 요금이 부과되며, 다음 항목들이 포함됩니다.

  • 이 솔루션에 대해 CloudWatch 에이전트가 수집한 모든 지표은 임베디드 지표 형식(EMF)을 사용하여 CloudWatch Logs에 게시됩니다. 이들 CloudWatch Logs는 분량 및 보존 기간에 따라 요금이 부과됩니다. 따라서 이 솔루션에 대한 PutMetricData API 호출에 대해서는 요금이 청구되지 않습니다. 로그에서 추출하고 수집한 지표은 사용자 지정 지표으로 요금이 부과됩니다. 이 솔루션에서 사용하는 지표 수는 EC2 호스트 수에 따라 달라집니다.

    • 솔루션에 구성된 각각의 NGINX EC2 호스트는 총 8개의 지표을 게시합니다.

  • 사용자 지정 단일 대시보드

CloudWatch 요금에 대한 자세한 내용은 Amazon CloudWatch 요금을 참조하세요.

요금 계산기는 이 솔루션 사용에 대한 대략적인 월별 비용을 추정하는 데 도움이 될 수 있습니다.

요금 계산기를 사용하여 솔루션 월별 비용을 추정하려면

  1. Amazon CloudWatch 요금 계산기를 엽니다.

  2. 리전 선택에서 솔루션을 배포할 AWS 리전을(를) 선택합니다.

  3. 지표 섹션의 지표 수에 8 * number of EC2 instances configured for this solution을(를) 입력합니다.

  4. 로그 섹션의 표준 로그: 수집한 데이터에 모든 EC2 호스트에서 CloudWatch 에이전트가 생성한 일일 로그 볼륨 예상값을 입력합니다. 예를 들어, EC2 인스턴스 5개는 하루에 1,000바이트 미만을 생성합니다. 설정한 후에는 CloudWatch Logs에서 변환한 IncomingBytes 지표을 사용하여 바이트 사용량을 확인할 수 있습니다. 적절한 로그 그룹을 선택해야 합니다.

  5. 로그 섹션의 로그 스토리지/보관(표준 및 변환 로그)에서 Yes to Store Logs: Assuming 1 month retention을(를) 선택합니다. 보존 기간에 사용자 지정 변경 값을 넣으려면 이 값을 수정합니다.

  6. 대시보드 및 경보 섹션의 대시보드 수에 1을(를) 입력합니다.

  7. 요금 계산기 하단에서 월별 예상 비용을 확인할 수 있습니다.

이 솔루션에 대한 CloudWatch 에이전트 구성

CloudWatch 에이전트는 서버와 컨테이너화된 환경에서 지속적이고 자율적으로 실행되는 소프트웨어입니다. 인프라와 애플리케이션에서 지표, 로그, 트레이스를 수집하여 CloudWatch와 X-Ray로 전송합니다.

CloudWatch에 대한 자세한 내용은 CloudWatch 에이전트를 사용하여 지표, 로그, 추적 수집을(를) 참조하세요.

이 솔루션의 에이전트 구성은 NGINX 워크로드 모니터링 및 관찰을 시작하는 데 도움이 되는 지표 세트를 수집합니다. CloudWatch 에이전트는 대시보드가 기본적으로 표시하는 것보다 더 많은 NGINX 지표을 수집하도록 구성할 수 있습니다. 수집할 수 있는 모든 NGINX 지표 목록은 NGINX OSS 지표을 참조하세요.

CloudWatch 에이전트를 구성하기 전에 먼저 지표을 노출하도록 NGINX를 구성해야 합니다. 두 번째로, 타사 Prometheus 지표 내보내기를 설치하여 구성해야 합니다.

NGINX 지표 노출

참고

다음은 Linux용 명령 예제입니다. Windows Server에서 NGINX for Windows 페이지와 동등한 명령을 확인합니다.

먼저 stub_status 모듈을 활성화해야 합니다. NGINX 구성 파일에 새 위치 블록을 추가합니다. nginx.conf의 server 블록에 다음 줄을 추가하여 NGINX의 stub_status 모듈을 활성화합니다.

location /nginx_status { 
          stub_status on;
          allow 127.0.0.1; # Allow only localhost to access
          deny all; # Deny all other IPs
        }

NGINX를 다시 로드하기 전에 NGINX 구성을 확인합니다.

sudo nginx -t

이 확인 명령은 웹 사이트를 중단시킬 수 있는 예상치 못한 오류를 방지하는 데 도움이 됩니다. 다음은 성공적인 응답의 예입니다.

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

업데이트된 구성을 성공적으로 확인했으면 NGINX를 다시 로드합니다(출력이 예상되지 않음).

sudo systemctl reload nginx

이 명령은 NGINX 프로세스에 구성을 다시 로드하도록 지시합니다. 재로드는 전체 재시작에 비해 더 안정적입니다. 다시 로드하면 새로운 구성으로 새 작업자 프로세스가 시작되어 이전 작업자 프로세스는 정상적으로 종료됩니다.

NGINX 상태 엔드포인트 테스트:

curl http://127.0.0.1/nginx_status

다음은 성공적인 응답의 예입니다.

Active connections: 1
server accepts handled requests
6 6 6
Reading: 0 Writing: 1 Waiting: 0

다음은 실패한 응답의 예입니다(계속하기 전에 이전 단계를 검토).

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
  <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
      <head>
          <title>The page is not found</title>
          ...

Prometheus 지표 내보내기 구성

공식 GitHub 리포지토리 에서 최신 NGINX Prometheus 내보내기 릴리스를 다운로드합니다. 플랫폼의 관련 바이너리를 다운로드해야 합니다.

다음 예제에서는 AMD64에 대한 명령을 보여줍니다.

cd /tmp
wget https://github.com/nginxinc/nginx-prometheus-exporter/releases/download/v1.3.0/nginx-prometheus-exporter_1.3.0_linux_amd64.tar.gz
tar -xzvf nginx-prometheus-exporter_1.3.0_linux_amd64.tar.gz
sudo cp nginx-prometheus-exporter /usr/local/bin/
rm /tmp/nginx-prometheus-exporter*

Prometheus 내보내기를 실행하고 NGINX 스텁 상태 페이지로 향합니다.

nohup /usr/local/bin/nginx-prometheus-exporter -nginx.scrape-uri http://127.0.0.1/nginx_status &>/dev/null &

다음 예제에서는 응답(배경 작업 ID 및 PID)을 보여줍니다.

[1] 74699

NGINX Prometheus 엔드포인트 테스트

NGINX Prometheus 내보내기가 관련 지표 노출을 시작했는지 확인합니다.

curl http://localhost:port-number/metrics

다음은 성공적인 응답의 예입니다.

# HELP go_gc_duration_seconds A summary of the pause duration of garbage collection cycles.
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 0
go_gc_duration_seconds{quantile="0.25"} 0
...
# HELP nginx_connections_accepted Accepted client connections
# TYPE nginx_connections_accepted counter
nginx_connections_accepted 14
# HELP nginx_connections_active Active client connections
# TYPE nginx_connections_active gauge
nginx_connections_active 1
...
# TYPE promhttp_metric_handler_requests_total counter
promhttp_metric_handler_requests_total{code="200"} 1
promhttp_metric_handler_requests_total{code="500"} 0
promhttp_metric_handler_requests_total{code="503"} 0

이 솔루션의 에이전트 구성

에이전트가 수집한 지표은 에이전트 구성에 정의되어 있습니다. 이 솔루션은 솔루션 대시보드에 적합한 차원에 권장 지표을 수집하는 에이전트 구성을 제공합니다.

솔루션 배포 단계는 뒷부분의 솔루션 에이전트 배포에 설명되어 있습니다. 다음 정보는 환경에 맞게 에이전트 구성을 사용자 지정하는 방법을 이해하는 데 도움이 됩니다.

Prometheus 내보내기에서 사용하는 포트 번호와 같이 환경에 맞게 에이전트 및 Prometheus 구성의 일부 부분을 사용자 지정해야 합니다.

Prometheus 내보내기에서 사용하는 포트는 다음 명령을 사용하여 확인할 수 있습니다.

sudo netstat -antp | grep nginx-prom

다음 예제에서는 응답을 보여줍니다(포트 값 9113 참조).

tcp6 0 0 :::9113 :::* LISTEN 76398/nginx-prometh

NGINX 호스트에 대한 에이전트 구성

Prometheus 모니터링이 포함된 CloudWatch 에이전트는 Prometheus 지표를 스크레이프하는 데 두 가지 구성이 필요합니다. 각각의 구성은 뒷부분의 2단계: Systems Manager Parameter Store에 권장 에이전트 구성 파일을 저장에 설명된 대로 SSM의 Parameter Store에 개별 파라미터로 저장됩니다.

첫 번째 구성은 Prometheus 설명서의 scrape_config에 설명된 Prometheus 내보내기를 위한 것입니다. 보안 암호는 CloudWatch 에이전트 구성을 위한 것입니다.

Prometheus 구성

포트 번호를 서버의 포트 번호로 바꾸세요.

global:
  scrape_interval: 30s
  scrape_timeout: 10s
  
scrape_configs:
- job_name: 'nginx'
  metrics_path: /metrics
  static_configs:
    - targets: ['localhost:port-number']
  ec2_sd_configs:
    - port: port-number
  relabel_configs:
    - source_labels: ['__meta_ec2_instance_id']
      target_label: InstanceId
  metric_relabel_configs:
    - source_labels: ['__name__']
      regex: 'nginx_up|nginx_http_requests_total|nginx_connections_.*'
      action: keep

CloudWatch 에이전트 구성

이전 CloudWatch 에이전트 구성에 따라 이러한 지표은 임베디드 지표 형식(EMF)을 사용하여 CloudWatch Logs를 통해 게시됩니다. 이러한 로그는 nginx 로그 그룹을 사용하도록 구성됩니다. CloudWatch 로그를 나타내는 다른 이름으로 log_group_name을 사용자 지정할 수 있습니다.

Windows Server를 사용하는 경우 다음 구성에서 prometheus_config_path를 C:\\ProgramData\\Amazon\\AmazonCloudWatchAgent\\prometheus.yaml(으)로 설정합니다.

{
"agent": {
  "metrics_collection_interval": 60
},
"logs": {
  "metrics_collected": {
      "prometheus": {
          "log_group_name": "nginx",
          "prometheus_config_path": "/opt/aws/amazon-cloudwatch-agent/etc/prometheus.yaml",
          "emf_processor": {
              "metric_declaration_dedup": true,
              "metric_namespace": "CWAgent",
              "metric_declaration":[
                  {
                      "source_labels":["InstanceId"],
                      "metric_selectors":["nginx_up", "nginx_http_requests_total", "nginx_connections*"],
                      "dimensions": [["InstanceId"]]
                  }
              ]
          }
      }
  }
}
}

솔루션 에이전트 배포

사용 사례에 따라 CloudWatch 에이전트를 설치하는 방법에는 여러 가지가 있습니다. 이 솔루션에는 Systems Manager를 사용하는 것이 좋습니다. Systems Manager는 콘솔 환경을 제공하며 단일 AWS 계정 내에 관리형 서버 플릿을 더 쉽게 관리할 수 있습니다. 이 섹션의 내용은 Systems Manager를 사용하며, 기존 구성으로 CloudWatch 에이전트를 실행하지 않는 경우에 적용할 수 있습니다. CloudWatch 에이전트가 실행 중인지 확인에 나열된 단계에 따라 CloudWatch 에이전트가 실행 중인지 확인할 수 있습니다.

워크로드가 배포된 EC2 호스트에서 이미 CloudWatch 에이전트를 실행 중이며 에이전트 구성을 관리 중이라면 이 섹션의 내용을 건너뛰어 기존 배포 메커니즘에 따라 구성을 업데이트할 수 있습니다. 새 CloudWatch 에이전트 및 Prometheus 구성을 기존 구성과 병합한 다음에 병합된 구성을 배포해야 합니다. Systems Manager를 사용하여 CloudWatch 에이전트의 구성을 저장하고 관리하는 경우, 해당 구성을 기존 파라미터 값에 병합할 수 있습니다. 자세한 내용은 CloudWatch 에이전트 구성 파일 관리를 참조하세요.

참고

Systems Manager를 사용하여 다음 CloudWatch 에이전트 구성을 배포하면 EC2 인스턴스의 기존 CloudWatch 에이전트 구성을 대체하거나 덮어씁니다. 이 구성은 고유한 환경 또는 사용 사례에 맞춰 수정할 수 있습니다. 구성에 정의된 지표은 솔루션을 제공하는 대시보드에 필요한 최소 항목입니다.

이 배포 프로세스는 다음 단계를 통해 이루어집니다.

  • 1단계: 대상 EC2 인스턴스에 필요한 IAM 권한이 있는지 확인합니다.

  • 2단계: Systems Manager Parameter Store에 권장 에이전트 구성 파일을 저장합니다.

  • 3단계: AWS CloudFormation 스택을 사용하여 하나 이상의 EC2 인스턴스에 CloudWatch 에이전트를 설치합니다.

  • 4단계: 에이전트 설정이 올바르게 구성되었는지 확인합니다.

1단계: 대상 EC2 인스턴스에 필요한 IAM 권한이 있는지 확인

Systems Manager가 CloudWatch 에이전트를 설치하고 구성할 수 있도록 권한을 부여해야 합니다. 또한, CloudWatch 에이전트가 EC2 인스턴스에서 CloudWatch로 원격 측정을 게시할 수 있는 권한을 부여해야 합니다. CloudWatch 에이전트 EC2 읽기 액세스 권한도 부여해야 합니다. EC2 InstanceId를 지표 차원으로 추가하려면 EC2 읽기 액세스가 필요합니다. 이 추가 요구 사항은 EC2 Service Discovery를 통해 __meta_ec2_instance_id을(를) 사용하므로 앞서 설명한 대로 prometheus.yaml에 의해 결정됩니다.

인스턴스에 연결된 IAM 역할에 CloudWatchAgentServerPolicy, AmazonSSMManagedInstanceCore 및 AmazonEC2ReadOnlyAccess IAM 정책이 연결되어 있는지 확인합니다.

2단계: Systems Manager Parameter Store에 권장 에이전트 구성 파일을 저장

Parameter Store는 구성 파라미터를 안전하게 저장하고 관리하여 EC2 인스턴스에 CloudWatch 에이전트 설치하는 작업을 간소화하므로 하드 코딩 값이 필요 없습니다. 이를 통해 보다 안전하고 유연한 배포 프로세스를 보장하며 중앙 집중식 관리를 가능하게 하는 동시에 다양한 인스턴스에서 구성을 더 쉽게 업데이트할 수 있습니다.

다음 단계에 따라 권장 CloudWatch 에이전트 구성 파일을 Parameter Store에 파라미터로 저장합니다.

CloudWatch 에이전트 구성 파일을 파라미터로 생성하려면

  1. AWS Systems Manager 콘솔(https://console.aws.amazon.com/systems-manager/)을 엽니다.

  2. 콘솔에서 선택한 리전이 NGINX가 실행 중인 리전인지 확인합니다.

  3. 탐색 창에서 애플리케이션 관리와 Parameter Store를 선택합니다.

  4. 다음 단계에 따라 새 구성 파라미터를 생성합니다.

    1. 파라미터 생성(Create parameter)을 선택합니다.

    2. 이름 상자에 이후 단계에서 CloudWatch 에이전트 구성 파일을 참조하는 데 사용할 이름을 입력합니다. 예를 들어 AmazonCloudWatch-NGINX-CloudWatchAgent-Configuration입니다.

    3. (선택 사항) Description 상자에 파라미터 설명을 입력합니다.

    4. 파라미터 계층에서 표준을 선택합니다.

    5. Type(유형)에서 문자열을 선택합니다.

    6. 데이터 유형에는 텍스트를 선택합니다.

    7. 값 상자에 NGINX 호스트에 대한 에이전트 구성에 목록으로 표시된 해당 JSON 블록을 붙여넣습니다. 필요에 따라 사용자 지정해야 합니다. 예를 들면, 관련 log_group_name입니다.

    8. 파라미터 생성(Create parameter)을 선택합니다.

Prometheus 구성 파일을 파라미터로 생성하려면

  1. AWS Systems Manager 콘솔(https://console.aws.amazon.com/systems-manager/)을 엽니다.

  2. 탐색 창에서 애플리케이션 관리와 Parameter Store를 선택합니다.

  3. 다음 단계에 따라 새 구성 파라미터를 생성합니다.

    1. 파라미터 생성(Create parameter)을 선택합니다.

    2. 이름 상자에 이후 단계에서 구성 파일을 참조하는 데 사용할 이름을 입력합니다. 예를 들어 AmazonCloudWatch-NGINX-Prometheus-Configuration입니다.

    3. (선택 사항) Description 상자에 파라미터 설명을 입력합니다.

    4. 파라미터 계층에서 표준을 선택합니다.

    5. Type(유형)에서 문자열을 선택합니다.

    6. 데이터 유형에는 텍스트를 선택합니다.

    7. 값 상자에 NGINX 호스트에 대한 에이전트 구성에 목록으로 표시된 해당 YAML 블록을 붙여넣습니다. 필요에 따라 사용자 지정해야 합니다. 예를 들면, targets에 따른 관련 포트 번호입니다.

    8. 파라미터 생성(Create parameter)을 선택합니다.

3단계: CloudWatch 에이전트를 설치하고 AWS CloudFormation 템플릿을 사용하여 구성을 적용

AWS CloudFormation을(를) 사용하여 에이전트를 설치하고 이를 이전 단계에서 생성한 CloudWatch 에이전트 구성을 사용하도록 구성할 수 있습니다.

이 솔루션의 CloudWatch 에이전트를 설치하고 구성하려면

  1. https://console.aws.amazon.com/cloudformation/home?#/stacks/quickcreate?templateURL=https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/CloudWatchAgent/CFN/v1.0.0/cw-agent-installation-template-with-prometheus-config-1.0.0.json 링크를 사용하여 AWS CloudFormation 빠른 스택 생성 마법사를 엽니다.

  2. 콘솔에서 선택한 리전이 NGINX 워크로드가 실행 중인 리전인지 확인합니다.

  3. 스택 이름에 스택의 이름을 CWAgentInstallationStack 등과 같이 입력합니다.

  4. 파라미터 섹션에는 다음과 같이 지정합니다.

    1. CloudWatchAgentConfigSSM에는 이전에 생성한 에이전트 구성의 AWS Systems Manager 파라미터 이름을 AmazonCloudWatch-NGINX-CloudWatchAgent-Configuration 등과 같이 입력합니다.

    2. PrometheusConfigSSM에는 이전에 생성한 에이전트 구성의 AWS Systems Manager 파라미터 이름을 AmazonCloudWatch-NGINX-Prometheus-Configuration 등과 같이 입력합니다.

    3. 대상 인스턴스를 선택할 때 사용할 수 있는 두 가지 옵션이 있습니다.

      1. InstanceIds에는 이 구성으로 CloudWatch 에이전트를 설치하려는 인스턴스 ID에서 쉼표로 구분된 인스턴스 ID 목록을 지정합니다. 단일 인스턴스나 여러 인스턴스를 목록 지정할 수 있습니다.

      2. 대규모 배포 시에는 TagKey와 해당 TagValue를 지정하여 해당 태그와 값을 사용하는 모든 EC2 인스턴스를 대상으로 지정할 수 있습니다. TagKey를 지정하는 경우 관련된 TagValue를 지정해야 합니다. (Auto Scaling 그룹에서는 TagKey를 aws:autoscaling:groupName처럼 지정하고 Auto Scaling 그룹 내의 모든 인스턴스에 배포할 TagValue의 Auto Scaling 그룹 이름을 지정합니다.)

  5. 설정을 검토한 다음 스택 생성을 선택합니다.

템플릿 파일을 먼저 편집하여 사용자 지정하려면 스택 생성 마법사에서 템플릿 파일 업로드 옵션을 선택하여 편집된 템플릿을 업로드합니다. 자세한 내용은 AWS CloudFormation 콘솔에서 스택 생성 단원을 참조하세요. https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/CloudWatchAgent/CFN/v1.0.0/cw-agent-installation-template-with-prometheus-config-1.0.0.json 링크를 사용하여 템플릿을 다운로드할 수 있습니다.

참고

이 단계가 완료되면 이 Systems Manager 파라미터는 대상 인스턴스에서 실행되는 CloudWatch 에이전트와 연결됩니다. 이는 다음을 의미합니다.

  1. Systems Manager 파라미터가 삭제되면 에이전트가 중지됩니다.

  2. Systems Manager 파라미터를 편집하면 기본값인 30일로 예약된 빈도로 에이전트에 구성 변경 사항이 자동으로 적용됩니다.

  3. 이 Systems Manager 파라미터에 변경 사항을 즉시 적용하려면 이 단계를 다시 실행해야 합니다. 자세한 내용은 Systems Manager에서 연결 작업을 참조하세요.

4단계: 에이전트 설정이 올바르게 구성되었는지 확인

CloudWatch 에이전트가 실행 중인지 확인에 나열된 단계에 따라 CloudWatch 에이전트가 설치되었는지 확인할 수 있습니다. CloudWatch 에이전트가 설치되어 실행되지 않는 경우 모든 항목을 올바르게 설정했는지 확인합니다.

모든 것이 올바르게 설정된 경우 CloudWatch에 게시되는 NGINX 지표이 표시됩니다. CloudWatch 콘솔을 확인하여 게시되고 있는지 확인할 수 있습니다.

NGINX 지표이 CloudWatch에 게시되고 있는지 확인하려면

  1. https://console.aws.amazon.com/cloudwatch/에서 CloudWatch 콘솔을 엽니다.

  2. 지표, 전체 지표을 선택합니다.

  3. 솔루션을 배포한 리전을 선택하고 사용자 지정 네임스페이스, CWAgent를 선택합니다.

  4. nginx_http_requests_total 등과 같은 지표을 검색합니다. 해당 지표에 대한 결과가 표시되면 지표은 CloudWatch에 게시 중입니다.

NGINX 솔루션 대시보드 생성

이 솔루션에서 제공하는 대시보드는 모든 인스턴스에서 지표을 집계하고 제시하여 NGINX 워크로드 지표을 제공합니다. 대시보드에는 지표별 상위 기여자(지표 위젯당 상위 10개)의 세부 정보가 표시됩니다. 이를 통해 관찰된 지표에 크게 기여하는 인스턴스나 이상치를 빠르게 식별할 수 있습니다.

대시보드를 생성하기 위해 사용할 수 있는 옵션은 다음과 같습니다.

  • CloudWatch 콘솔을 사용하여 대시보드를 생성합니다.

  • AWS CloudFormation 콘솔을 사용하여 대시보드를 배포합니다.

  • AWS CloudFormation 인프라를 코드로 다운로드하여 지속적 통합(CI) 자동화에 통합합니다.

CloudWatch 콘솔을 사용하여 대시보드를 생성하면 실제 생성 및 청구 전에 대시보드를 미리 볼 수 있습니다.

참고

이 솔루션에서 AWS CloudFormation(으)로 생성된 대시보드에는 솔루션이 배포된 리전의 지표이 표시됩니다. NGINX 지표이 게시되는 리전에서 AWS CloudFormation 스택을 생성해야 합니다.

사용자 지정 네임스페이스를 CloudWatch 에이전트 구성의 CWAgent 이외의 네임스페이스로 지정하는 경우 대시보드의 CloudFormation 템플릿을 변경하여 사용 중인 사용자 지정 네임스페이스로 CWAgent를 바꿔야 합니다.

CloudWatch 콘솔을 통해 대시보드를 생성하려면

  1. https://console.aws.amazon.com/cloudwatch/home?#dashboards?dashboardTemplate=NginxOnEc2&referrer=os-catalog 링크를 사용하여 CloudWatch 클라우드의 대시보드 생성을 엽니다.

  2. 콘솔에서 선택한 리전이 NGINX 워크로드가 실행 중인 리전인지 확인합니다.

  3. 대시보드의 이름을 입력하고 대시보드 생성을 선택합니다.

    이 대시보드를 다른 리전의 비슷한 대시보드와 쉽게 구분하려면 NGINXDashboard-us-east-1처럼 대시보드 이름에 리전 이름을 포함하는 것이 좋습니다.

  4. 대시보드를 미리 보고 저장을 선택하여 대시보드를 생성합니다.

AWS CloudFormation을(를) 통해 대시보드를 생성하려면

  1. https://console.aws.amazon.com/cloudformation/home?#/stacks/quickcreate?templateURL=https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/NGINX_EC2/CloudWatch/CFN/v1.0.0/dashboard-template-1.0.0.json 링크를 사용하여 AWS CloudFormation 빠른 스택 생성 마법사를 엽니다.

  2. 콘솔에서 선택한 리전이 NGINX 워크로드가 실행 중인 리전인지 확인합니다.

  3. 스택 이름에 스택의 이름을 NGINXDashboardStack 등과 같이 입력합니다.

  4. 파라미터 섹션에서 DashboardName 파라미터 아래에 대시보드 이름을 지정합니다.

  5. 이 대시보드를 다른 리전의 비슷한 대시보드와 쉽게 구분하려면 NGINXDashboard-us-east-1처럼 대시보드 이름에 리전 이름을 포함하는 것이 좋습니다.

  6. 기능 및 변환에서 변환에 대한 액세스 기능을 확인합니다. CloudFormation은 IAM 리소스를 추가하지 않습니다.

  7. 설정을 검토한 다음 스택 생성을 선택합니다.

  8. 스택 상태가 CREATE_COMPLETE가 되면, 생성된 스택에서 리소스 탭을 선택한 다음 물리적 ID의 링크를 선택하여 대시보드로 이동합니다. 콘솔의 왼쪽 탐색 창에서 대시보드를 선택하고 사용자 지정 대시보드에서 대시보드 이름을 찾아 CloudWatch 콘솔의 대시보드에 액세스할 수도 있습니다.

템플릿 파일을 먼저 편집하여 사용자 지정하려면 스택 생성 마법사에서 템플릿 파일 업로드 옵션을 선택하여 편집된 템플릿을 업로드합니다. 자세한 내용은 AWS CloudFormation 콘솔에서 스택 생성 단원을 참조하세요. https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/NGINX_EC2/CloudWatch/CFN/v1.0.0/dashboard-template-1.0.0.json 링크를 사용하여 템플릿을 다운로드할 수 있습니다.

NGINX 대시보드 시작하기

새 NGINX 대시보드로 시도해 볼 수 있는 작업들 가운데는 다음과 같은 것이 있습니다. 이들 작업을 통해 대시보드가 올바르게 작동하는지 확인하고 이를 사용하여 NGINX 워크로드 모니터링과 관련된 몇 가지 실습 경험을 제공할 수 있습니다. 이들 작업을 직접 실행해 보면 대시보드 탐색 및 시각화된 지표 해석에 익숙해질 수 있습니다.

연결 지표 검토

연결 섹션에서는 NGINX 서버의 클라이언트 연결 처리에 인사이트를 제공하는 몇 가지 주요 지표을 찾을 수 있습니다. 이러한 연결 지표을 모니터링하면 잠재적인 병목 현상, 연결 문제 또는 예상치 못한 연결 패턴을 식별하는 데 도움이 될 수 있습니다.

  • 승인된 클라이언트 연결

  • 활성 클라이언트 연결

  • 처리된 클라이언트 연결

  • 연결 읽기 요청

  • 유휴 클라이언트 연결

  • 응답 작성 연결

HTTP 요청 볼륨 분석

HTTP 요청 섹션의 request 지표은 NGINX 서버에서 처리한 총 HTTP 요청 수를 보여줍니다. 시간 경과에 따라 이 지표을 추적하면 NGINX 인프라의 전체 트래픽 부하를 파악하고 그에 따라 리소스 할당 및 규모 조정을 계획하는 데 도움이 될 수 있습니다.