기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# 로그 검색 및 보존
<a name="troubleshooting-v3-get-logs"></a>

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에서 클러스터 로그를 사용할 수 없음
<a name="troubleshooting-v3-get-logs-unavailable"></a>

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
```

## 아카이브 로그
<a name="troubleshooting-v3-get-logs-archive"></a>

로그는 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) 섹션을 참조하세요.

## 보존된 로그
<a name="troubleshooting-v3-get-logs-preserve"></a>

버전 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 <cluster_name>`을 실행하여 클러스터를 삭제하지만 Amazon CloudWatch에 저장된 로그 그룹은 그대로 유지합니다.

## 종료된 노드 로그
<a name="troubleshooting-v3-get-logs-terminated-node"></a>

정적 컴퓨팅 노드가 예기치 않게 종료되고 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
```

콘솔 출력 로그는 컴퓨팅 노드 로그를 사용할 수 없을 때 컴퓨팅 노드 장애의 근본 원인을 디버깅하는 데 도움이 될 수 있습니다.