기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # 모니터링 AWS ParallelCluster 및 로그 모니터링은 AWS ParallelCluster 및 다른 AWS 솔루션의 신뢰성, 가용성 및 성능을 유지하는 데 중요한 부분입니다.는 다음과 같은 모니터링 도구를 AWS 제공하여 모니터링 AWS ParallelCluster, 보고 및 문제 발생 시 적절한 경우 자동 조치를 취합니다. + *Amazon CloudWatch*는 AWS 리소스와 AWS 에서 실행하는 애플리케이션을 실시간으로 모니터링합니다. 지표를 수집 및 추적하고, 사용자 지정 대시보드를 생성할 수 있으며, 지정된 지표가 지정한 임곗값에 도달하면 사용자에게 알리거나 조치를 취하도록 경보를 설정할 수 있습니다. 예를 들어 CloudWatch에서 Amazon EC2 인스턴스의 CPU 사용량 또는 기타 지표를 추적하고 필요할 때 자동으로 새 인스턴스를 시작할 수 있습니다. 자세한 내용은 [CloudWatch 사용 설명서](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/)를 참조하세요. + *Amazon CloudWatch Logs*로 Amazon EC2 인스턴스, CloudTrail, 기타 소스의 로그 파일을 모니터링, 저장 및 액세스할 수 있습니다. CloudWatch Logs는 로그 파일의 정보를 모니터링하고 특정 임곗값에 도달하면 사용자에게 알릴 수 있습니다. 또한 매우 내구력 있는 스토리지에 로그 데이터를 저장할 수 있습니다. 자세한 내용은 [Amazon CloudWatch Logs 사용 설명서](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/)를 참조하십시오. + *AWS CloudTrail*은 직접 수행하거나 AWS 계정 를 대신하여 수행한 API 호출 및 관련 이벤트를 캡처하고 지정한 Amazon S3 버킷에 로그 파일을 전송합니다. 어떤 사용자 및 계정이 AWS를 호출했는지 어떤 소스 IP 주소에 호출이 이루어졌는지 언제 호출이 발생했는지 확인할 수 있습니다. 자세한 내용은 [AWS CloudTrail 사용 설명서](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/)를 참조하십시오. + *EventBridge*: 애플리케이션을 다양한 소스의 데이터와 쉽게 연결할 수 있는 서버리스 이벤트 버스 서비스입니다. EventBridge는 자체 애플리케이션, Software-as-a-Service(SaaS) 애플리케이션 및 AWS 서비스의 실시간 데이터 스트림을 제공하고 해당 데이터를 Lambda와 같은 대상으로 라우팅합니다. 이를 통해 서비스에서 발생하는 이벤트를 모니터링하고 이벤트 기반 아키텍처를 구축할 수 있습니다. 자세한 내용은 [Amazon EventBridge 사용 설명서](https://docs.aws.amazon.com/eventbridge/latest/userguide/)를 참조하세요. **Topics** + [Amazon CloudWatch Logs와 통합](cloudwatch-logs-v3.md) + [Amazon CloudWatch 대시보드](cloudwatch-dashboard-v3.md) + [클러스터 지표에 대한 Amazon CloudWatch 경보](cloudwatch-alarms-v3.md) + [AWS ParallelCluster 구성된 로그 교체](log-rotation-v3.md) + [`pcluster` CLI 로그](troubleshooting-v3-pc-cli-logs.md) + [Amazon EC2 콘솔 출력 로그](console-logs-v3.md) + [PCUI 및 AWS ParallelCluster 런타임 로그 검색](troubleshooting-v3-get-runtime-logs.md) + [로그 검색 및 보존](troubleshooting-v3-get-logs.md) # Amazon CloudWatch Logs와 통합 CloudWatch Logs에 대한 자세한 내용은 [Amazon CloudWatch Logs 사용 설명서](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/)를 참조하세요. CloudWatch Logs 통합을 구성하려면 [`Monitoring`](Monitoring-v3.md) 섹션을 참조하세요. `append-config`를 사용하여 CloudWatch 구성에 사용자 지정 로그를 추가하는 방법을 알아보려면 Amazon CloudWatch 사용 설명서**의 [다중 CloudWatch 에이전트 구성 파일](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-common-scenarios.html#CloudWatch-Agent-multiple-config-files)을 참조하세요. ## Amazon CloudWatch Logs 클러스터 로그 이름이 `/aws/parallelcluster/cluster-name-`인 각 클러스터에 대해 로그 그룹이 생성됩니다(예: `/aws/parallelcluster/testCluster-202202050215`). 각 노드의 각 로그(또는 경로에 `*`가 포함된 경우 로그 집합)에는 `{hostname}.{instance_id}.{logIdentifier}`라는 로그 스트림이 있습니다. (예: `ip-172-31-10-46.i-02587cf29cc3048f3.nodewatcher`.) 로그 데이터는 모든 클러스터 인스턴스에서 `root`로 실행되는 [CloudWatch 에이전트](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)에 의해 CloudWatch로 전송됩니다. Amazon CloudWatch 대시보드는 클러스터가 생성될 때 생성됩니다. 이 대시보드를 사용하면 CloudWatch Logs에 저장된 로그를 검토할 수 있습니다. 자세한 내용은 [Amazon CloudWatch 대시보드](cloudwatch-dashboard-v3.md) 항목을 참조하세요. 이 목록에는 플랫폼, 스케줄러 및 노드에 사용할 수 있는 로그 스트림의 *logIdentifier* 및 경로가 포함되어 있습니다. **플랫폼, 스케줄러 및 노드에 사용할 수 있는 로그 스트림** | 플랫폼 | 스케줄러 | 노드 | 로그 스트림 | | --- | --- | --- | --- | | amazon redhat ubuntu | awsbatch slurm | HeadNode | dcv-authenticator: `/var/log/parallelcluster/pcluster_dcv_authenticator.log` dcv-ext-authenticator: `/var/log/parallelcluster/pcluster_dcv_connect.log` dcv-agent: `/var/log/dcv/agent.*.log` dcv-xsession: `/var/log/dcv/dcv-xsession.*.log` dcv-server: `/var/log/dcv/server.log` dcv-session-launcher: `/var/log/dcv/sessionlauncher.log` Xdcv: `/var/log/dcv/Xdcv.*.log` cfn-init: `/var/log/cfn-init.log` chef-client: `/var/log/chef-client.log` | | amazon redhat ubuntu | awsbatch slurm | ComputeFleet HeadNode | cloud-init: `/var/log/cloud-init.log` supervisord: `/var/log/supervisord.log` | | amazon redhat ubuntu | slurm | ComputeFleet | cloud-init-output: `/var/log/cloud-init-output.log` computemgtd: `/var/log/parallelcluster/computemgtd` slurmd: `/var/log/slurmd.log` slurm\$1prolog\$1epilog: `/var/log/parallelcluster/slurm_prolog_epilog.log` | | amazon redhat ubuntu | slurm | HeadNode | sssd: `/var/log/sssd/sssd.log` sssd\$1domain\$1default: `/var/log/sssd/sssd_default.log` pam\$1ssh\$1key\$1generator: `/var/log/parallelcluster/pam_ssh_key_generator.log` clusterstatusmgtd: `/var/log/parallelcluster/clusterstatusmgtd` clustermgtd: `/var/log/parallelcluster/clustermgtd` compute\$1console\$1output: `/var/log/parallelcluster/compute_console_output` slurm\$1resume: `/var/log/parallelcluster/slurm_resume.log` slurm\$1suspend: `/var/log/parallelcluster/slurm_suspend.log` slurmctld: `/var/log/slurmctld.log` slurm\$1fleet\$1status\$1manager: `/var/log/parallelcluster/slurm_fleet_status_manager.log` | | amazon redhat | awsbatch slurm | ComputeFleet HeadNode | system-messages: `/var/log/messages` | | ubuntu | awsbatch slurm | ComputeFleet HeadNode | syslog: `/var/log/syslog` | 를 사용하는 클러스터의 작업은 상태에 도달한 작업의 출력을 CloudWatch Logs`RUNNING``SUCCEEDED``FAILED`에 AWS Batch 저장합니다. 로그 그룹은 `/aws/batch/job`이며 로그 스트림 이름 형식은 `jobDefinitionName/default/ecs_task_id`입니다. 기본적으로 이러한 로그들은 만료되도록 설정하지 않지만 유지 기간을 수정할 수 있습니다. 자세한 내용은 Amazon CloudWatch Logs User Guide**의 [CloudWatch에서 로그 데이터 보존 기간을 변경](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SettingLogRetention.html)을 참조하세요. ## Amazon CloudWatch Logs 빌드 이미지 로그 각 사용자 지정 빌드 이미지에 대해 이름이 `/aws/imagebuilder/ParallelClusterImage-`인 로그 그룹이 생성됩니다. 이름이 *\$1pcluster-version\$1*/1인 고유한 로그 스트림에는 빌드 이미지 프로세스의 출력이 포함됩니다. [`pcluster`](pcluster-v3.md) 이미지 명령을 사용하여 로그에 액세스할 수 있습니다. 자세한 내용은 [AWS ParallelCluster AMI 사용자 지정](custom-ami-v3.md) 항목을 참조하세요. # Amazon CloudWatch 대시보드 Amazon CloudWatch 대시보드는 클러스터가 생성될 때 생성됩니다. 이렇게 하면 클러스터의 노드를 더 쉽게 모니터링하고 Amazon CloudWatch Logs에 저장된 로그를 볼 수 있습니다. 대시보드의 이름은 `ClusterName-Region`입니다. *ClusterName*은 클러스터의 이름이고 *Region*은 클러스터가 속해 AWS 리전 입니다. 콘솔에서 또는 `https://console.aws.amazon.com/cloudwatch/home?region=Region#dashboards:name=ClusterName-Region`를 열어서 대시보드에 액세스할 수 있습니다. 다음 이미지는 클러스터에 대한 CloudWatch 대시보드의 예를 보여 줍니다. ![\[Dashboard graphs of the status of cluster resources.\]](http://docs.aws.amazon.com/ko_kr/parallelcluster/latest/ug/images/CW-dashboard.png) 헤드 노드 인스턴스 지표**** 대시보드의 첫 번째 섹션에는 헤드 노드 Amazon EC2 지표의 그래프가 표시됩니다. 클러스터에 공유 스토리지가 있는 경우 다음 섹션에는 공유 스토리지 지표가 표시됩니다. 클러스터 상태 지표**** 클러스터가 스케줄링에 Slurm을 사용하는 경우 클러스터 상태 지표 그래프에 실시간 클러스터 컴퓨팅 노드 오류가 표시됩니다. 자세한 내용은 [클러스터 상태 지표 문제 해결](troubleshooting-v3-cluster-health-metrics.md) 단원을 참조하십시오. 클러스터 상태 지표는 AWS ParallelCluster 버전 3.6.0부터 대시보드에 추가됩니다. 헤드 노드 로그**** 마지막 섹션에는 AWS ParallelCluster로그, 스케줄러 로그, Amazon DCV 통합 로그 및 시스템 로그별로 그룹화된 헤드 노드 로그가 나열됩니다. Amazon CloudWatch 대시보드에 대한 자세한 내용은 Amazon CloudWatch 사용 설명서**의 [Amazon CloudWatch 대시보드 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)을 참조하세요. Amazon CloudWatch 대시보드를 생성하지 않으려는 경우 [`Monitoring`](Monitoring-v3.md)/[`Dashboards`](Monitoring-v3.md#yaml-Monitoring-Dashboards)/[`CloudWatch`](Monitoring-v3.md#yaml-Monitoring-Dashboard-CloudWatch)/[`Enabled`](Monitoring-v3.md#yaml-Monitoring-Dashboard-CloudWatch-Enabled)를 `false`로 설정하여 대시보드를 비활성화할 수 있습니다. **참고** Amazon CloudWatch 대시보드 생성을 비활성화하면 클러스터에 대한 Amazon CloudWatch `disk_used_percent` 및 `memory_used_percent` 경보도 비활성화됩니다. 자세한 내용은 [클러스터 지표에 대한 Amazon CloudWatch 경보](cloudwatch-alarms-v3.md) 단원을 참조하십시오. `disk_used_percent` 및 `memory_used_percent` 경보는 AWS ParallelCluster 버전 3.6부터 추가됩니다. # 클러스터 지표에 대한 Amazon CloudWatch 경보 AWS ParallelCluster 는 헤드 노드의 상태 및 리소스 사용률을 모니터링하도록 Amazon CloudWatch 경보를 구성합니다. 경보의 이름은 이며`cluster-name-HeadNode-metric`, 여기서 *cluster-name*은 클러스터의 이름이고 *지표*는 모니터링 중인 지표를 식별합니다. 탐색 창에서 **경보**를 선택하여 CloudWatch 콘솔에서 경보에 액세스합니다. 라는 복합 경보는 개별 헤드 노드 경보가 트리거될 때 `ALARM` 상태로 `cluster-name-HeadNode` 전환됩니다. ## 디스크 및 메모리 경보 AWS ParallelCluster 버전 3.6.0부터 다음과 같은 CloudWatch 경보가 생성됩니다. + `cluster-name-HeadNode-Disk` - 루트 볼륨 `disk_used_percent` 지표를 모니터링합니다. 1분 동안 1개의 데이터 포인트에 대한 디스크 사용량이 90%를 초과하는 경우 `ALARM` 상태로 전환됩니다. + `cluster-name-HeadNode-Mem` - `mem_used_percent` 지표를 모니터링합니다. 1분 동안 1개의 데이터 포인트에 대한 메모리 사용량이 90%보다 클 때 `ALARM` 상태를 입력합니다. 자세한 설명은 [Amazon CloudWatch 사용자 가이드](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/metrics-collected-by-CloudWatch-agent.html)의 *CloudWatch 에이전트가 수집하는 지표*를 참조하세요. ## 상태 확인 및 CPU 경보 AWS ParallelCluster 버전 3.8.0부터 다음과 같은 CloudWatch 경보가 생성됩니다. + `cluster-name-HeadNode-Health` - Amazon EC2 `StatusCheckFailed` 지표를 모니터링합니다. 1분 내에 1개의 데이터 포인트에 대해 값이 0보다 클 때 `ALARM` 상태를 입력합니다. + `cluster-name-HeadNode-Cpu` - Amazon EC2 `CPUUtilization` 지표를 모니터링합니다. 1분 동안 1개의 데이터 포인트에 대한 CPU 사용률이 90%보다 클 때 `ALARM` 상태가 됩니다. ## 클러스터 관리 데몬 하트비트 경보 AWS ParallelCluster 버전 3.15.0부터 Amazon CloudWatch 로깅이 활성화되고 Slurm 스케줄러가 사용되는 경우 다음 경보가 생성됩니다. + `cluster-name-HeadNode-ClustermgtdHeartbeat` - `ParallelCluster` 네임스페이스의 `ClustermgtdHeartbeat` 지표를 모니터링합니다. 1분 동안 10개의 연속 데이터 포인트에 대해 1개 미만의 하트비트가 수신되면 경보가 `ALARM` 상태로 전환됩니다. 누락된 데이터는 위반으로 처리됩니다. **참고** 모든 경보는 대칭적으로 복구됩니다. 경보를 트리거하는 동일한 데이터 포인트 및 평가 기간도 복구를 관리합니다. 예를 들어, 1개의 데이터 포인트가 있는 경보는 동일한 관찰 기간 내에 1개의 좋은 데이터 포인트 후에 복구됩니다. 마찬가지로 `ClustermgtdHeartbeat` 경보를 사용하려면 10개의 좋은 데이터 포인트(10분)가 연속으로 필요합니다`OK`. **참고** AWS ParallelCluster 는 경보 작업을 구성하지 않습니다. 경보 전송과 같은 경보 작업을 설정하는 방법에 대한 자세한 내용은 [경보 작업](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions)을 참조하세요. Amazon CloudWatch 경보에 대한 자세한 내용은 Amazon CloudWatch 사용 설명서**의 [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)을 참조하세요. AWS ParallelCluster 버전 3.8.0 이상의 경우 클러스터 구성`false`에서 [`Monitoring`](Monitoring-v3.md) / /를 [`Alarms`](Monitoring-v3.md#yaml-Monitoring-Alarms) [`Enabled`](Monitoring-v3.md#yaml-Monitoring-Alarms-Enabled)로 설정하여 경보를 비활성화합니다. 3.8.0 이전 AWS ParallelCluster 버전의 경우 클러스터 구성`false`에서 [`Monitoring`](Monitoring-v3.md) / / [`Dashboards`](Monitoring-v3.md#yaml-Monitoring-Dashboards) /를 [`CloudWatch`](Monitoring-v3.md#yaml-Monitoring-Dashboard-CloudWatch) [`Enabled`](Monitoring-v3.md#yaml-Monitoring-Dashboard-CloudWatch-Enabled)로 설정하여 경보를 비활성화합니다. 이 설정은 Amazon CloudWatch 대시보드도 비활성화합니다. 자세한 내용은 섹션을 참조[Amazon CloudWatch 대시보드](cloudwatch-dashboard-v3.md)하세요. # AWS ParallelCluster 구성된 로그 교체 AWS ParallelCluster 로그 교체 구성은 `/etc/logrotate.d/parallelcluster_*_log_rotation` 파일에 있습니다. 구성된 로그가 교체되면 현재 로그 내용은 단일 백업에 보존되고 비워진 로그는 로깅을 재개합니다. 구성된 각 로그에 대해 백업은 1개만 유지됩니다. AWS ParallelCluster 는 크기가 50MB에 도달하면 빠르게 증가하는 로그를 회전하도록 구성합니다. 빠르게 증가하는 로그는 `/var/log/parallelcluster/clustermgtd`, `/var/log/parallelcluster/slurm_resume.log`, `/var/log/slurmctld.log`를 포함하여 크기 조정 및 Slurm과 관련이 있습니다. AWS ParallelCluster 는 크기가 10MB에 도달하면 느리게 증가하는 로그를 회전하도록 구성합니다. CloudFormation 로깅이 활성화된 상태에서 클러스터 구성 [`Logs`](Monitoring-v3.md#yaml-Monitoring-Logs)/[`CloudWatch`](Monitoring-v3.md#yaml-Monitoring-Logs-CloudWatch)/[`RetentionInDays`](Monitoring-v3.md#yaml-Monitoring-Logs-CloudWatch-RetentionInDays) 설정에 정의된 일수 동안 보존된 이전 로그를 볼 수 있습니다. `RetentionInDays` 설정에서 사용 사례에 따라 일수를 늘려야 하는지 확인하세요. AWS ParallelCluster 는 다음 로그를 구성하고 교체합니다. **헤드 노드 로그** ``` /var/log/cloud-init.log /var/log/supervisord.log /var/log/cfn-init.log /var/log/chef-client.log /var/log/dcv/server.log /var/log/dcv/sessionlauncher.log /var/log/dcv/agent.*.log /var/log/dcv/dcv-xsession.*.log /var/log/dcv/Xdcv.*.log /var/log/parallelcluster/pam_ssh_key_generator.log /var/log/parallelcluster/clustermgtd /var/log/parallelcluster/clusterstatusmgtd /var/log/parallelcluster/slurm_fleet_status_manager.log /var/log/parallelcluster/slurm_resume.log /var/log/parallelcluster/slurm_suspend.log /var/log/slurmctld.log /var/log/slurmdbd.log /var/log/parallelcluster/compute_console_output.log ``` **컴퓨팅 노드 로그** ``` /var/log/cloud-init.log /var/log/supervisord.log /var/log/cloud-init-output.log /var/log/parallelcluster/computemgtd /var/log/slurmd.log ``` **로그인 노드 로그** ``` /var/log/cloud-init.log /var/log/cloud-init.log /var/log/cloud-init-output.log /var/log/supervisord.log /var/log/parallelcluster/pam_ssh_key_generator.log ``` # `pcluster` CLI 로그 `pcluster` CLI는 명령 로그를 `/home/user/.parallelcluster/` 내의 `pcluster.log.#` 파일에 기록합니다. 각 명령에 대한 로그에는 일반적으로 입력이 포함된 명령, 명령을 만드는 데 사용된 CLI API 버전 사본, 응답, 정보 및 오류 메시지가 포함됩니다. 생성 및 빌드 명령의 경우 로그에는 구성 파일, 구성 파일 검증 작업, CloudFormation 템플릿 및 스택 명령도 포함됩니다. 이러한 로그를 사용하여 오류, 입력, 버전 및 `pcluster` CLI 명령을 확인할 수 있습니다. 또한 명령이 언제 실행되었는지에 대한 기록으로도 사용할 수 있습니다. # Amazon EC2 콘솔 출력 로그 가 정적 컴퓨팅 노드 인스턴스가 예기치 않게 종료되는 것을 AWS ParallelCluster 감지하면 일정 시간이 경과한 후 종료된 노드 인스턴스에서 Amazon EC2 콘솔 출력을 검색하려고 시도합니다. 이렇게 하면 컴퓨팅 노드가 Amazon CloudWatch와 통신할 수 없는 경우에도 노드가 종료된 원인에 대한 유용한 문제 해결 정보를 콘솔 출력에서 계속 검색할 수 있습니다. 이 콘솔 출력은 헤드 노드의 `/var/log/parallelcluster/compute_console_output` 로그에 기록됩니다. Amazon EC2 콘솔 출력에 대한 자세한 내용은 *Linux 인스턴스용 Amazon EC2 사용 설명서*의 [인스턴스 콘솔 출력](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-console.html#instance-console-console-output)을 참조하세요. 기본적으로는 종료된 노드의 샘플 하위 집합에서만 콘솔 출력을 AWS ParallelCluster 검색합니다. 이렇게 하면 잦은 종료로 다수의 콘솔 출력 요청이 발생해 클러스터 헤드 노드가 과부하되는 것을 방지할 수 있습니다. 기본적으로는 종료 감지와 콘솔 출력 검색 사이에 5분을 AWS ParallelCluster 기다려 Amazon EC2에 노드에서 최종 콘솔 출력을 검색할 시간을 부여합니다. 헤드 노드의 `/etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf` 파일에서 샘플 크기 및 대기 시간 파라미터 값을 편집할 수 있습니다. 이 기능은 AWS ParallelCluster 버전 3.5.0에 추가되었습니다. ## Amazon EC2 콘솔 출력 파라미터 다음 Amazon EC2 콘솔 출력 파라미터의 값을 헤드 노드의 `/etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf` 파일에서 편집할 수 있습니다. ### `compute_console_logging_enabled` 콘솔 출력 로그 수집을 비활성화하려면 `compute_console_logging_enabled`를 `false`로 설정합니다. 기본값은 `true`입니다. 컴퓨팅 플릿을 중지하지 않고 언제라도 이 파라미터를 업데이트할 수 있습니다. ### `compute_console_logging_max_sample_size` `compute_console_logging_max_sample_size`는 예기치 않은 종료를 감지할 때마다가 콘솔 출력을 AWS ParallelCluster 수집하는 최대 컴퓨팅 노드 수를 설정합니다. 이 값이 보다 작으면 종료된 모든 노드에서 콘솔 출력을 `1` AWS ParallelCluster 검색합니다. 기본값은 `1`입니다. 컴퓨팅 플릿을 중지하지 않고 언제라도 이 파라미터를 업데이트할 수 있습니다. ### `compute_console_wait_time` `compute_console_wait_time`는 노드 실패 감지와 해당 노드에서 콘솔 출력 수집 사이의 AWS ParallelCluster 대기 시간을 초 단위로 설정합니다. Amazon EC2가 종료된 노드로부터 최종 출력을 수집하는 데 시간이 더 필요하다고 판단되면 대기 시간을 늘릴 수 있습니다. 기본값은 300초(5분)입니다. 컴퓨팅 플릿을 중지하지 않고 언제라도 이 파라미터를 업데이트할 수 있습니다. # PCUI 및 AWS ParallelCluster 런타임 로그 검색 문제 해결을 위해 PCUI 및 AWS ParallelCluster 런타임 로그를 검색하는 방법을 알아봅니다. 시작하려면 관련 PCUI와 AWS ParallelCluster 스택 이름을 찾아보세요. 스택 이름을 사용하여 설치 로그 그룹을 찾을 수 있습니다. 완료하려면 로그를 내보내세요. 이러한 로그는 AWS ParallelCluster 런타임에만 해당됩니다. 클러스터 로그는 [로그 검색 및 보존](troubleshooting-v3-get-logs.md) 섹션을 참조하세요. **사전 조건** + 가 설치 AWS CLI 됩니다. + PCUI가 켜져 AWS 계정 있는에서 AWS CLI 명령을 실행할 수 있는 자격 증명이 있습니다. + PCUI가 켜져 AWS 계정 있는에서 Amazon CloudWatch 콘솔에 액세스할 수 있습니다. ## 1단계: 관련 스택의 스택 이름 찾기 다음 예에서는 빨간색으로 강조 표시된 텍스트를 실제 값으로 바꿉니다. PCUI를 설치한 AWS 리전 를 사용하여 스택을 나열합니다. ``` $ aws cloudformation list-stacks --region aws-region-id ``` 다음 스택의 스택 이름을 적어 둡니다. + 계정에 PCUI를 배포한 스택의 이름입니다. PCUI를 설치할 때 이 이름을 입력했습니다(예: `pcluster-ui`). + 입력한 AWS ParallelCluster 스택 이름 앞에 접두사가 붙은 스택입니다. 예: `pcluster-ui-ParallelClusterApi-ABCD1234EFGH`. ## 2단계: 로그 그룹 찾기 다음 예와 같이 PCUI 스택의 로그 그룹을 나열합니다. ``` $ aws cloudformation describe-stack-resources \ --region aws-region-id \ --stack-name pcluster-ui \ --query "StackResources[?ResourceType == 'AWS::Logs::LogGroup' && (LogicalResourceId == 'ApiGatewayAccessLog' || LogicalResourceId == 'ParallelClusterUILambdaLogGroup')].PhysicalResourceId" \ --output text ``` 다음 예제와 같이 AWS ParallelCluster API 스택의 로그 그룹을 나열합니다. ``` $ aws cloudformation describe-stack-resources \ --region aws-region-id \ --stack-name pcluster-ui-ParallelCluster-Api-ABCD1234EFGH \ --query "StackResources[?ResourceType == 'AWS::Logs::LogGroup' && LogicalResourceId == 'ParallelClusterFunctionLogGroup'].PhysicalResourceId" \ --output text ``` 다음 단계에서 사용할 수 있도록 로그 그룹 목록을 적어 둡니다. ## 3단계: 로그 내보내기 다음 단계를 사용하여 로그를 수집하고 내보낼 수 있습니다. 1. 에 로그인 AWS Management Console한 다음 PCUI가 켜져 있는 AWS 계정 에서 [Amazon CloudWatch](https://console.aws.amazon.com/cloudwatch/) 콘솔로 이동합니다. 1. 탐색 창에서 **Logs**(로그), **Logs Insights**를 선택합니다. 1. 이전 단계에서 나열된 로그 그룹을 모두 선택합니다. 1. 시간 범위(예: 12시간)를 선택합니다. 1. 다음 쿼리를 실행합니다. ``` $ fields @timestamp, @message | sort @timestamp desc | limit 10000 ``` 1. **결과 내보내기**, **테이블 다운로드(JSON)**를 선택합니다. # 로그 검색 및 보존 AWS ParallelCluster 는 HeadNode 및 컴퓨팅 인스턴스와 스토리지에 대한 Amazon EC2 지표를 생성합니다. CloudWatch 콘솔 **사용자 지정 대시보드에서 지표를 볼 수 있습니다**. AWS ParallelCluster 또한는 로그 그룹에 클러스터 CloudWatch 로그 스트림을 생성합니다. CloudWatch 콘솔 사용자 지정 대시보드**** 또는 로그 그룹****에서 이러한 로그를 볼 수 있습니다. [모니터링](Monitoring-v3.md#yaml-Monitoring-Logs-CloudWatch) 클러스터 구성 섹션에서는 클러스터 CloudWatch 로그 및 대시보드를 수정하는 방법을 설명합니다. 자세한 내용은 [Amazon CloudWatch Logs와 통합](cloudwatch-logs-v3.md) 및 [Amazon CloudWatch 대시보드](cloudwatch-dashboard-v3.md) 섹션을 참조하세요. 로그는 문제를 해결하는 데 유용한 리소스입니다. 예를 들어, 장애가 발생한 클러스터를 삭제하려면 먼저 클러스터 로그의 아카이브를 만드는 것이 유용할 수 있습니다. 아카이브를 생성하려면 [아카이브 로그](#troubleshooting-v3-get-logs-archive)에서 다음 단계를 따르세요. **Topics** + [CloudWatch에서 클러스터 로그를 사용할 수 없음](#troubleshooting-v3-get-logs-unavailable) + [아카이브 로그](#troubleshooting-v3-get-logs-archive) + [보존된 로그](#troubleshooting-v3-get-logs-preserve) + [종료된 노드 로그](#troubleshooting-v3-get-logs-terminated-node) ## CloudWatch에서 클러스터 로그를 사용할 수 없음 CloudWatch에서 클러스터 로그를 사용할 수 없는 경우 구성에 사용자 지정 로그를 추가할 때 AWS ParallelCluster CloudWatch 로그 구성을 덮어쓰지 않았는지 확인합니다. CloudWatch 구성에 사용자 지정 로그를 추가하려면 가져오고 덮어쓰지 말고 구성에 추가해야 합니다. `fetch-config`및 `append-config`에 대한 자세한 내용은 CloudWatch 사용 설명서**의 [다중 CloudWatch 에이전트 구성 파일](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-common-scenarios.html#CloudWatch-Agent-multiple-config-files)을 참조하세요. AWS ParallelCluster CloudWatch 로그 구성을 복원하려면 AWS ParallelCluster 노드 내에서 다음 명령을 실행할 수 있습니다. ``` $ PLATFORM="$(ohai platform | jq -r ".[]")" LOG_GROUP_NAME="$(cat /etc/chef/dna.json | jq -r ".cluster.log_group_name")" SCHEDULER="$(cat /etc/chef/dna.json | jq -r ".cluster.scheduler")" NODE_ROLE="$(cat /etc/chef/dna.json | jq -r ".cluster.node_type")" CONFIG_DATA_PATH="/usr/local/etc/cloudwatch_agent_config.json" /opt/parallelcluster/pyenv/versions/cookbook_virtualenv/bin/python /usr/local/bin/write_cloudwatch_agent_json.py --platform $PLATFORM --config $CONFIG_DATA_PATH --log-group $LOG_GROUP_NAME --scheduler $SCHEDULER --node-role $NODE_ROLE /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c file:/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json -s ``` ## 아카이브 로그 로그는 Amazon S3 또는 로컬 파일(`--output-file` 파라미터에 따라 다름)에 보관할 수 있습니다. **참고** AWS ParallelCluster 3.12.0부터는 로그를 기본 AWS ParallelCluster 버킷으로 내보낼 수 있습니다. 이 경우 버킷 권한을 설정할 필요가 없습니다. **참고** CloudWatch 액세스 권한을 부여하려면 Amazon S3 버킷 정책에 권한을 추가합니다. 자세한 내용은 CloudWatch Logs 사용 설명서**의 [Amazon S3 버킷에 대한 권한 설정](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3ExportTasks.html#S3Permissions)을 참조하세요. ``` $ pcluster export-cluster-logs --cluster-name mycluster --region eu-west-1 \ --bucket bucketname --bucket-prefix logs { "url": "https://bucketname.s3.eu-west-1.amazonaws.com/export-log/mycluster-logs-202109071136.tar.gz?..." } # use the --output-file parameter to save the logs locally $ pcluster export-cluster-logs --cluster-name mycluster --region eu-west-1 \ --bucket bucketname --bucket-prefix logs --output-file /tmp/archive.tar.gz { "path": "/tmp/archive.tar.gz" } ``` 구성 또는 `export-cluster-logs` 명령의 파라미터에 명시적으로 지정되지 않은 한 아카이브에는 지난 14일 동안 헤드 노드 및 컴퓨팅 노드에서 Amazon CloudWatch Logs 스트림 및 CloudFormation 스택 이벤트가 포함됩니다. 명령이 완료되는 데 걸리는 시간은 클러스터의 노드 수와 CloudWatch Logs에서 사용 가능한 로그 스트림 수에 따라 달라집니다. 사용 가능한 로그 스트림에 대한 자세한 내용은 [Amazon CloudWatch Logs와 통합](cloudwatch-logs-v3.md) 섹션을 참조하세요. ## 보존된 로그 버전 3.0.0부터 클러스터가 삭제될 때 CloudWatch Logs를 기본적으로 AWS ParallelCluster 보존합니다. 클러스터를 삭제하고 해당 로그를 보존하려면 클러스터 구성에서 [`Monitoring`](Monitoring-v3.md)/[`Logs`](Monitoring-v3.md#yaml-Monitoring-Logs)/[`CloudWatch`](Monitoring-v3.md#yaml-Monitoring-Logs-CloudWatch)/[`DeletionPolicy`](Monitoring-v3.md#yaml-Monitoring-Logs-CloudWatch-DeletionPolicy)가 `Delete`로 설정되어 있지 않은지 확인하세요. 그렇지 않으면 이 필드의 값을 `Retain`으로 변경하고 `pcluster update-cluster` 명령을 실행하세요. 그런 다음 `pcluster delete-cluster --cluster-name `을 실행하여 클러스터를 삭제하지만 Amazon CloudWatch에 저장된 로그 그룹은 그대로 유지합니다. ## 종료된 노드 로그 정적 컴퓨팅 노드가 예기치 않게 종료되고 CloudWatch에 로그가 없는 경우가 해당 컴퓨팅 노드의 콘솔 출력을 `/var/log/parallelcluster/compute_console_output` 로그의 헤드 노드에 기록 AWS ParallelCluster 했는지 확인합니다. 자세한 내용은 [디버깅을 위한 키 로그](troubleshooting-v3-scaling-issues.md#troubleshooting-v3-key-logs) 단원을 참조하십시오. `/var/log/parallelcluster/compute_console_output` 로그를 사용할 수 없거나 노드에 대한 출력이 포함되지 않은 경우 AWS CLI 를 사용하여 실패한 노드에서 콘솔 출력을 검색합니다. 클러스터 헤드 노드에 로그인하고 `/var/log/parallelcluster/slurm_resume.log` 파일에서 장애가 발생한 노드 `instance-id`를 가져옵니다. `instance-id`로 다음 명령을 사용하여 콘솔 출력을 검색합니다. ``` $ aws ec2 get-console-output --instance-id i-abcdef01234567890 ``` 동적 컴퓨팅 노드가 시작 후 자체 종료되고 CloudWatch에 해당 노드에 대한 로그가 없는 경우 클러스터 규모 조정 작업을 활성화하는 작업을 제출하세요. 인스턴스에 장애가 발생할 때까지 기다린 다음 인스턴스 콘솔 로그를 검색하세요. 클러스터 헤드 노드에 로그인하고 `/var/log/parallelcluster/slurm_resume.log` 파일에서 컴퓨팅 노드 `instance-id`를 가져옵니다. 인스턴스 콘솔 로그를 검색하려면 다음 명령을 사용합니다. ``` $ aws ec2 get-console-output --instance-id i-abcdef01234567890 ``` 콘솔 출력 로그는 컴퓨팅 노드 로그를 사용할 수 없을 때 컴퓨팅 노드 장애의 근본 원인을 디버깅하는 데 도움이 될 수 있습니다.