CloudWatch가 설치된 EC2 인스턴스의 일반적인 권한 오류 문제를 해결하려면 어떻게 해야 합니까?
Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에서 Amazon CloudWatch에 대한 일반적인 권한 오류를 해결하려고 합니다.
간략한 설명
다음은 Amazon EC2 인스턴스에서 가장 흔히 발생하는 CloudWatch 권한 오류입니다.
- 연결되지 않은 AWS Identity and Access Management(IAM) 역할
- 연결된 IAM 역할에 권한이 없음
- CloudWatch 서비스 엔드포인트에 액세스할 수 없음
- 중단된 프로파일 연결 상태
- 잘못 구성된 자격 증명
- 메타데이터 정보 검색 실패
- 누락된 인증서 번들
해결 방법
연결되지 않은 IAM 역할
연결되지 않은 IAM 역할이 있는 경우 CloudWatch 로그 파일 amazon-cloudwatch-agent.log에 다음과 같은 오류가 나타날 수 있습니다.
"Failed to get credential from session: NoCredentialProviders: no valid providers in chain caused by: EnvAccessKeyNotFound: failed to find credentials in the environment."
CloudWatch 에이전트를 실행하려면 인스턴스가 IAM 역할과 올바르게 연결되어 있어야 합니다. AWS 관리형 정책인 CloudWatchAgentServerPolicy를 사용하여 각 서버에서 CloudWatch 에이전트를 실행하는 데 필요한 IAM 역할을 생성하십시오. 에이전트에서 CloudWatch Logs로 로그를 전송하며 로그 그룹 보존 정책을 설정하려는 경우 logs:PutRetentionPolicy 권한을 역할에 추가하십시오.
자세한 내용은 CloudWatch 에이전트와 함께 사용할 IAM 역할 및 사용자 생성을 참조하십시오.
연결된 IAM 역할에 권한이 없음
연결된 IAM 역할에 CloudWatch 에이전트에 대한 다음 권한이 포함되어 있어야 합니다.
"Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "cloudwatch:PutMetricData", "ec2:DescribeVolumes", "ec2:DescribeTags", "logs:PutLogEvents", "logs:DescribeLogStreams", "logs:DescribeLogGroups", "logs:CreateLogStream", "logs:CreateLogGroup", "logs:PutRetentionPolicy", "xray:PutTraceSegments", "xray:PutTelemetryRecords", "xray:GetSamplingRules", "xray:GetSamplingTargets", "xray:GetSamplingStatisticSummaries" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "ssm:GetParameter" ], "Resource": "arn:aws:ssm:*:*:parameter/AmazonCloudWatch-*" } ] }
CloudWatch 서비스 엔드포인트에 액세스할 수 없음
인터넷 연결 또는 Amazon Virtual Private Cloud(Amazon VPC) 엔드포인트를 통해 서비스 엔드포인트에 연결할 수 있습니다. 지표와 로그를 전송하려면 CloudWatch 에이전트가 특정 CloudWatch 서비스 엔드포인트와 연결을 유지해야 합니다.
- 지표의 경우 CloudWatch 에이전트가 https://ec2.example-region.amazonaws.com 및 https://monitoring.example-region.amazonaws.com 서비스 엔드포인트와 연결되어 있어야 합니다.
- 로그의 경우 CloudWatch 에이전트가 https://logs.example-region.amazonaws.com 서비스 엔드포인트와 연결되어 있어야 합니다.
CloudWatch 서비스 엔드포인트에 액세스할 수 없는 경우 CloudWatch 에이전트 로그 파일 amazon-cloudwatch-agent.log에 다음과 같은 오류 또는 이와 유사한 오류가 나타날 수 있습니다.
"2023-12-30T02:56:37Z W! {"caller":"ec2tagger/ec2tagger.go:485","msg":"ec2tagger: Unable to describe ec2 tags for initial retrieval","kind":"processor","name":"ec2tagger","pipeline":"metrics/host","error":"RequestError: send request failed\caused by: Post \"https://ec2.us-west-1.amazonaws.com/\": dial tcp 176.32.118.30:443: i/o timeout"}"
연결이 없는 Amazon EC2 인스턴스에서 지표를 푸시하려면 NAT 게이트웨이를 설정하거나 Amazon VPC 엔드포인트를 생성해야 합니다. Amazon VPC 엔드포인트를 생성하는 경우에는 연결을 테스트해야 합니다. 또한 CloudWatch에 액세스하는 모든 가용 영역에 대해 하나의 서브넷을 선택하십시오.
참고: NAT 게이트웨이를 설정하거나 Amazon VPC 엔드포인트를 생성하는 경우 추가 요금이 발생합니다. 자세한 내용은 AWS PrivateLink 요금 및 Amazon VPC 요금을 참조하십시오.
중단된 프로파일 연결 상태
인스턴스 프로파일을 업데이트할 때 한 역할이 연결 해제되고 다른 역할이 연결되는 중이면 중단된 프로파일 연결 상태가 발생합니다. 이전 역할의 연결이 완전히 해제되지 않은 경우 프로파일 연결 상태가 중단된 것입니다.
인스턴스의 연결을 목록으로 표시하려면 다음 명령을 실행합니다.
참고: example-instance-id를 필요한 인스턴스 ID로 바꾸고, example-region을 필요한 AWS 리전으로 바꿉니다.
$ aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=example-instance-id --region example-region
출력 예시:
{ "IamInstanceProfileAssociations": [ { "AssociationId": "iip-assoc-aaaaaaaaa", "InstanceId": "i-08c9a2ccvssdfgge", "IamInstanceProfile": { "Arn": "arn:aws:iam::1234567890:instance-profile/CloudWatch_Monitoring", "Id": "AIPAdddddsgggggg" }, "State": "disassociating" }, { "AssociationId": "iip-assoc-bbbbbbb", "InstanceId": "i-08c9a2ccvssdfgge", "IamInstanceProfile": { "Arn": "arn:aws:iam::1234567890:instance-profile/Grafana", "Id": "AIPA3gggdddddddgg" }, "State": "associating" } ] }
중단된 프로파일 연결 상태를 해결하려면 AWS Management Console 또는 AWS Command Line Interface(AWS CLI)를 사용하십시오.
AWS Management Console 사용
AWS CLI 사용
참고: AWS CLI 명령을 실행할 때 오류가 발생하면 AWS CLI 오류 문제 해결을 참조하십시오. 또한 최신 AWS CLI 버전을 사용하고 있는지 확인하십시오.
-
모든 연결을 한 번에 하나씩 해제합니다. 연결 해제하려는 각 연결에 대해 다음 명령을 실행합니다.
참고: example-association-id를 연결 해제하려는 연결 ID로 바꿉니다.$ aws ec2 disassociate-iam-instance-profile --association-id example-association-id
-
인스턴스 프로파일의 연결을 목록으로 표시하여 필요한 모든 연결이 해제되었는지 확인합니다.
참고: example-instance-id를 필요한 인스턴스 ID로 바꾸고, example-region을 필요한 AWS 리전으로 바꿉니다.$ aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=example-instance-id --region example-region
-
IAM 프로파일을 연결합니다.
참고: example-instance-id를 필요한 인스턴스 ID로 바꾸고, example-profile-name을 필요한 프로파일 이름으로 바꿉니다.aws ec2 associate-iam-instance-profile \ --instance-id example-instance-id \ --iam-instance-profile Name=example-profile-name
잘못 구성된 자격 증명
CloudWatch 에이전트는 다음 유형의 자격 증명을 순서대로 검색합니다.
- env
- assume-role
- assume-role-with-web-identity
- sso
- shared-credentials-file
- custom-process
- config-file
- ec2-credentials-file
- boto-config
- container-role
- iam-role
참고: iam-role 자격 증명은 CloudWatch 에이전트가 검색하는 자격 증명 목록의 마지막에 있습니다. iam-role 앞에 다른 자격 증명이 있는 경우 iam-role 자격 증명이 사용되지 않습니다.
사용 중인 자격 증명을 확인하려면 인스턴스에서 다음 명령을 실행합니다.
$ aws sts get-caller-identity --debug
iam-role 자격 증명이 사용되지 않는 문제를 해결하려면 탐지된 자격 증명에 적절한 정책을 연결하거나 탐지된 자격 증명을 제거하십시오. 탐지된 자격 증명을 제거하면 iam-role 자격 증명이 기본 자격 증명이 됩니다.
메타데이터 정보 검색 실패
CloudWatch 에이전트가 메타데이터 정보를 검색하지 못하면 로그 파일 amazon-cloudwatch-agent.log에 EC2MetadataError가 나타날 수 있습니다. 이 오류를 해결하려면 다음 단계를 완료하십시오.
메타데이터 접근성 확인
-
메타데이터 접근성을 확인하려면 다음 명령을 실행합니다.
```bash curl http://169.254.169.254/latest/meta-data/iam/security-credentials curl http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance curl http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials curl http://169.254.169.254/latest/meta-data ```
-
메타데이터 버전이 다르면 다음 명령을 실행합니다.
IMDSv1:wget -q -O - http://169.254.169.254/latest/meta-data/instance-id curl http://169.254.169.254/
IMDSv2:
TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \ && curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/
네트워크 설정 확인
라우팅 테이블을 확인하여 메타데이터 IP 주소 169.254.169.254에 대해 생성된 경로가 없는지 확인합니다.
-
Linux의 경우 다음 명령을 실행합니다.
OS 커널 수준 라우팅 테이블을 확인합니다.sudo route -n netstat -rn ip route list
방화벽을 확인합니다.
sudo iptables -L
경로가 없는 경우 커널 수준 라우팅 테이블에 경로를 추가하십시오.
참고: example-gateway를 필요한 게이트웨이로 바꿉니다.sudo ip route add 169.254.169.254 via <example-gateway>
-
Windows의 경우 다음 명령을 실행합니다.
라우팅 테이블을 확인합니다.ipconfig /all route print
경로가 없는 경우 고정 경로를 추가하십시오.
참고: example-gateway를 필요한 게이트웨이 IP 주소로 바꿉니다.route -p ADD 169.254.169.251 MASK 255.255.255.255 <gateway-ip> route -p ADD 169.254.169.250 MASK 255.255.255.255 <example-gateway> route -p ADD 169.254.169.254 MASK 255.255.255.255 <example-gateway> route -p ADD 169.254.169.249 MASK 255.255.255.255 <example-gateway> route -p ADD 169.254.169.123 MASK 255.255.255.255 <example-gateway> route -p ADD 169.254.169.253 MASK 255.255.255.255 <example-gateway>
IMDS의 PUT 응답 홉 제한 확인
기본적으로 HttpPutResponseHopLimit는 1로 설정됩니다. 이렇게 하면 하나의 라우터 또는 홉에서만 패킷을 전달하고 인스턴스의 로컬 네트워크 내에 요청을 유지할 수 있습니다. 다음과 같은 시나리오에서 홉 제한을 조정하십시오.
- IMDS 요청이 둘 이상의 네트워크 홉을 통과하는 경우 HttpPutResponseHopLimit를 조정합니다.
- Amazon EC2 인스턴스에서 컨테이너 오케스트레이션 시스템을 사용하고 메타데이터 서비스 요청에 추가 홉이 도입되는 경우 홉 제한을 조정합니다. 컨테이너가 계속 IMDS에 액세스할 수 있도록 홉 제한을 조정합니다.
- 검사 또는 로깅을 위해 특정 네트워크 경로를 통해 요청을 전달하거나 라우팅하는 경우 홉 제한을 조정합니다.
- IMDS에 액세스할 때 네트워크 문제로 장애가 발생하는 경우 진단을 위해 홉 제한을 조정합니다. 문제 해결이 완료되면 홉 제한 값을 롤백해야 합니다.
프록시 설정 확인
프록시 설정은 CloudWatch 에이전트가 메타데이터 정보를 가져오는 기능을 방해할 수 있습니다. 프록시가 구성된 경우 common-config.toml을 적절한 프록시 값으로 업데이트하십시오.
프록시 설정 예시:
```toml [proxy] # http_proxy = "{example-http-url}" # https_proxy = "{example-https-url}" no_proxy = "169.254.169.254"
IMDSv2와의 버전 호환성 확인
CloudWatch 에이전트 1.23 이전 버전은 IMDSv2를 지원하지 않습니다. 이전 버전의 CloudWatch 에이전트를 실행하는 경우 CloudWatch 에이전트를 최신 버전으로 업데이트하십시오.
CloudWatch 에이전트의 버전을 확인하려면 다음 명령을 실행합니다.
Linux의 경우:
```bash sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a status ```
Windows의 경우:
```powershell & $Env:ProgramFiles\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1 -m ec2 -a status ```
CloudWatch 에이전트가 온프레미스에서 실행 중인 것으로 간주하는지 확인
CloudWatch 에이전트가 Amazon EC2 Docker 컨테이너에 설치되어 있는 경우 메타데이터 정보를 가져오지 못하면 에이전트는 온프레미스에서 실행 중인 것으로 간주합니다. 다음과 같은 오류가 나타날 수 있습니다.
"2023/05/19 11:43:50 I! access ECS task metadata fail with response unable to get response from http://169.254.170.2/v2/metadata, error: Get "http://169.254.170.2/v2/metadata": context deadline exceeded (Client.Timeout exceeded while awaiting headers), assuming I'm not running in ECS.
I! Detected the instance is OnPremise"
이 오류는 CloudWatch 에이전트가 Linux 시스템의 /root/.aws/credentials 경로에서 자격 증명을 찾으려고 시도하는데 시간이 초과될 때 발생합니다. 이 시간 초과는 에이전트가 Amazon EC2 대신 Amazon Elastic Container Service(Amazon ECS)의 메타데이터 엔드포인트 IP에 연결하려고 할 때 발생합니다. 이 문제를 해결하려면 다음 중 하나를 완료하십시오.
- 기본 OS에 설치된 CloudWatch 에이전트의 완전한 버전을 사용합니다. 이렇게 하면 클러스터 설정을 우회할 수 있습니다.
- CloudWatch Container Insights에서 CloudWatch 에이전트의 OnPremise 옵션을 사용하고 올바른 AWS 자격 증명이 제공되었는지 확인합니다. 이렇게 하면 Amazon ECS 엔드포인트에 대한 메타데이터 호출을 방지할 수 있습니다.
누락된 인증서 번들
인증서 번들에 필요한 Amazon 루트 인증서가 포함되어 있지 않으면 Amazon EC2 클라이언트에 신뢰 문제가 발생합니다. CloudWatch 에이전트 로그 파일에 다음과 같은 오류가 표시될 수 있습니다.
"caused by: Post "https://ec2.ca-central-1.amazonaws.com/": x509: certificate signed by unknown authority, metrics will be dropped until it got fixed 2023-08-08T17:24:10Z E! refresh EC2 Instance Tags failed: RequestError: send request failed caused by: Post "https://ec2.ca-central-1.amazonaws.com/": x509: certificate signed by unknown authority, metrics will be dropped until it got fixed 2023-08-08T17:34:10Z E! refresh EC2 Instance Tags failed: RequestError: send request failed caused by: Post "https://ec2.ca-central-1.amazonaws.com/": x509: certificate signed by unknown authority, metrics will be dropped until it got fixed"
인증서 번들을 검사하려면 다음 명령을 실행합니다.
-
Linux의 경우 인증서는 /etc/ssl/certs/에 저장됩니다. 기본 인증서 번들을 검사하려면 다음 명령을 실행합니다.
``bash cat /etc/ssl/certs/ca-certificates.crt ``
-
자체 인증서가 있는 애플리케이션의 경우 다음 명령을 실행합니다.
참고: example-region을 필요한 AWS 리전으로 바꿉니다.``bash curl --cacert /path/to/ca-bundle.crt -Iv https://ec2.example-region.amazonaws.com/ ``
-
Windows의 경우 인증서는 Microsoft 관리 콘솔(MMC) 을 통해 관리됩니다. Windows 시스템에서 MMC에 액세스하려면 Windows 아이콘 버튼과 R을 동시에 누릅니다. 프롬프트가 나타나면 mmc를 입력하고 Enter를 선택합니다.
참고: Amazon 루트 인증서가 없는 경우 시스템 또는 애플리케이션의 인증서 번들에 추가하십시오.
관련 콘텐츠
- 질문됨 일 년 전lg...
- 질문됨 10달 전lg...
- AWS 공식업데이트됨 2년 전
- AWS 공식업데이트됨 한 달 전
- AWS 공식업데이트됨 8달 전
- AWS 공식업데이트됨 10달 전