# CloudWatch 에이전트 설치
Amazon EC2 인스턴스, 온프레미스 서버, 컨테이너화된 환경에 CloudWatch 에이전트를 설치하여 지표, 로그, 트레이스를 수집할 수 있습니다. 에이전트는 Linux, Windows, macOS 운영 체제를 지원합니다. Systems Manager를 사용하거나, CloudWatch 콘솔을 통하거나, 명령줄에서 설치하거나, 구성 파일을 사용하여 설치하는 등의 여러 가지 방법으로 에이전트를 설치할 수 있습니다. 설치하기 전에 필요한 IAM 권한과 네트워크 액세스가 구성되어 있는지 확인합니다.
**Topics**
+ [CloudWatch 콘솔에서 워크로드 탐지와 함께 Amazon CloudWatch 에이전트 설치 및 구성](install-cloudwatch-agent-workload-detection.md)
+ [Amazon EC2에서 수동 설치](manual-installation.md)
+ [AWS Systems Manager를 사용하여 CloudWatch 에이전트 설치](installing-cloudwatch-agent-ssm.md)
+ [온프레미스 서버에 CloudWatch 에이전트 설치](install-CloudWatch-Agent-on-premise.md)
+ [CloudFormation을 사용하여 새 인스턴스에 CloudWatch 에이전트 설치](Install-CloudWatch-Agent-New-Instances-CloudFormation.md)
+ [Amazon CloudWatch Observability EKS 추가 기능 또는 헬름 차트를 사용하여 CloudWatch 에이전트 설치](install-CloudWatch-Observability-EKS-addon.md)
# CloudWatch 콘솔에서 워크로드 탐지와 함께 Amazon CloudWatch 에이전트 설치 및 구성
## 소개
CloudWatch 시작하기 콘솔을 사용하여 Amazon EC2 인스턴스에 CloudWatch 에이전트를 설치하고 구성할 수 있습니다. Amazon CloudWatch 에이전트는 Amazon EC2 인스턴스에서 시스템 수준 지표, 로그, 트레이스를 수집하는 경량 소프트웨어 구성 요소입니다. 에이전트를 사용하면 모니터링 데이터를 수집한 후 CloudWatch로 전송하는 작업을 자동화하여 실행 가능한 인사이트를 얻고, 리소스 사용률을 최적화하며, 최소한의 구성 작업으로 애플리케이션을 원활하게 실행할 수 있습니다.
자동 워크로드 감지를 활용하여 인스턴스에서 실행 중인 애플리케이션 및 서비스를 식별하는 사전 정의된 워크로드별 구성으로 CloudWatch 에이전트를 구성합니다. 특정 지표, 로그, 트레이스로 데이터 수집을 사용자 지정하여 애플리케이션 성능을 모니터링하고 문제를 효과적으로 해결할 수 있습니다.
## 작동 방식
CloudWatch 에이전트는 자동 워크로드 탐지 기능을 통해 Amazon EC2 인스턴스에서 실행 중인 워크로드를 탐지합니다. 이 기능은 인스턴스에서 실행 중인 애플리케이션 및 서비스를 식별하여 수동 구성 없이 지능형 모니터링을 활성화합니다.
관찰성 솔루션에서는 Apache Kafka, Apache Tomcat, Java Virtual Machines(JVM), NGINX, NVIDIA GPU 워크로드 같은 일반적인 애플리케이션에 맞게 사전 정의된 워크로드별 구성을 제공합니다. 이러한 솔루션은 탐지된 각 워크로드와 관련된 올바른 지표, 로그, 트레이스를 자동으로 수집하여 모니터링 설정을 간소화하므로, 수동 계측 및 구성이 필요하지 않습니다.
워크로드 탐지가 활성화되면 에이전트에서는 인스턴스 환경을 분석하고, 사전 구성된 관련 모니터링 템플릿을 자동으로 선택합니다. 이러한 구성은 AWS 주제 전문가가 각 워크로드 유형에 가장 중요한 원격 분석 데이터를 캡처하도록 최적화한 것이므로, 처음부터 종합적으로 관찰할 수 있습니다.
## 사전 조건
### SSM 에이전트 설치(필수)
Amazon EC2 인스턴스에 AWS Systems Manager(SSM) 에이전트가 설치되어 있어야 합니다. SSM 에이전트는 AWS에서 제공하는 대부분의 Amazon Machine Image(AMI)에 사전 설치되어 제공됩니다. SSM 에이전트를 수동으로 설치하거나 업데이트해야 하는 경우 [Systems Manager 설명서](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html)를 참조하세요.
**참고**
기본 호스트 관리 구성(DHMC)은 Systems Manager의 기능입니다. 이 기능을 사용하면 Amazon EC2 인스턴스가 Systems Manager에 연결할 수 있는 권한이 자동으로 부여되며, 각 인스턴스에 IAM 인스턴스 프로파일을 수동으로 연결하지 않아도 됩니다. Amazon EC2 인스턴스가 DHMC를 사용 중이고 CloudWatch 에이전트 설치 프로세스가 CloudWatch 정책을 인스턴스에 연결할 경우, 새 정책이 적용되기까지 최대 30분 정도 걸릴 수 있습니다. 이러한 지연으로 인해 지표, 로그, 트레이스를 CloudWatch로 게시하는 작업이 미뤄질 수 있습니다. 이를 완화하려면 [AmazonSSMManagedInstanceCore](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSSMManagedInstanceCore.html) 정책이 포함된 IAM 역할로 Amazon EC2 인스턴스를 생성하면 됩니다.
### 워크로드 탐지(권장)
워크로드 탐지는 인스턴스에서 실행 중인 애플리케이션 및 서비스를 자동으로 식별하는 옵트인 기능입니다. 사전 구성된 워크로드별 모니터링 템플릿을 활용하려면 워크로드 탐지를 켜는 것이 좋습니다. [CloudWatch console settings](https://console.aws.amazon.com/cloudwatch/home#settings)에서 워크로드 탐지를 활성화할 수 있습니다.
## 시작하기
Amazon CloudWatch 콘솔에서 Amazon CloudWatch 에이전트 시작하기 페이지를 엽니다. [https://console.aws.amazon.com/cloudwatch/home\$1cloudwatch-agent](https://console.aws.amazon.com/cloudwatch/home#cloudwatch-agent)
**CloudWatch 에이전트를 위한 수동 인스턴스 배포**
CloudWatch 에이전트를 설치하고 구성하기 위한 최대 50개의 인스턴스를 수동으로 선택합니다. 이러한 타겟팅된 접근 방식을 사용하면 특정 Amazon EC2 인스턴스에 대한 모니터링을 개선할 수 있습니다.
**CloudWatch 에이전트를 위한 태그 기반 배포**
태그 기반 배포를 사용하여 Amazon EC2 인스턴스 플릿에 CloudWatch 에이전트를 설치하고 구성합니다. 이 방법은 일치하는 태그가 있는 모든 현재 인스턴스 및 미래 인스턴스에 적용됩니다.
**태그 기반 구성**
태그 기반 구성을 사용하면 구성을 효율적으로 구성, 확인, 수정할 수 있으므로 Amazon EC2 인스턴스 플릿에서 CloudWatch 에이전트와 해당 구성을 관리할 수 있습니다.
**CloudWatch 에이전트 설치**
CloudWatch 에이전트를 설치하여 Amazon EC2 인스턴스 및 온프레미스 호스트에서 지표, 로그, 트레이스를 수집합니다. 이 원격 분석은 인프라 및 애플리케이션에 대한 중요한 상태 및 성능 데이터를 제공합니다.
**CloudWatch 에이전트 구성**
미리 정의된 워크로드별 구성으로 CloudWatch 에이전트를 구성합니다. 특정 지표, 로그, 트레이스로 데이터 수집을 사용자 지정하여 애플리케이션 성능을 모니터링하고 문제를 효과적으로 해결할 수 있습니다.
## 비용
이 프로세스 중에 추가하는 지표는 사용자 지정 지표로 청구됩니다. CloudWatch 지표 요금에 대한 자세한 내용은 [Amazon CloudWatch 요금](https://aws.amazon.com/cloudwatch/pricing)을 참조하세요.
# Amazon EC2에서 수동 설치
**참고**
CloudWatch 에이전트를 처음 설치하기 전에 사전 조건이 완료되었는지 확인합니다.
**Topics**
+ [패키지 관리자를 사용하여 Amazon Linux에 설치](#amazon-linux-package)
+ [명령줄을 사용하여 Amazon Linux에 설치](#linux-manual-install)
+ [Windows에 설치](#windows-installation)
+ [macOS에 설치](#macos-installation)
## 패키지 관리자를 사용하여 Amazon Linux에 설치
CloudWatch 에이전트는 Amazon Linux 2023 및 Amazon Linux 2에서 패키지로 사용할 수 있습니다. 이러한 운영 체제 중 하나를 사용하는 경우 다음 명령을 입력하여 패키지를 설치할 수 있습니다.
```
sudo yum install amazon-cloudwatch-agent
```
또한 인스턴스에 연결된 IAM 역할에 **CloudWatchAgentServerPolicy**가 연결되어 있는지 확인해야 합니다.
## 명령줄을 사용하여 Amazon Linux에 설치
지원되는 모든 Linux 운영 체제에서 명령줄을 사용하여 CloudWatch 에이전트를 다운로드하고 설치할 수 있습니다.
1. CloudWatch 에이전트를 다운로드합니다. Linux 서버의 경우 다음을 입력하세요. `download-link`의 경우 아래 테이블에서 적절한 다운로드 링크를 사용하세요.
```
wget download-link
```
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/manual-installation.html)
1. 패키지를 다운로드했으면 선택 사항으로 패키지 서명을 확인할 수 있습니다. 자세한 내용은 [CloudWatch 에이전트 패키지의 서명 확인](verify-CloudWatch-Agent-Package-Signature.md) 단원을 참조하세요.
1. 패키지를 설치합니다. Linux 서버에서 RPM 패키지를 다운로드한 경우 패키지가 있는 디렉터리로 변경하고 다음을 입력합니다.
```
sudo rpm -U ./amazon-cloudwatch-agent.rpm
```
Linux 서버에서 DEB 패키지를 다운로드한 경우 패키지가 있는 디렉터리로 변경하고 다음을 입력합니다.
```
sudo dpkg -i -E ./amazon-cloudwatch-agent.deb
```
## Windows에 설치
Windows Server에서 명령줄을 사용하여 CloudWatch 에이전트를 다운로드하고 설치할 수 있습니다.
1. 다음 파일을 다운로드하세요.
```
https://amazoncloudwatch-agent.s3.amazonaws.com/windows/amd64/latest/amazon-cloudwatch-agent.msi
```
1. 패키지를 다운로드했으면 선택 사항으로 패키지 서명을 확인할 수 있습니다. 자세한 내용은 [CloudWatch 에이전트 패키지의 서명 확인](verify-CloudWatch-Agent-Package-Signature.md) 단원을 참조하세요.
1. 패키지를 설치합니다. 패키지를 포함하는 디렉터리로 변경하고 다음을 입력하세요.
```
msiexec /i amazon-cloudwatch-agent.msi
```
또한 이 명령은 PowerShell 내에서도 작동합니다. MSI 명령 옵션에 대한 자세한 내용은 Microsoft Windows 문서의 [명령줄 옵션](https://docs.microsoft.com/en-us/windows/desktop/Msi/command-line-options) 단원을 참조하세요.
## macOS에 설치
macOS 컴퓨터에서 명령줄을 사용하여 CloudWatch 에이전트를 다운로드하고 설치할 수 있습니다.
1. 아키텍처에 적합한 패키지를 다운로드하세요.
```
https://amazoncloudwatch-agent.s3.amazonaws.com/darwin/amd64/latest/amazon-cloudwatch-agent.pkg
```
ARM64 아키텍처의 경우:
```
https://amazoncloudwatch-agent.s3.amazonaws.com/darwin/arm64/latest/amazon-cloudwatch-agent.pkg
```
1. 패키지를 다운로드했으면 선택 사항으로 패키지 서명을 확인할 수 있습니다. 자세한 내용은 [CloudWatch 에이전트 패키지의 서명 확인](verify-CloudWatch-Agent-Package-Signature.md) 단원을 참조하세요.
1. 패키지를 설치합니다. 패키지를 포함하는 디렉터리로 변경하고 다음을 입력하세요.
```
sudo installer -pkg ./amazon-cloudwatch-agent.pkg -target /
```
# AWS Systems Manager를 사용하여 CloudWatch 에이전트 설치
AWS Systems Manager를 사용하면 Amazon EC2 인스턴스 플릿에 CloudWatch 에이전트를 더 쉽게 설치할 수 있습니다. 에이전트를 하나의 서버에 다운로드한 후 플릿의 모든 서버에 대한 CloudWatch 에이전트 구성 파일을 생성할 수 있습니다. 그러면 Systems Manager에서 생성한 구성 파일을 사용하여 다른 서버에 에이전트를 설치할 수 있습니다. 다음 주제를 참조하여 AWS Systems Manager를 사용해 CloudWatch 에이전트를 설치하고 실행할 수 있습니다.
**Topics**
+ [SSM Agent 설치 또는 업데이트](#update-SSM-Agent-EC2instance-first)
+ [Systems Manager 사전 조건 확인](#install-CloudWatch-Agent-minimum-requirements-first)
+ [인터넷 액세스 확인](#install-CloudWatch-Agent-internet-access-first)
+ [CloudWatch 에이전트 패키지를 첫 번째 인스턴스에 다운로드](#install-CloudWatch-Agent-EC2-first)
+ [에이전트 구성 파일 생성 및 수정](#CW-Agent-Instance-Create-Configuration-File-first)
+ [에이전트 구성을 사용하여 추가 EC2 인스턴스에 CloudWatch 에이전트를 설치하고 시작](#install-CloudWatch-Agent-on-EC2-Instance-fleet)
+ [에이전트 구성을 사용하여 추가 EC2 인스턴스에 CloudWatch 에이전트를 설치하고 시작](#install-CloudWatch-Agent-on-EC2-Instance-fleet)
+ [(선택 사항) CloudWatch 에이전트에 대한 일반 구성 및 명명된 프로파일 수정](#CloudWatch-Agent-profile-instance-fleet)
## SSM Agent 설치 또는 업데이트
Amazon EC2 인스턴스에서 CloudWatch 에이전트를 사용하려면 인스턴스가 SSM Agent의 2.2.93.0 이상 버전을 실행하고 있어야 합니다. CloudWatch 에이전트를 설치하기 전에 인스턴스에서 SSM Agent를 업데이트하거나 설치합니다(아직 하지 않은 경우).
Linux를 실행하는 인스턴스에 SSM Agent를 설치하거나 업데이트하는 방법에 대한 자세한 내용은 *AWS Systems Manager 사용 설명서*의 [Linux 인스턴스에 SSM Agent 설치 및 구성](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html) 단원을 참조하세요.
SSM Agent 설치 또는 업데이트에 대한 자세한 내용은 *AWS Systems Manager 사용 설명서*의 [SSM Agent 작업](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html) 단원을 참조하세요.
## Systems Manager 사전 조건 확인
Systems Manager Run Command를 사용하여 CloudWatch 에이전트를 설치 및 구성하기 전에 인스턴스가 Systems Manager 최소 요구 사항을 충족하는지 확인하세요. 자세한 내용은 *AWS Systems Manager 사용 설명서*의 [Systems Manager 사전 조건](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up.html#systems-manager-prereqs) 단원을 참조하세요.
## 인터넷 액세스 확인
Amazon EC2 인스턴스는 CloudWatch 엔드포인트에 연결할 수 있어야 합니다. 인터넷 게이트웨이, NAT 게이트웨이 또는 CloudWatch 인터페이스 VPC 엔드포인트를 기준으로 할 수 있습니다. 인터넷 액세스를 구성하는 방법에 대한 자세한 내용은 *Amazon VPC 사용 설명서*의 [인터넷 게이트웨이](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) 단원을 참조하세요.
프록시에서 구성할 엔드포인트와 포트는 다음과 같습니다.
+ 에이전트를 사용하여 지표를 수집하는 경우 적절한 리전의 CloudWatch 엔드포인트를 허용 목록에 추가해야 합니다. 이러한 엔드포인트는 **Amazon Web Services 일반 참조의 [Amazon CloudWatch](https://docs.aws.amazon.com/general/latest/gr/rande.html#cw_region)에 나열되어 있습니다.
+ 에이전트를 사용하여 로그를 수집하는 경우 적절한 리전의 CloudWatch Logs 엔드포인트를 허용 목록에 추가해야 합니다. 이러한 엔드포인트는 **Amazon Web Services 일반 참조의 [Amazon CloudWatch Logs](https://docs.aws.amazon.com/general/latest/gr/rande.html#cwl_region)에 나열되어 있습니다.
+ Systems Manager를 사용하여 에이전트를 설치하거나 파라미터 스토어를 사용하여 구성 파일을 저장하는 경우 적절한 리전의 Systems Manager 엔드포인트를 허용 목록에 추가해야 합니다. 이러한 엔드포인트는 **Amazon Web Services 일반 참조의 [AWS Systems Manager](https://docs.aws.amazon.com/general/latest/gr/rande.html#ssm_region)에 에 나열되어 있습니다.
## CloudWatch 에이전트 패키지를 첫 번째 인스턴스에 다운로드
다음 단계에 따라 Systems Manager를 사용하여 CloudWatch 에이전트 패키지를 다운로드합니다.
**Systems Manager를 사용하여 CloudWatch 에이전트 다운로드**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **명령 실행**을 선택합니다.
-또는-
AWS Systems Manager 홈페이지가 열리면 아래로 스크롤하여 [**Run Command 탐색(Explore Run Command)**]을 선택합니다.
1. **명령 실행**을 선택합니다.
1. **명령 문서** 목록에서 **AWS-ConfigureAWSPackage**를 선택합니다.
1. [**대상(Targets)**] 영역에서 CloudWatch 에이전트를 설치할 인스턴스를 선택합니다. 특정 인스턴스가 표시되지 않으면 Systems Manager에서 사용할 관리형 인스턴스로 구성되지 않은 것일 수 있습니다. 자세한 내용은 *AWS Systems Manager 사용 설명서*에서 [하이브리드 환경의 AWS Systems Manager 설정](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-managedinstances.html) 단원을 참조하세요.
1. **작업** 목록에서 **설치**를 선택합니다.
1. **이름** 필드에 *AmazonCloudWatchAgent*를 입력합니다.
1. 최신 버전의 에이전트를 설치하도록 **버전**을 **최신** 상태로 설정한 채로 유지합니다.
1. **실행**을 선택합니다.
1. (선택 사항) [**대상 및 출력(Targets and outputs)**] 영역에서 인스턴스 이름 옆의 버튼을 선택하고 [**출력 보기(View output)**]를 선택합니다. Systems Manager에 에이전트가 성공적으로 설치되었다고 표시되어야 합니다.
## 에이전트 구성 파일 생성 및 수정
CloudWatch 에이전트를 다운로드했으면 서버에서 에이전트를 시작하기 전에 구성 파일을 생성해야 합니다.
에이전트 구성 파일을 Systems Manager 파라미터 스토어에 저장하려는 경우 EC2 인스턴스를 사용하여 파라미터 스토어에 저장해야 합니다. 또한 먼저, 해당 인스턴스에 `CloudWatchAgentAdminRole` IAM 역할을 연결해야 합니다. 역할 연결에 대한 자세한 내용은 **Amazon EC2 사용 설명서의 [인스턴스에 IAM 역할 연결](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/iam-roles-for-amazon-ec2.html#attach-iam-role) 섹션을 참조하세요.
CloudWatch 에이전트 구성 파일 생성에 대한 자세한 내용은 [CloudWatch 에이전트 구성 파일 생성](create-cloudwatch-agent-configuration-file.md) 단원을 참조하세요.
## 에이전트 구성을 사용하여 추가 EC2 인스턴스에 CloudWatch 에이전트를 설치하고 시작
CloudWatch 에이전트 구성을 파라미터 스토어에 저장했으면 다른 서버에 에이전트를 설치할 때 이를 사용할 수 있습니다.
각 서버에 대해 이 섹션의 앞에 나열된 단계에 따라 Systems Manager 사전 요구 사항, SSM Agent 버전, 인터넷 액세스를 확인합니다. 그런 다음 생성한 CloudWatch 에이전트 구성 파일을 사용하여 다음 지침에 따라 추가 인스턴스에 CloudWatch 에이전트를 설치합니다.
**1단계: CloudWatch 에이전트 다운로드 및 설치**
CloudWatch 데이터를 다른 리전으로 전송할 수 있도록 이 인스턴스에 연결한 IAM 역할에 해당 리전의 CloudWatch 데이터에 대한 쓰기 권한이 있는지 확인합니다.
다음은 `aws configure` 명령을 사용하여 CloudWatch 에이전트에 대한 명명된 프로파일을 생성하는 예입니다. 이 예에서는 `AmazonCloudWatchAgent`의 기본 프로필 이름을 사용하는 것으로 가정합니다.
**CloudWatch 에이전트에 대한 AmazonCloudWatchAgent 프로파일을 생성하려면**
+ Linux 서버에서 다음 명령을 입력하고 표시되는 메시지를 따릅니다.
```
sudo aws configure --profile AmazonCloudWatchAgent
```
Windows Server에서는 관리자 권한으로 PowerShell을 열고 다음 명령을 입력한 후 표시되는 메시지를 따릅니다.
```
aws configure --profile AmazonCloudWatchAgent
```
## 에이전트 구성을 사용하여 추가 EC2 인스턴스에 CloudWatch 에이전트를 설치하고 시작
CloudWatch 에이전트 구성을 파라미터 스토어에 저장했으면 다른 서버에 에이전트를 설치할 때 이를 사용할 수 있습니다.
각 서버에 대해 이 섹션의 앞에 나열된 단계에 따라 Systems Manager 사전 요구 사항, SSM Agent 버전, 인터넷 액세스를 확인합니다. 그런 다음 생성한 CloudWatch 에이전트 구성 파일을 사용하여 다음 지침에 따라 추가 인스턴스에 CloudWatch 에이전트를 설치합니다.
**1단계: CloudWatch 에이전트 다운로드 및 설치**
에이전트를 실행할 각 서버에 에이전트를 설치해야 합니다. CloudWatch 에이전트는 Amazon Linux 2023 및 Amazon Linux 2에서 패키지로 사용할 수 있습니다. 이 운영 체제를 사용하는 경우 Systems Manager를 사용하여 다음 단계에 따라 패키지를 설치할 수 있습니다.
**참고**
또한 인스턴스에 연결된 IAM 역할에 **CloudWatchAgentServerPolicy**가 연결되어 있는지 확인해야 합니다. 자세한 내용은 [사전 조건](prerequisites.md) 섹션을 참조하세요.
**Systems Manager를 사용하여 CloudWatch 에이전트 패키지 설치**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **명령 실행**을 선택합니다.
-또는-
AWS Systems Manager 홈페이지가 열리면 아래로 스크롤하여 [**Run Command 탐색(Explore Run Command)**]을 선택합니다.
1. **명령 실행**을 선택합니다.
1. **명령 문서** 목록에서 **AWS-RunShellScript**를 선택합니다. 그런 다음 다음을 **명령 파라미터**에 붙여넣습니다.
```
sudo yum install amazon-cloudwatch-agent
```
1. **실행**을 선택합니다.
지원되는 모든 운영 체제에서 Systems Manager Run Command 또는 Amazon S3 다운로드 링크를 사용하여 CloudWatch 에이전트 패키지를 다운로드할 수 있습니다.
**참고**
CloudWatch 에이전트를 설치하거나 업데이트하는 경우 **제거 및 재설치(Uninstall and reinstall)** 옵션만 지원됩니다. **현재 위치 업데이트(In-place update)** 옵션을 사용할 수 없습니다.
Systems Manager Run Command를 사용하면 인스턴스의 구성을 관리할 수 있습니다. Systems Manager 문서 및 파라미터를 지정하고 하나 이상의 인스턴스에서 명령을 실행할 수 있습니다. 인스턴스의 SSM Agent는 명령을 처리하고 지정된 대로 인스턴스를 구성합니다.
**Run Command를 사용하여 CloudWatch 에이전트를 다운로드하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **명령 실행**을 선택합니다.
-또는-
AWS Systems Manager 홈페이지가 열리면 아래로 스크롤하여 [**Run Command 탐색(Explore Run Command)**]을 선택합니다.
1. **명령 실행**을 선택합니다.
1. **명령 문서** 목록에서 **AWS-ConfigureAWSPackage**를 선택합니다.
1. [**대상(Targets)**] 영역에서 CloudWatch 에이전트를 설치할 인스턴스를 선택합니다. 특정 인스턴스가 표시되지 않으면 Run Command에 대해 구성되지 않은 것일 수 있습니다. 자세한 내용은 *AWS Systems Manager 사용 설명서*에서 [하이브리드 환경의 AWS Systems Manager 설정](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-managedinstances.html) 단원을 참조하세요.
1. **작업** 목록에서 **설치**를 선택합니다.
1. **이름** 상자에 *AmazonCloudWatchAgent*를 입력합니다.
1. 최신 버전의 에이전트를 설치하도록 **버전**을 **최신** 상태로 설정한 채로 유지합니다.
1. **실행**을 선택합니다.
1. (선택 사항) [**대상 및 출력(Targets and outputs)**] 영역에서 인스턴스 이름 옆의 버튼을 선택하고 [**출력 보기(View output)**]를 선택합니다. Systems Manager에 에이전트가 성공적으로 설치되었다고 표시되어야 합니다.
**2단계: 에이전트 구성 파일을 사용하여 CloudWatch 에이전트 시작**
다음 단계에 따라 Systems Manager Run Command를 사용하여 에이전트를 시작할 수 있습니다.
보안이 강화된 Linux(SELinux)가 활성화된 시스템에서 에이전트를 설정하는 방법에 대한 내용은 [보안이 강화된 Linux(SELinux)로 CloudWatch 에이전트 설정](CloudWatch-Agent-SELinux.md) 섹션을 참조하세요.
**Run Command를 사용하여 CloudWatch 에이전트를 시작하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **명령 실행**을 선택합니다.
-또는-
AWS Systems Manager 홈페이지가 열리면 아래로 스크롤하여 [**Run Command 탐색(Explore Run Command)**]을 선택합니다.
1. **명령 실행**을 선택합니다.
1. **명령 문서** 목록에서 **AmazonCloudWatch-ManageAgent**를 선택합니다.
1. [**대상(Targets)**] 영역에서 CloudWatch 에이전트를 설치한 인스턴스를 선택합니다.
1. **작업** 목록에서 **구성**을 선택합니다.
1. **Optional Configuration Source(구성 소스(선택 사항))** 목록에서 **ssm**을 선택합니다.
1. [CloudWatch 에이전트 구성 파일 생성](create-cloudwatch-agent-configuration-file.md)에 설명된 대로 **선택적 구성 위치** 상자에서 Systems Manager Parameter Store에 생성 및 저장한 에이전트 구성 파일의 Systems Manager 매개변수 이름을 입력합니다.
1. **Optional Restart(재시작(선택 사항))** 목록에서 **예**를 선택하여 해당 단계를 마친 후 에이전트가 시작되도록 합니다.
1. **실행**을 선택합니다.
1. (선택 사항) [**대상 및 출력(Targets and outputs)**] 영역에서 인스턴스 이름 옆의 버튼을 선택하고 [**출력 보기(View output)**]를 선택합니다. Systems Manager에 에이전트가 성공적으로 시작되었다고 표시되어야 합니다.
## (선택 사항) CloudWatch 에이전트에 대한 일반 구성 및 명명된 프로파일 수정
CloudWatch 에이전트에는 `common-config.toml`이라는 구성 파일이 포함되어 있습니다. 필요한 경우 이 파일을 사용하여 프록시 및 리전 정보를 지정할 수 있습니다.
Linux를 실행하는 서버에서는 이 파일이 `/opt/aws/amazon-cloudwatch-agent/etc` 디렉터리에 있습니다. Windows Server를 실행하는 서버에서는 이 파일이 `C:\ProgramData\Amazon\AmazonCloudWatchAgent` 디렉터리에 있습니다.
기본 `common-config.toml`은 다음과 같습니다.
```
# This common-config is used to configure items used for both ssm and cloudwatch access
## Configuration for shared credential.
## Default credential strategy will be used if it is absent here:
## Instance role is used for EC2 case by default.
## AmazonCloudWatchAgent profile is used for onPremise case by default.
# [credentials]
# shared_credential_profile = "{profile_name}"
# shared_credential_file= "{file_name}"
## Configuration for proxy.
## System-wide environment-variable will be read if it is absent here.
## i.e. HTTP_PROXY/http_proxy; HTTPS_PROXY/https_proxy; NO_PROXY/no_proxy
## Note: system-wide environment-variable is not accessible when using ssm run-command.
## Absent in both here and environment-variable means no proxy will be used.
# [proxy]
# http_proxy = "{http_url}"
# https_proxy = "{https_url}"
# no_proxy = "{domain}"
```
처음에는 모든 줄이 코멘트 아웃 처리되어 있습니다. 자격 증명 프로필이나 프록시 설정을 설정하려면 해당 줄에서 `#`을 제거하고 값을 지정하세요. 이 파일을 수동으로 편집하거나 다음과 같이 Systems Manager에서 `RunShellScript` Run Command를 사용하여 편집할 수 있습니다.
+ `shared_credential_profile` – 온프레미스 서버의 경우 이 줄은 CloudWatch에 데이터를 전송하는 데 사용할 IAM 사용자 자격 증명 프로파일을 지정합니다. 이 줄을 코멘트 아웃 처리된 상태로 유지할 경우 `AmazonCloudWatchAgent`가 사용됩니다.
EC2 인스턴스에서 이 줄을 사용하여 CloudWatch 에이전트가 이 인스턴스의 데이터를 다른 AWS 리전의 CloudWatch에 전송하도록 할 수 있습니다. 이렇게 하려면 보낼 리전의 이름을 지정하는 `region` 필드가 있는 명명된 프로필을 지정합니다.
`shared_credential_profile`을 지정하는 경우 `[credentials]` 행의 시작 부분에서 `#`도 제거해야 합니다.
+ `shared_credential_file` – 에이전트가 기본 경로 이외의 다른 경로에 있는 파일에서 자격 증명을 찾도록 하려면 여기에 전체 경로 및 파일 이름을 지정합니다. 기본 경로는 Linux의 경우 `/root/.aws`이며 Windows Server의 경우 `C:\\Users\\Administrator\\.aws`입니다.
아래의 첫 번째 예는 Linux 서버의 유효한 `shared_credential_file` 행 구문이고 두 번째 예는 Windows Server에 유효한 행 구문입니다. Windows Server에서는 \$1 문자를 이스케이프 처리해야 합니다.
```
shared_credential_file= "/usr/username/credentials"
```
```
shared_credential_file= "C:\\Documents and Settings\\username\\.aws\\credentials"
```
`shared_credential_file`을 지정하는 경우 `[credentials]` 행의 시작 부분에서 `#`도 제거해야 합니다.
+ 프록시 설정 - 서버가 HTTP 또는 HTTPS 프록시를 사용하여 AWS 서비스에 연결하는 경우 `http_proxy` 및 `https_proxy` 필드에 해당 프록시를 지정합니다. 프록시 설정에서 제외해야 하는 URL이 있다면 이를 쉼표로 구분하여 `no_proxy` 필드에 지정하세요.
# 온프레미스 서버에 CloudWatch 에이전트 설치
한 컴퓨터에 CloudWatch 에이전트를 다운로드하고 에이전트 구성 파일을 생성한 경우 해당 구성 파일을 사용하여 다른 온프레미스 서버에 에이전트를 설치할 수 있습니다.
## 온프레미스 서버에 CloudWatch 에이전트 다운로드
Systems Manager Run Command 또는 Amazon S3 다운로드 링크를 사용하여 CloudWatch 에이전트 패키지를 다운로드할 수 있습니다.
### Systems Manager를 사용하여 다운로드
Systems Manager Run Command를 사용하려면 Amazon EC2 Systems Manager에 온프레미스 서버를 등록해야 합니다. 자세한 내용은 *AWS Systems Manager 사용 설명서*의 [하이브리드 환경에서 Systems Manager 설정](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-managedinstances.html) 단원을 참조하세요.
서버를 이미 등록한 경우 SSM Agent를 최신 버전으로 업데이트합니다.
Linux를 실행하는 서버에서 SSM Agent를 업데이트하는 방법에 대한 자세한 내용은 *AWS Systems Manager 사용 설명서*에서 [하이브리드 환경(Linux)의 SSM Agent 설치](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-managedinstances.html#sysman-install-managed-linux) 단원을 참조하세요.
Windows Server를 실행하는 서버에서 SSM Agent를 업데이트하는 방법에 대한 자세한 내용은 *AWS Systems Manager 사용 설명서*에서 [하이브리드 환경(Windows)의 SSM Agent 설치](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-managedinstances.html#sysman-install-managed-win) 단원을 참조하세요.
**SSM Agent를 사용하여 온프레미스 서버에 CloudWatch 에이전트 패키지를 다운로드하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **명령 실행**을 선택합니다.
-또는-
AWS Systems Manager 홈페이지가 열리면 아래로 스크롤하여 [**Run Command 탐색(Explore Run Command)**]을 선택합니다.
1. **명령 실행**을 선택합니다.
1. **명령 문서** 목록에서 **AWS-ConfigureAWSPackage** 옆의 버튼을 선택합니다.
1. [**대상(Targets)**] 영역에서 CloudWatch 에이전트를 설치할 서버를 선택합니다. 특정 서버가 표시되지 않으면 Run Command에 대해 구성되지 않은 것일 수 있습니다. 자세한 내용은 *AWS Systems Manager 사용 설명서*에서 [하이브리드 환경의 AWS Systems Manager 설정](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-managedinstances.html) 단원을 참조하세요.
1. **작업** 목록에서 **설치**를 선택합니다.
1. **이름** 상자에 *AmazonCloudWatchAgent*를 입력합니다.
1. 최신 버전의 에이전트를 설치하도록 **버전**을 비워 둡니다.
1. **실행**을 선택합니다.
에이전트 패키지가 다운로드되며 다음 단계는 이를 구성하고 시작하는 것입니다.
## (온프레미스 서버에 설치) IAM 자격 증명 및 AWS 리전 지정
CloudWatch 에이전트가 온프레미스 서버의 데이터를 보낼 수 있도록 하려면 이전에 생성한 IAM 사용자의 액세스 키 및 보안 키를 지정해야 합니다.
또한 `region` 필드를 사용하여 지표를 보낼 AWS 리전을 지정해야 합니다.
다음은 이 파일의 예입니다.
```
[AmazonCloudWatchAgent]
aws_access_key_id=my_access_key
aws_secret_access_key=my_secret_key
region = us-west-1
```
*my\$1access\$1key* 및 *my\$1secret\$1key*의 경우 Systems Manager 파라미터 스토어에 대한 쓰기 권한이 없는 IAM 사용자의 키를 사용합니다.
이 프로필의 이름을 `AmazonCloudWatchAgent`로 지정하면 아무 작업도 수행할 필요가 없습니다. 다음 단원에서 설명된 대로 필요한 경우 다른 이름을 지정하고 해당 이름을 ` common-config.toml` 파일에서 `shared_credential_profile`에 대한 값으로 지정할 수 있습니다.
다음은 **aws configure** 명령을 사용하여 CloudWatch 에이전트에 대한 명명된 프로파일을 생성하는 예입니다. 이 예에서는 `AmazonCloudWatchAgent`의 기본 프로필 이름을 사용하는 것으로 가정합니다.
**CloudWatch 에이전트에 대한 AmazonCloudWatchAgent 프로파일을 생성하려면**
1. 아직 설치하지 않았다면 서버에 AWS Command Line Interface를 설치합니다. 자세한 내용은 [AWS CLI 설치](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) 단원을 참조하세요.
1. Linux 서버에서 다음 명령을 입력하고 표시되는 메시지를 따릅니다.
```
sudo aws configure --profile AmazonCloudWatchAgent
```
Windows Server에서는 관리자 권한으로 PowerShell을 열고 다음 명령을 입력한 후 표시되는 메시지를 따릅니다.
```
aws configure --profile AmazonCloudWatchAgent
```
## (선택 사항) CloudWatch 에이전트에 대한 일반 구성 및 명명된 프로파일 수정
CloudWatch 에이전트에는 `common-config.toml`이라는 구성 파일이 포함되어 있습니다. 필요한 경우 이 파일을 사용하여 프록시 및 리전 정보를 지정할 수 있습니다.
Linux를 실행하는 서버에서는 이 파일이 `/opt/aws/amazon-cloudwatch-agent/etc` 디렉터리에 있습니다. Windows Server를 실행하는 서버에서는 이 파일이 `C:\ProgramData\Amazon\AmazonCloudWatchAgent` 디렉터리에 있습니다.
기본 `common-config.toml`은 다음과 같습니다.
```
# This common-config is used to configure items used for both ssm and cloudwatch access
## Configuration for shared credential.
## Default credential strategy will be used if it is absent here:
## Instance role is used for EC2 case by default.
## AmazonCloudWatchAgent profile is used for onPremise case by default.
# [credentials]
# shared_credential_profile = "{profile_name}"
# shared_credential_file= "{file_name}"
## Configuration for proxy.
## System-wide environment-variable will be read if it is absent here.
## i.e. HTTP_PROXY/http_proxy; HTTPS_PROXY/https_proxy; NO_PROXY/no_proxy
## Note: system-wide environment-variable is not accessible when using ssm run-command.
## Absent in both here and environment-variable means no proxy will be used.
# [proxy]
# http_proxy = "{http_url}"
# https_proxy = "{https_url}"
# no_proxy = "{domain}"
```
처음에는 모든 줄이 코멘트 아웃 처리되어 있습니다. 자격 증명 프로필이나 프록시 설정을 설정하려면 해당 줄에서 `#`을 제거하고 값을 지정하세요. 이 파일을 수동으로 편집하거나 다음과 같이 Systems Manager에서 `RunShellScript` Run Command를 사용하여 편집할 수 있습니다.
+ `shared_credential_profile` – 온프레미스 서버의 경우 이 줄은 CloudWatch에 데이터를 전송하는 데 사용할 IAM 사용자 자격 증명 프로파일을 지정합니다. 이 줄을 코멘트 아웃 처리된 상태로 유지할 경우 `AmazonCloudWatchAgent`가 사용됩니다. 이 프로필 생성에 대한 자세한 내용은 [(온프레미스 서버에 설치) IAM 자격 증명 및 AWS 리전 지정](#install-CloudWatch-Agent-iam_user-SSM-onprem) 단원을 참조하세요.
EC2 인스턴스에서 이 줄을 사용하여 CloudWatch 에이전트가 이 인스턴스의 데이터를 다른 AWS 리전의 CloudWatch에 전송하도록 할 수 있습니다. 이렇게 하려면 보낼 리전의 이름을 지정하는 `region` 필드가 있는 명명된 프로필을 지정합니다.
`shared_credential_profile`을 지정하는 경우 `[credentials]` 행의 시작 부분에서 `#`도 제거해야 합니다.
+ `shared_credential_file` – 에이전트가 기본 경로 이외의 다른 경로에 있는 파일에서 자격 증명을 찾도록 하려면 여기에 전체 경로 및 파일 이름을 지정합니다. 기본 경로는 Linux의 경우 `/root/.aws`이며 Windows Server의 경우 `C:\\Users\\Administrator\\.aws`입니다.
아래의 첫 번째 예는 Linux 서버의 유효한 `shared_credential_file` 행 구문이고 두 번째 예는 Windows Server에 유효한 행 구문입니다. Windows Server에서는 \$1 문자를 이스케이프 처리해야 합니다.
```
shared_credential_file= "/usr/username/credentials"
```
```
shared_credential_file= "C:\\Documents and Settings\\username\\.aws\\credentials"
```
`shared_credential_file`을 지정하는 경우 `[credentials]` 행의 시작 부분에서 `#`도 제거해야 합니다.
+ 프록시 설정 - 서버가 HTTP 또는 HTTPS 프록시를 사용하여 AWS 서비스에 연결하는 경우 `http_proxy` 및 `https_proxy` 필드에 해당 프록시를 지정합니다. 프록시 설정에서 제외해야 하는 URL이 있다면 이를 쉼표로 구분하여 `no_proxy` 필드에 지정하세요.
# CloudFormation을 사용하여 새 인스턴스에 CloudWatch 에이전트 설치
이 섹션에서는 AWS CloudFormation을 사용하여 새로운 Amazon EC2 인스턴스에 CloudWatch 에이전트를 설치하는 방법을 설명합니다.
**참고**
Amazon은 새로운 Amazon EC2 인스턴스에 CloudWatch 에이전트를 설치하고 업데이트하는 데 도움이 되는 여러 가지 CloudFormation 템플릿을 GitHub에 업로드했습니다. CloudFormation 사용에 대한 자세한 내용은 [AWS CloudFormation란 무엇입니까?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)를 참조하세요.
템플릿 위치는 [CloudFormation을 사용하여 EC2 인스턴스에 Amazon CloudWatch 에이전트 배포](https://github.com/aws-cloudformation/aws-cloudformation-templates/tree/main/Solutions/AmazonCloudWatchAgent)입니다. 이 위치에는 `inline` 디렉터리와 `ssm` 디렉터리가 모두 포함되어 있습니다. 각 디렉터리에는 Linux 및 Windows 인스턴스 둘 다에 대한 템플릿이 포함되어 있습니다.
+ `inline` 디렉터리의 템플릿에는 CloudFormation 템플릿에 포함된 CloudWatch 에이전트 구성이 있습니다. 기본적으로 Linux 템플릿은 지표 `mem_used_percent` 및 `swap_used_percent`를 수집하고, Windows 템플릿은 `Memory % Committed Bytes In Use` 및 `Paging File % Usage`를 수집합니다.
다른 지표를 수집하도록 이러한 템플릿을 수정하려면 템플릿의 다음 섹션을 수정하세요. 다음 예제는 Linux 서버용 템플릿에서 가져옵니다. 에이전트 구성 파일의 형식 및 구문에 따라 다음과 같이 변경합니다. 자세한 내용은 [수동으로 CloudWatch 에이전트 구성 파일 생성 또는 편집](CloudWatch-Agent-Configuration-File-Details.md) 단원을 참조하세요.
```
{
"metrics":{
"append_dimensions":{
"AutoScalingGroupName":"${!aws:AutoScalingGroupName}",
"ImageId":"${!aws:ImageId}",
"InstanceId":"${!aws:InstanceId}",
"InstanceType":"${!aws:InstanceType}"
},
"metrics_collected":{
"mem":{
"measurement":[
"mem_used_percent"
]
},
"swap":{
"measurement":[
"swap_used_percent"
]
}
}
}
}
```
**참고**
인라인 템플릿에서 모든 자리 표시자 변수에는 이스케이프 문자로 앞에 느낌표(\$1)가 있어야 합니다. 이러한 내용은 예제 템플릿에서 확인할 수 있습니다. 다른 자리 표시자 변수를 추가한 경우 해당 변수의 이름 앞에 느낌표를 추가해야 합니다.
+ `ssm` 디렉터리의 템플릿은 파라미터 스토어에서 에이전트 구성 파일을 로드합니다. 이러한 템플릿을 사용하려면 먼저, 구성 파일을 생성하여 파라미터 스토어에 업로드해야 합니다. 그런 다음, 템플릿에서 파일의 파라미터 스토어 이름을 지정합니다. 구성 파일은 수동으로 생성하거나 마법사를 사용해 생성할 수 있습니다. 자세한 내용은 [CloudWatch 에이전트 구성 파일 생성](create-cloudwatch-agent-configuration-file.md) 단원을 참조하세요.
CloudWatch 에이전트를 설치하고 에이전트 구성을 업데이트하는 데 두 가지 템플릿 유형을 모두 사용할 수 있습니다.
보안이 강화된 Linux(SELinux)가 활성화된 시스템에서 에이전트를 설정하는 방법에 대한 내용은 [보안이 강화된 Linux(SELinux)로 CloudWatch 에이전트 설정](CloudWatch-Agent-SELinux.md) 섹션을 참조하세요.
## 튜토리얼: CloudFormation 인라인 템플릿을 사용하여 CloudWatch 에이전트 설치 및 구성
이 튜토리얼에서는 CloudFormation을 사용하여 새 Amazon EC2 인스턴스에 CloudWatch 에이전트를 설치하는 과정을 안내합니다. 이 튜토리얼에서는 JSON 구성 파일 또는 파라미터 스토어를 사용할 필요가 없는 인라인 템플릿을 사용하여 Amazon Linux 2를 실행하는 새 인스턴스에 설치합니다. 인라인 템플릿에는 에이전트 구성이 포함되어 있습니다. 이 자습서에서는 템플릿에 포함된 기본 에이전트 구성을 사용합니다.
에이전트를 설치하는 절차를 수행한 다음 자습서에서는 계속해서 에이전트를 업데이트하는 방법을 설명합니다.
**CloudFormation을 사용하여 새 인스턴스에 CloudWatch 에이전트를 설치하려면**
1. GitHub에서 템플릿을 다운로드합니다. 이 튜토리얼에서는 다음과 같이 Amazon Linux 2용 인라인 템플릿을 다운로드합니다.
```
curl -O https://raw.githubusercontent.com/aws-cloudformation/aws-cloudformation-templates/main/Solutions/AmazonCloudWatchAgent/inline/amazon_linux.yaml
```
1. CloudFormation 콘솔([https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/))을 엽니다.
1. **스택 생성**을 선택합니다.
1. **템플릿 선택**에서 **Amazon S3에 템플릿 업로드**를 선택하고, 다운로드한 템플릿을 선택한 후 **다음**을 선택합니다.
1. **세부 정보 지정** 페이지에 다음 파라미터를 입력하고 **다음**을 선택합니다.
+ **스택 이름**: CloudFormation 스택에 대한 스택 이름을 선택합니다.
+ **IAMRole**: CloudWatch 지표, 로그, 추적을 작성할 수 있는 권한이 있는 IAM 역할을 선택합니다. 자세한 내용은 [사전 조건](prerequisites.md) 섹션을 참조하세요.
+ **InstanceAMI**: 스택을 시작하려는 리전에서 유효한 AMI를 선택합니다.
+ **InstanceType**: 유효한 인스턴스 유형을 선택합니다.
+ **KeyName**: 새 인스턴스에 대한 SSH 액세스를 사용 설정하려면 기존 Amazon EC2 키 페어를 선택합니다. Amazon EC2 키 페어가 아직 없는 경우 AWS Management Console에서 새로 생성할 수 있습니다. 자세한 내용은 **Amazon EC2 사용 설명서의 [Amazon EC2 키 페어](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)를 참조하세요.
+ **SSHLocation**: SSH를 사용하여 인스턴스에 연결하는 데 사용할 수 있는 IP 주소 범위를 지정합니다. 기본값은 모든 IP 주소에서의 액세스를 허용합니다.
1. **옵션** 페이지에서 스택 리소스에 태그를 지정할 수 있습니다. **다음**을 선택합니다.
1. [**검토(Review)**] 페이지에서 정보를 검토하고 스택이 IAM 리소스를 생성할 수 있음을 확인한 다음, [**생성(Create)**]을 선택합니다.
콘솔을 새로 고치면 새 스택에 `CREATE_IN_PROGRESS` 상태가 있음을 알 수 있습니다.
1. 인스턴스가 생성되면 Amazon EC2 콘솔에서 해당 인스턴스를 볼 수 있습니다. 필요한 경우 호스트에 연결해 진행 상황을 확인할 수 있습니다.
다음 명령을 사용하여 에이전트가 설치되었는지 확인합니다.
```
rpm -qa amazon-cloudwatch-agent
```
다음 명령을 사용하여 에이전트가 실행 중인지 확인합니다.
```
ps aux | grep amazon-cloudwatch-agent
```
다음 절차에서는 CloudFormation에서 인라인 템플릿을 사용하여 CloudWatch 에이전트를 업데이트하는 방법을 보여 줍니다. 기본 인라인 템플릿은 `mem_used_percent` 지표를 수집합니다. 이 자습서에서는 이 지표 수집을 중지하도록 에이전트 구성을 변경합니다.
**CloudFormation을 사용하여 CloudWatch 에이전트를 업데이트하려면**
1. 이전 절차에서 다운로드한 템플릿에서 다음 줄을 제거하고 템플릿을 저장합니다.
```
"mem": {
"measurement": [
"mem_used_percent"
]
},
```
1. CloudFormation 콘솔([https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/))을 엽니다.
1. CloudFormation 대시보드에서 생성된 스택을 선택하고 **스택 업데이트**를 선택합니다.
1. **템플릿 선택**에서 **Amazon S3에 템플릿 업로드**를 선택하고, 수정한 템플릿을 선택한 후 **다음**을 선택합니다.
1. **옵션** 페이지에서 **다음**을 선택한 후 **다음**을 선택합니다.
1. **검토** 페이지에서 정보를 검토하고 **업데이트**를 선택합니다.
잠시 후 `UPDATE_COMPLETE`가 표시됩니다.
## 튜토리얼: CloudFormation 및 파라미터 스토어를 사용하여 CloudWatch 에이전트 설치
이 튜토리얼에서는 CloudFormation을 사용하여 새 Amazon EC2 인스턴스에 CloudWatch 에이전트를 설치하는 과정을 안내합니다. 이 튜토리얼에서는 생성하여 파라미터 스토어에 저장한 에이전트 구성 파일을 사용해 Amazon Linux 2를 실행하는 새 인스턴스에 설치합니다.
에이전트를 설치하는 절차를 수행한 다음 자습서에서는 계속해서 에이전트를 업데이트하는 방법을 설명합니다.
**CloudFormation에서 파라미터 스토어의 구성을 사용해 새 인스턴스에 CloudWatch 에이전트를 설치하려면**
1. 아직 설치하지 않은 경우 에이전트 구성 파일을 생성할 수 있도록 컴퓨터 중 한 대에 CloudWatch 에이전트 패키지를 다운로드합니다. 파라미터 스토어를 사용하여 에이전트를 다운로드하는 방법에 대한 자세한 내용은 [CloudWatch 에이전트 패키지 다운로드](download-CloudWatch-Agent-on-EC2-Instance-commandline-first.md) 단원을 참조하세요.
1. 에이전트 구성 파일을 생성하여 파라미터 스토어에 저장합니다. 자세한 내용은 [CloudWatch 에이전트 구성 파일 생성](create-cloudwatch-agent-configuration-file.md) 단원을 참조하세요.
1. 다음과 같이 GitHub에서 템플릿을 다운로드합니다.
```
curl -O https://raw.githubusercontent.com/awslabs/aws-cloudformation-templates/master/aws/solutions/AmazonCloudWatchAgent/ssm/amazon_linux.template
```
1. CloudFormation 콘솔([https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/))을 엽니다.
1. **스택 생성**을 선택합니다.
1. **템플릿 선택**에서 **Amazon S3에 템플릿 업로드**를 선택하고, 다운로드한 템플릿을 선택한 후 **다음**을 선택합니다.
1. **세부 정보 지정** 페이지에 다음 파라미터를 입력하고 **다음**을 선택합니다.
+ **스택 이름**: CloudFormation 스택에 대한 스택 이름을 선택합니다.
+ **IAMRole**: CloudWatch 지표, 로그, 추적을 작성할 수 있는 권한이 있는 IAM 역할을 선택합니다. 자세한 내용은 [사전 조건](prerequisites.md) 섹션을 참조하세요.
+ **InstanceAMI**: 스택을 시작하려는 리전에서 유효한 AMI를 선택합니다.
+ **InstanceType**: 유효한 인스턴스 유형을 선택합니다.
+ **KeyName**: 새 인스턴스에 대한 SSH 액세스를 사용 설정하려면 기존 Amazon EC2 키 페어를 선택합니다. Amazon EC2 키 페어가 아직 없는 경우 AWS Management Console에서 새로 생성할 수 있습니다. 자세한 내용은 **Amazon EC2 사용 설명서의 [Amazon EC2 키 페어](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)를 참조하세요.
+ **SSHLocation**: SSH를 사용하여 인스턴스에 연결하는 데 사용할 수 있는 IP 주소 범위를 지정합니다. 기본값은 모든 IP 주소에서의 액세스를 허용합니다.
+ **SSMKey**: 생성하여 파라미터 스토어에 저장한 에이전트 구성 파일을 지정합니다.
1. **옵션** 페이지에서 스택 리소스에 태그를 지정할 수 있습니다. **다음**을 선택합니다.
1. [**검토(Review)**] 페이지에서 정보를 검토하고 스택이 IAM 리소스를 생성할 수 있음을 확인한 다음, [**생성(Create)**]을 선택합니다.
콘솔을 새로 고치면 새 스택에 `CREATE_IN_PROGRESS` 상태가 있음을 알 수 있습니다.
1. 인스턴스가 생성되면 Amazon EC2 콘솔에서 해당 인스턴스를 볼 수 있습니다. 필요한 경우 호스트에 연결해 진행 상황을 확인할 수 있습니다.
다음 명령을 사용하여 에이전트가 설치되었는지 확인합니다.
```
rpm -qa amazon-cloudwatch-agent
```
다음 명령을 사용하여 에이전트가 실행 중인지 확인합니다.
```
ps aux | grep amazon-cloudwatch-agent
```
다음 절차에서는 CloudFormation에서 파라미터 스토어에 저장한 에이전트 구성을 사용해 CloudWatch 에이전트를 업데이트하는 방법을 보여 줍니다.
**CloudFormation에서 파라미터 스토어의 구성을 사용해 CloudWatch 에이전트를 업데이트하려면**
1. 파라미터 스토어에 저장된 에이전트 구성 파일을 원하는 새 구성으로 변경합니다.
1. [튜토리얼: CloudFormation 및 파라미터 스토어를 사용하여 CloudWatch 에이전트 설치](#installing-CloudWatch-Agent-using-CloudFormation-Templates) 주제에서 다운로드한 CloudFormation 템플릿에서 버전 번호를 변경합니다. 예를 들어, `VERSION=1.0`을 `VERSION=2.0`으로 변경할 수 있습니다.
1. CloudFormation 콘솔([https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/))을 엽니다.
1. CloudFormation 대시보드에서 생성된 스택을 선택하고 **스택 업데이트**를 선택합니다.
1. **템플릿 선택**에서 **Amazon S3에 템플릿 업로드**를 선택하고, 방금 수정한 템플릿을 선택한 후 **다음**을 선택합니다.
1. **옵션** 페이지에서 **다음**을 선택한 후 **다음**을 선택합니다.
1. **검토** 페이지에서 정보를 검토하고 **업데이트**를 선택합니다.
잠시 후 `UPDATE_COMPLETE`가 표시됩니다.
## CloudFormation을 사용한 CloudWatch 에이전트 설치 문제 해결
이 단원에서는 CloudFormation을 사용한 CloudWatch 에이전트 설치 및 업데이트와 관련된 문제를 해결할 수 있도록 지원합니다.
### 업데이트 실패 시 감지
CloudFormation을 사용하여 CloudWatch 에이전트 구성을 업데이트하는데 잘못된 구성을 사용하는 경우 에이전트는 CloudWatch로의 지표 전송을 중지합니다. `cfn-init-cmd.log` 파일을 살펴보면 에이전트 구성 업데이트에 성공했는지 여부를 빠르게 확인할 수 있습니다. Linux 서버에서 이 파일은 `/var/log/cfn-init-cmd.log`에 있습니다. Windows 인스턴스에서 이 파일은 `C:\cfn\log\cfn-init-cmd.log`에 있습니다.
### 지표가 누락됨
에이전트를 설치 또는 업데이트한 후 원하는 지표가 표시되지 않는 경우 에이전트가 해당 지표를 수집하도록 구성되어 있는지 확인하세요. 이렇게 하려면 `amazon-cloudwatch-agent.json` 파일을 점검하여 해당 지표가 나열되어 있는지 확인하고 지금 살펴보고 있는 지표 네임스페이스가 올바른 네임스페이스인지를 확인하세요. 자세한 내용은 [CloudWatch 에이전트 파일 및 위치](troubleshooting-CloudWatch-Agent.md#CloudWatch-Agent-files-and-locations) 섹션을 참조하세요.
# Amazon CloudWatch Observability EKS 추가 기능 또는 헬름 차트를 사용하여 CloudWatch 에이전트 설치
Amazon CloudWatch Observability EKS 추가 기능 또는 Amazon CloudWatch Observability 차트 Helm을 사용하여 Amazon EKS 클러스터에 CloudWatch 에이전트와 Fluent-Bit 에이전트를 설치할 수 있습니다. 또한 차트 Helm을 사용하여 Amazon EKS에서 호스팅되지 않은 Kubernetes 클러스터에 CloudWatch 에이전트와 Fluent-bit 에이전트를 설치할 수 있습니다.
Amazon EKS 클러스터에서 두 방법 중 하나를 사용하면 기본적으로 Amazon EKS와 [CloudWatch Application Signals](CloudWatch-Application-Monitoring-Sections.md)에 대한 향상된 관찰성을 갖춘 [Container Insights](ContainerInsights.md)가 모두 활성화됩니다. 두 기능 모두 클러스터에서 인프라 지표, 애플리케이션 성능 텔레메트리 및 컨테이너 로그를 수집하는 데 도움이 됩니다.
버전 `v6.0.1-eksbuild.1` 이상의 추가 기능을 사용하면 OTLP(OpenTelemetry Protocol)를 사용하여 지표를 수집하고 PromQL 쿼리를 지원하는 OpenTelemetry 지표가 포함된 Container Insights가 활성화됩니다. 자세한 내용은 [Amazon EKS의 OpenTelemetry 지표가 포함된 Container Insights](container-insights-otel-metrics.md) 섹션을 참조하세요.
Amazon EKS의 향상된 관찰 기능을 갖춘 Container Insights를 사용하면 Container Insights 지표는 저장된 지표나 수집된 로그별로 요금이 부과되는 대신 관찰당 요금이 부과됩니다. Application Signals의 경우 결제는 애플리케이션에 대한 인바운드 요청, 애플리케이션의 아웃바운드 요청, 구성된 각 서비스 수준 목표(SLO)를 기준으로 합니다. 수신된 각 인바운드 요청은 하나의 애플리케이션 신호를 생성하고, 각 아웃바운드 요청은 하나의 애플리케이션 신호를 생성합니다. 모든 SLO는 측정 기간당 두 개의 애플리케이션 신호를 생성합니다. CloudWatch 요금에 대한 자세한 내용은 [Amazon CloudWatch 요금](https://aws.amazon.com/cloudwatch/pricing/)을 참조하세요.
두 방법 다 Amazon EKS 클러스터의 Linux 및 Windows 워커 노드 모두에서 Container Insights를 활성화합니다. Windows에서 Container Insights를 활성화하려면 Amazon EKS 추가 기능 버전 1.5.0 이상 또는 차트 Helm을 사용해야 합니다. Windows에서는 Amazon EKS 클러스터에서 Application Signals가 지원되지 않습니다.
Amazon CloudWatch Observability EKS 추가 기능은 Kubernetes 버전 1.23 이상을 실행하는 Amazon EKS 클러스터에서 지원됩니다.
추가 기능 또는 차트 Helm을 설치할 때 CloudWatch 에이전트가 지표, 로그 및 트레이스를 CloudWatch에 전송할 수 있도록 IAM 권한을 부여해야 합니다. 이렇게 하는 방법은 두 가지입니다.
+ 작업자 노드의 IAM 역할에 정책을 연결합니다. 이 옵션은 워커 노드에 CloudWatch로 원격 측정을 전송할 수 있는 권한을 부여합니다.
+ 에이전트 포드에 대해 서비스 계정의 IAM 역할을 사용하고 이 역할에 정책을 연결합니다. 이는 Amazon EKS 클러스터에만 적용됩니다. 이 옵션을 사용하면 CloudWatch가 해당 에이전트 포드에만 액세스할 수 있습니다.
**Topics**
+ [옵션 1: EKS Pod Identity를 사용하여 설치](#install-CloudWatch-Observability-EKS-pod-identity)
+ [옵션 2: 워커 노드에 IAM 권한으로 설치](#install-CloudWatch-Observability-EKS-addon-workernodes)
+ [옵션 3: IAM 서비스 계정 역할을 사용하여 설치(추가 기능을 사용하는 경우에만 해당)](#install-CloudWatch-Observability-EKS-addon-serviceaccountrole)
+ [Amazon EKS Hybrid Nodes의 고려 사항](#install-CloudWatch-Observability-EKS-addon-hybrid)
+ [(선택 사항) 추가 구성](#install-CloudWatch-Observability-EKS-addon-configuration)
+ [Java Management Extensions(JMX) 지표 수집](#install-CloudWatch-Observability-EKS-addon-JMX-metrics)
+ [Kueue 지표 활성화](#enable-Kueue-metrics)
+ [OpenTelemetry 수집기 구성 파일 추가](#install-CloudWatch-Observability-EKS-addon-OpenTelemetry)
+ [Amazon EKS 클러스터의 Application Signals를 통해 APM 활성화](#Container-Insights-setup-EKS-appsignalsconfiguration)
+ [Amazon CloudWatch Observability EKS 추가 기능 또는 차트 Helm 문제 해결](#Container-Insights-setup-EKS-addon-troubleshoot)
+ [Application Signals 옵트아웃](#Opting-out-App-Signals)
## 옵션 1: EKS Pod Identity를 사용하여 설치
추가 기능의 버전 3.1.0 이상을 사용하는 경우 EKS Pod Identity를 사용하여 추가 기능에 필요한 권한을 부여할 수 있습니다. EKS Pod Identity는 권장 옵션이며 최소 권한, 자격 증명 교체 및 감사 가능성과 같은 이점을 제공합니다. 또한 EKS Pod Identity를 사용하면 클러스터 생성 중에 EKS 추가 기능을 설치할 수 있습니다.
이 방법을 사용하려면 먼저 [EKS Pod Identity 연결](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-association.html#pod-id-association-create/) 단계에 따라 IAM 역할을 생성하고 EKS Pod Identity 에이전트를 설정합니다.
그런 다음 Amazon CloudWatch Observability EKS 추가 기능을 사용하여 설치합니다. 추가 기능을 설치하기 위해 AWS CLI, Amazon EKS 콘솔, CloudFormation 또는 Terraform을 사용할 수 있습니다.
------
#### [ AWS CLI ]
**AWS CLI를 사용하여 Amazon CloudWatch Observability EKS 추가 기능 설치**
다음 명령을 입력합니다. `my-cluster-name`을 실제 클러스터 이름으로 바꾸고 *111122223333*을 계정 ID로 바꿉니다. *my-role*을 EKS Pod Identity 연결 단계에서 생성한 IAM 역할로 바꾸세요.
```
aws iam attach-role-policy \
--role-name my-role \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
aws eks create-addon \
--addon-name amazon-cloudwatch-observability \
--cluster-name my-cluster-name \
--pod-identity-associations serviceAccount=cloudwatch-agent,roleArn=arn:aws:iam::111122223333:role/my-role
```
------
#### [ Amazon EKS console ]
**Amazon EKS 콘솔을 사용하여 Amazon CloudWatch Observability EKS 추가 기능 설치**
1. [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters)에서 Amazon EKS 콘솔을 엽니다.
1. 좌측 탐색 창에서 **클러스터**를 선택합니다.
1. Amazon CloudWatch Observabiilty EKS 추가 기능을 구성할 클러스터의 이름을 선택합니다.
1. **추가 기능** 탭을 선택합니다.
1. **추가 기능 더 가져오기**를 선택합니다.
1. **추가 기능 선택** 페이지에서 다음을 수행합니다.
1. **Amazon EKS 추가 기능** 섹션에서 **Amazon CloudWatch Observability** 확인란을 선택합니다.
1. **다음**을 선택합니다.
1. **선택한 추가 기능 설정 구성** 페이지에서 다음을 수행합니다.
1. 사용할 **버전(Version)**을 선택합니다.
1. **추가 기능 액세스**에서 **EKS Pod Identity**를 선택하세요.
1. IAM 역할이 구성되지 않은 경우 **권장 역할 생성**을 선택한 다음 **3단계 이름, 검토 및 생성**에 도달할 때까지 **다음**을 선택하세요. 원하는 경우 역할 이름을 변경할 수 있습니다. 그렇지 않으면 **역할 생성**을 선택하고 추가 기능 페이지로 돌아가서 방금 생성한 IAM 역할을 선택하세요.
1. (선택 사항) **선택적 구성 설정**을 확장할 수 있습니다. **충돌 해결 방법**에서 **재정의**를 선택한 경우 기존 추가 기능에 대한 하나 이상의 설정을 Amazon EKS 추가 기능의 설정으로 덮어쓸 수 있습니다. 이 옵션을 사용 설정하지 않고 기존 설정과 충돌이 있는 경우 작업이 실패합니다. 결과 오류 메시지를 사용하여 충돌을 해결할 수 있습니다. 이 옵션을 선택하기 전에 Amazon EKS 추가 기능이 사용자가 자체 관리해야 하는 설정을 관리하지 않는지 확인하세요.
1. **다음**을 선택합니다.
1. **검토 및 추가** 페이지에서 **생성**을 선택합니다. 추가 기능 설치가 완료되면 설치한 추가 기능이 표시됩니다.
------
#### [ CloudFormation ]
**CloudFormation을 사용하여 Amazon CloudWatch Observability EKS 추가 기능 설치**
1. 먼저 다음 AWS CLI 명령을 실행하여 IAM 역할에 필요한 IAM 정책을 연결하세요. *my-role*을 EKS Pod Identity 연결 단계에서 생성한 역할로 바꾸세요.
```
aws iam attach-role-policy \
--role-name my-role \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
```
1. 그리고 다음 리소스를 생성하세요. `my-cluster-name`을 클러스터 이름으로 바꾸고 *111122223333*을 계정 ID로 바꾸며, *my-role*을 EKS Pod Identity 연결 단계에서 생성된 IAM 역할로 바꾸세요. 자세한 내용은 [ AWS::EKS::Addon](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-eks-addon.html)을 참조하세요.
```
{
"Resources": {
"EKSAddOn": {
"Type": "AWS::EKS::Addon",
"Properties": {
"AddonName": "amazon-cloudwatch-observability",
"ClusterName": "my-cluster-name",
"PodIdentityAssociations": [
{
"ServiceAccount": "cloudwatch-agent",
"RoleArn": "arn:aws:iam::111122223333:role/my-role"
}
]
}
}
}
}
```
------
#### [ Terraform ]
**Terraform을 사용하여 Amazon CloudWatch Observability EKS 추가 기능 설치**
1. 다음을 사용하세요. `my-cluster-name`을 클러스터 이름으로 바꾸고 *111122223333*을 계정 ID로 바꾸며, *my-service-account-role*을 EKS Pod Identity 연결 단계에서 생성된 IAM 역할로 바꾸세요.
자세한 내용은 Terraform 설명서의 [Resource: aws\$1eks\$1addon](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/eks_addon)을 참조하세요.
1.
```
resource "aws_iam_role_policy_attachment" "CloudWatchAgentServerPolicy" {
policy_arn = "arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy"
role = "my-role"
}
resource "aws_eks_addon" "example" {
cluster_name = "my-cluster-name"
addon_name = "amazon-cloudwatch-observability"
pod_identity_associations {
roleArn = "arn:aws:iam::111122223333:role/my-role"
serviceAccount = "cloudwatch-agent"
}
}
```
------
## 옵션 2: 워커 노드에 IAM 권한으로 설치
이 방법을 사용하려면 먼저 다음 명령을 입력하여 **CloudWatchAgentServerPolicy** IAM 정책을 워커 노드에 연결합니다. 이 명령에서는 *my-worker-node-role*을 Kubernetes 워커 노드에서 사용하는 IAM 역할로 대체합니다.
```
aws iam attach-role-policy \
--role-name my-worker-node-role \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
```
그런 다음 Amazon CloudWatch Observability EKS 추가 기능을 사용하여 설치합니다. 추가 기능을 설치하려면 AWS CLI, 콘솔, CloudFormation 또는 Terraform을 사용할 수 있습니다.
------
#### [ AWS CLI ]
**AWS CLI를 사용하여 Amazon CloudWatch Observability EKS 추가 기능 설치**
다음 명령을 입력합니다. `my-cluster-name`를 클러스터 이름으로 바꿉니다.
```
aws eks create-addon --addon-name amazon-cloudwatch-observability --cluster-name my-cluster-name
```
------
#### [ Amazon EKS console ]
**Amazon EKS 콘솔을 사용하여 Amazon CloudWatch Observability EKS 추가 기능 설치**
1. [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters)에서 Amazon EKS 콘솔을 엽니다.
1. 좌측 탐색 창에서 **클러스터**를 선택합니다.
1. Amazon CloudWatch Observabiilty EKS 추가 기능을 구성할 클러스터의 이름을 선택합니다.
1. **추가 기능** 탭을 선택합니다.
1. **추가 기능 더 가져오기**를 선택합니다.
1. **추가 기능 선택** 페이지에서 다음을 수행합니다.
1. **Amazon EKS 추가 기능** 섹션에서 **Amazon CloudWatch Observability** 확인란을 선택합니다.
1. **다음**을 선택합니다.
1. **선택한 추가 기능 설정 구성** 페이지에서 다음을 수행합니다.
1. 사용할 **버전(Version)**을 선택합니다.
1. (선택 사항) **선택적 구성 설정**을 확장할 수 있습니다. **충돌 해결 방법**에서 **재정의**를 선택한 경우 기존 추가 기능에 대한 하나 이상의 설정을 Amazon EKS 추가 기능의 설정으로 덮어쓸 수 있습니다. 이 옵션을 사용 설정하지 않고 기존 설정과 충돌이 있는 경우 작업이 실패합니다. 결과 오류 메시지를 사용하여 충돌을 해결할 수 있습니다. 이 옵션을 선택하기 전에 Amazon EKS 추가 기능이 사용자가 자체 관리해야 하는 설정을 관리하지 않는지 확인하세요.
1. **다음**을 선택합니다.
1. **검토 및 추가** 페이지에서 **생성**을 선택합니다. 추가 기능 설치가 완료되면 설치한 추가 기능이 표시됩니다.
------
#### [ CloudFormation ]
**CloudFormation을 사용하여 Amazon CloudWatch Observability EKS 추가 기능 설치**
`my-cluster-name`를 클러스터 이름으로 바꿉니다. 자세한 내용은 [ AWS::EKS::Addon](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-eks-addon.html)을 참조하세요.
```
{
"Resources": {
"EKSAddOn": {
"Type": "AWS::EKS::Addon",
"Properties": {
"AddonName": "amazon-cloudwatch-observability",
"ClusterName": "my-cluster-name"
}
}
}
}
```
------
#### [ Helm chart ]
**`amazon-cloudwatch-observability` 차트 Helm을 사용하려면 다음을 수행하세요.**
1. 이 차트를 사용하려면 Helm이 설치되어 있어야 합니다. Helm 설치에 대한 자세한 내용은 [Helm 설명서](https://helm.sh/docs/)를 참조하세요.
1. Helm을 설치한 후 다음 명령을 입력합니다. *my-cluster-name*을 클러스터 이름으로 바꾸고, *my-cluster-region*을 클러스터가 실행되는 리전으로 바꿉니다.
```
helm repo add aws-observability https://aws-observability.github.io/helm-charts
helm repo update aws-observability
helm install --wait --create-namespace --namespace amazon-cloudwatch amazon-cloudwatch-observability aws-observability/amazon-cloudwatch-observability --set clusterName=my-cluster-name --set region=my-cluster-region
```
------
#### [ Terraform ]
**Terraform을 사용하여 Amazon CloudWatch Observability EKS 추가 기능 설치**
`my-cluster-name`를 클러스터 이름으로 바꿉니다. 자세한 내용은 [리소스: aws\$1eks\$1addon](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/eks_ad)를 참조하세요.
```
resource "aws_eks_addon" "example" {
addon_name = "amazon-cloudwatch-observability"
cluster_name = "my-cluster-name"
}
```
------
## 옵션 3: IAM 서비스 계정 역할을 사용하여 설치(추가 기능을 사용하는 경우에만 해당)
이 방법은 Amazon CloudWatch 관찰성 EKS 추가 기능을 사용하는 경우에만 유효합니다. 이 방법을 사용하기 전에 다음과 같은 사전 요구 사항을 확인하세요.
+ Container Insights를 지원하는 AWS 리전 중 하나에 노드가 연결되어 있는 Amazon EKS 클러스터터가 작동 중입니다. 지원되는 리전 목록은 [Container Insights](ContainerInsights.md) 단원을 참조하세요.
+ 클러스터에 대해 `kubectl`가 설치 및 구성되어 있습니다. 자세한 내용은 *Amazon EKS 사용 설명서*의 [`kubectl` 설치](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)를 참조하세요.
+ `eksctl`이 설치되어 있습니다. 자세한 내용은 *Amazon EKS 사용 설명서*의 [`eksctl`설치 또는 업데이트](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html) 섹션을 참조하세요.
------
#### [ AWS CLI ]
**AWS CLI를 통해 IAM 서비스 계정 역할을 사용하여 Amazon CloudWatch Observability EKS 추가 기능을 설치하는 방법**
1. 클러스터에 아직 OpenID Connect(OIDC) 공급자가 없는 경우 다음 명령을 입력하여 해당 공급자를 생성합니다. 자세한 내용은 *Amazon EKS 사용 설명서*의 [IAM 역할을 가정하는 Kubernetes 서비스 계정 구성](https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html)을 참조하세요.
```
eksctl utils associate-iam-oidc-provider --cluster my-cluster-name --approve
```
1. 다음 명령을 입력하여 **CloudWatchAgentServerPolicy** 정책이 연결된 IAM 역할을 생성하고 OIDC를 사용하여 해당 역할을 수임하도록 에이전트 서비스 계정을 구성합니다. *my-cluster-name*을 클러스터 이름으로, *my-service-account-role*을 서비스 계정을 연결할 역할의 이름으로 바꿉니다. 역할이 아직 없는 경우 `eksctl`이 자동으로 생성합니다.
```
eksctl create iamserviceaccount \
--name cloudwatch-agent \
--namespace amazon-cloudwatch --cluster my-cluster-name \
--role-name my-service-account-role \
--attach-policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy \
--role-only \
--approve
```
1. 다음 명령을 입력하여 추가 기능을 설치합니다. *my-cluster-name*을 클러스터 이름으로, *111122223333*을 계정 ID로, *my-service-account-role*을 이전 단계에서 생성한 IAM 역할로 바꿉니다.
```
aws eks create-addon --addon-name amazon-cloudwatch-observability --cluster-name my-cluster-name --service-account-role-arn arn:aws:iam::111122223333:role/my-service-account-role
```
------
#### [ Amazon EKS console ]
**콘솔을 통해 IAM 서비스 계정 역할을 사용하여 Amazon CloudWatch Observability EKS 추가 기능을 설치하는 방법**
1. [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters)에서 Amazon EKS 콘솔을 엽니다.
1. 좌측 탐색 창에서 **클러스터**를 선택합니다.
1. Amazon CloudWatch Observabiilty EKS 추가 기능을 구성할 클러스터의 이름을 선택합니다.
1. **추가 기능** 탭을 선택합니다.
1. **추가 기능 더 가져오기**를 선택합니다.
1. **추가 기능 선택** 페이지에서 다음을 수행합니다.
1. **Amazon EKS 추가 기능** 섹션에서 **Amazon CloudWatch Observability** 확인란을 선택합니다.
1. **다음**을 선택합니다.
1. **선택한 추가 기능 설정 구성** 페이지에서 다음을 수행합니다.
1. 사용할 **버전(Version)**을 선택합니다.
1. **추가 기능 액세스**에서 **서비스 계정의 IAM 역할(IRSA)**을 선택하세요.
1. **추가 기능 액세스** 상자에서 IAM 역할을 선택하세요.
1. (선택 사항) **선택적 구성 설정**을 확장할 수 있습니다. **충돌 해결 방법**에서 **재정의**를 선택한 경우 기존 추가 기능에 대한 하나 이상의 설정을 Amazon EKS 추가 기능의 설정으로 덮어쓸 수 있습니다. 이 옵션을 사용 설정하지 않고 기존 설정과 충돌이 있는 경우 작업이 실패합니다. 결과 오류 메시지를 사용하여 충돌을 해결할 수 있습니다. 이 옵션을 선택하기 전에 Amazon EKS 추가 기능이 사용자가 자체 관리해야 하는 설정을 관리하지 않는지 확인하세요.
1. **다음**을 선택합니다.
1. **검토 및 추가** 페이지에서 **생성**을 선택합니다. 추가 기능 설치가 완료되면 설치한 추가 기능이 표시됩니다.
------
## Amazon EKS Hybrid Nodes의 고려 사항
[Container Insights](ContainerInsights.md)는 노드 수준 지표에 대한 [EC2 인스턴스 메타데이터 서비스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html)(IMDS)의 가용성에 좌우되기 때문에 노드 수준 지표는 하이브리드 노드에 사용할 수 없습니다. 클러스터, 워크로드, Pod, 컨테이너 수준 지표는 하이브리드 노드에 사용할 수 있습니다.
이전 섹션의 단계에 따라 추가 기능을 설치한 후에는 에이전트가 하이브리드 노드에서 성공적으로 실행될 수 있도록 추가 기능 매니페스트를 업데이트해야 합니다. 클러스터의 `amazoncloudwatchagents` 리소스를 편집하여 다음과 일치하는 `RUN_WITH_IRSA` 환경 변수를 추가합니다.
```
kubectl edit amazoncloudwatchagents -n amazon-cloudwatch cloudwatch-agent
```
```
apiVersion: v1
items:
- apiVersion: cloudwatch.aws.amazon.com/v1alpha1
kind: AmazonCloudWatchAgent
metadata:
...
name: cloudwatch-agent
namespace: amazon-cloudwatch
...
spec:
...
env:
- name: RUN_WITH_IRSA # <-- Add this
value: "True" # <-- Add this
- name: K8S_NODE_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
...
```
## (선택 사항) 추가 구성
**Topics**
+ [컨테이너 로그 수집 옵트아웃](#CloudWatch-Observability-EKS-addon-OptOutContainerLogs)
+ [사용자 지정 Fluent Bit 구성 사용](#CloudWatch-Observability-EKS-addon-CustomFluentBit)
+ [설치된 포드 워크로드에 대한 Kubernetes 톨러레이션을 관리합니다.](#CloudWatch-Observability-EKS-addon-Tolerations)
+ [가속 컴퓨팅 지표 수집 옵트아웃](#CloudWatch-Observability-EKS-addon-OptOutAccelerated)
+ [사용자 지정 CloudWatch 에이전트 구성 사용](#CloudWatch-Observability-EKS-addon-CustomAgentConfig)
+ [승인 웹후크 TLS 인증서 관리](#CloudWatch-Observability-EKS-addon-Webhook)
+ [Amazon EBS 볼륨 ID 수집](#CloudWatch-Observability-EKS-addon-VolumeIDs)
### 컨테이너 로그 수집 옵트아웃
기본적으로 추가 기능은 Fluent Bit를 사용하여 모든 포드에서 컨테이너 로그를 수집한 다음 로그를 CloudWatch Logs로 보냅니다. 수집되는 로그에 대한 자세한 내용은 [Fluent Bit 설정](Container-Insights-setup-logs-FluentBit.md#Container-Insights-FluentBit-setup)을 참조하세요.
**참고**
추가 기능과 차트 Helm 모두 클러스터의 기존 Fluentd 또는 Fluent Bit 리소스를 관리하지 않습니다. 추가 기능 또는 차트 Helm을 설치하기 전에 기존 Fluentd 또는 Fluent Bit 리소스를 삭제할 수 있습니다. 또는 기존 설정을 유지하고 추가 기능이나 차트 Helm이 Fluent Bit를 설치하지 않도록 하려면 이 섹션의 지침에 따라 이를 비활성화할 수 있습니다.
Amazon CloudWatch Observability EKS 추가 기능을 사용하는 경우 컨테이너 로그 수집을 옵트아웃하려면 추가 기능을 생성하거나 업데이트할 때 다음 옵션을 전달하세요.
```
--configuration-values '{ "containerLogs": { "enabled": false } }'
```
차트 Helm을 사용하는 경우 컨테이너 로그 수집을 옵트아웃하려면 추가 기능을 생성하거나 업데이트할 때 다음 옵션을 전달하세요.
```
--set containerLogs.enabled=false
```
### 사용자 지정 Fluent Bit 구성 사용
Amazon CloudWatch Observability EKS 추가 기능 버전 1.7.0부터 추가 기능 또는 차트 Helm을 생성하거나 업데이트할 때 Fluent Bit 구성을 수정할 수 있습니다. 차트 Helm의 값 재정의 또는 추가 기능 고급 구성의 `containerLogs` 루트 수준 섹션에서 지정 정의 Fluent Bit 구성을 제공합니다. 이 섹션에서는 `config` 섹션(Linux의 경우) 또는 `configWindows` 섹션(Windows의 경우)에서 사용자 지정 Fluent Bit 구성을 제공합니다. `config`는 다음과 같은 하위 섹션으로 더 세분화됩니다.
+ `service` - 이 섹션은 Fluent Bit 엔진의 글로벌 동작을 정의하는 `SERVICE` 구성을 나타냅니다.
+ `customParsers` – 이 섹션은 비정형 로그 항목을 가져와 처리 및 추가 필터링을 쉽게 할 수 있도록 구조를 부여할 수 있는 포함할 글로벌 `PARSER`를 나타냅니다.
+ `extraFiles` – 이 섹션은 포함할 추가 Fluent Bit `conf` 파일을 제공하는 데 사용할 수 있습니다. 기본적으로 다음 3개의 `conf` 파일이 포함됩니다.
+ `application-log.conf` - CloudWatch Logs의 로그 그룹 `/aws/containerinsights/my-cluster-name/application`으로 클러스터의 애플리케이션 로그를 전송하기 위한 `conf` 파일입니다.
+ `dataplane-log.conf` - CloudWatch Logs의 로그 그룹 `/aws/containerinsights/my-cluster-name/dataplane`으로 클러스터의 데이터 영역 구성 요소에 해당하는 로그(CRI 로그, kubelet 로그, kube-proxy 로그 및 Amazon VPC CNI 로그 포함)를 전송하기 위한 `conf` 파일입니다.
+ `host-log.conf` - Linux의 `/var/log/dmesg`, `/var/log/messages`, `/var/log/secure`와 Windows의 시스템 `winlogs`에서 CloudWatch의 로그 그룹 `/aws/containerinsights/my-cluster-name/host`로 로그를 전송하기 위한 `conf`입니다.
**참고**
하위 섹션 내에서 한 필드만 수정하는 경우에도 이러한 개별 섹션 각각에 대한 전체 구성을 제공하세요. 아래에 제공된 기본 구성을 기준으로 사용한 다음 기본적으로 활성화되어 있는 기능을 비활성화하지 않도록 적절하게 수정하는 것이 좋습니다. Amazon EKS 추가 기능의 고급 구성을 수정하거나 차트 Helm에 대한 값 재정의를 제공할 때 다음 YAML 구성을 사용할 수 있습니다.
클러스터의 `config` 섹션을 찾으려면 GitHub의 [aws-observability / helm-charts](https://github.com/aws-observability/helm-charts/releases)를 참조하여 설치 중인 추가 기능 또는 차트 Helm 버전에 해당하는 릴리스를 찾으세요. 그런 다음 `/charts/amazon-cloudwatch-observability/values.yaml`로 이동하여 `containerLogs` 아래의 `fluentBit` 섹션 내에서 `config` 섹션(Linux의 경우)과 `configWindows` 섹션(Windows의 경우)을 찾으세요.
예를 들어 버전 1.7.0의 기본 Fluent Bit 구성은 [여기](https://github.com/aws-observability/helm-charts/blob/v1.7.0/charts/amazon-cloudwatch-observability/values.yaml#L44))에서 찾을 수 있습니다.
Amazon EKS 추가 기능의 고급 구성을 사용하여 제공하거나 Helm 설치에 대한 값 재정의로 제공할 때 `config`를 YAML로 제공하는 것이 좋습니다. YAML이 다음 구조를 준수하는지 확인하세요.
```
containerLogs:
fluentBit:
config:
service: |
...
customParsers: |
...
extraFiles:
application-log.conf: |
...
dataplane-log.conf: |
...
host-log.conf: |
...
```
다음 예제 `config`에서는 비우기 간격의 글로벌 설정을 45초로 변경합니다. `Flush` 필드만 수정하더라도 서비스 하위 섹션에 대한 전체 `SERVICE` 정의를 제공해야 합니다. 이 예제에서는 다른 하위 섹션에 대한 재정의를 지정하지 않았으므로 기본값이 사용됩니다.
```
containerLogs:
fluentBit:
config:
service: |
[SERVICE]
Flush 45
Grace 30
Log_Level error
Daemon off
Parsers_File parsers.conf
storage.path /var/fluent-bit/state/flb-storage/
storage.sync normal
storage.checksum off
storage.backlog.mem_limit 5M
```
다음 예제 구성에는 추가 Fluent bit `conf` 파일이 포함되어 있습니다. 이 예제에서는 `extraFiles` 아래에 사용자 지정 `my-service.conf`를 추가하고 있으며 이 구성은 세 가지 기본 `extraFiles`에 추가로 포함됩니다.
```
containerLogs:
fluentBit:
config:
extraFiles:
my-service.conf: |
[INPUT]
Name tail
Tag myservice.*
Path /var/log/containers/*myservice*.log
DB /var/fluent-bit/state/flb_myservice.db
Mem_Buf_Limit 5MB
Skip_Long_Lines On
Ignore_Older 1d
Refresh_Interval 10
[OUTPUT]
Name cloudwatch_logs
Match myservice.*
region ${AWS_REGION}
log_group_name /aws/containerinsights/${CLUSTER_NAME}/myservice
log_stream_prefix ${HOST_NAME}-
auto_create_group true
```
다음 예제에서는 `extraFiles`에서 기존 `conf` 파일을 완전히 제거합니다. 이는 빈 문자열로 재정의하여 `application-log.conf`를 완전히 제외합니다. `extraFiles`에서 `application-log.conf`를 생략하면 기본값을 사용한다는 의미이지만, 이 예제에서 기본값을 사용하려고 하는 것은 아닙니다. 이전에 `extraFiles`에 추가했을 수 있는 사용자 지정 `conf` 파일을 제거하는 경우에도 마찬가지입니다.
```
containerLogs:
fluentBit:
config:
extraFiles:
application-log.conf: ""
```
### 설치된 포드 워크로드에 대한 Kubernetes 톨러레이션을 관리합니다.
Amazon CloudWatch Observability EKS 추가 기능 버전 1.7.0부터 추가 기능이나 차트 Helm은 이에 의해 설치된 포드 워크로드의 모든 테인트를 허용하도록 Kubernetes **톨러레이션을 기본 설정합니다. 이렇게 하면 CloudWatch 에이전트 및 Fluent Bit와 같은 DaemonSet가 기본적으로 클러스터의 모든 노드에서 포드를 예약할 수 있습니다. 톨러레이션과 테인트에 대한 자세한 내용은 Kubernetes 문서의 [테인트(Taints)와 톨러레이션(Tolerations)](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)을 참조하세요.
추가 기능 또는 차트 Helm에서 설정하는 기본 톨러레이션은 다음과 같습니다.
```
tolerations:
- operator: Exists
```
추가 기능 고급 구성을 사용하거나 값 재정의로 차트 Helm을 설치하거나 업그레이드할 때 루트 수준에서 `tolerations` 필드를 설정하여 기본 톨러레이션을 재정의할 수 있습니다. 예제는 다음과 같습니다.
```
tolerations:
- key: "key1"
operator: "Exists"
effect: "NoSchedule"
```
톨러레이션을 완전히 생략하려면 다음과 같은 구성을 사용할 수 있습니다.
```
tolerations: []
```
톨러레이션에 대한 모든 변경 사항은 추가 기능 또는 차트 Helm에 의해 설치되는 모든 포드 워크로드에 적용됩니다.
### 가속 컴퓨팅 지표 수집 옵트아웃
기본적으로 고급 관찰성을 갖춘 Container Insights는 NVIDIA GPU 지표, AWS Trainium 및 AWS Inferentia에 대한 AWS Neuron 지표, AWS Elastic Fabric Adapter(EFA) 지표를 포함하여 가속 컴퓨팅 모니터링을 위한 지표를 수집합니다.
Amazon EKS 워크로드의 NVIDIA GPU 지표는 EKS 추가 기능 또는 차트 Helm 버전 `v1.3.0-eksbuild.1`과 CloudWatch 에이전트 버전 `1.300034.0`부터 기본적으로 수집됩니다. 수집되는 지표 목록과 전제 조건은 [NVIDIA GPU 지표](Container-Insights-metrics-enhanced-EKS.md#Container-Insights-metrics-EKS-GPU) 섹션을 참조하세요.
AWS Trainium 및 AWS Inferentia 액셀러레이터에 대한 AWS Neuron 지표는 EKS 추가 기능 또는 차트 Helm 버전 `v1.5.0-eksbuild.1`과 CloudWatch 에이전트 버전 `1.300036.0`부터 기본적으로 수집됩니다. 수집되는 지표 목록과 전제 조건은 [AWS Trainium 및 AWS Inferentia의 AWS Neuron 지표](Container-Insights-metrics-enhanced-EKS.md#Container-Insights-metrics-EKS-Neuron) 섹션을 참조하세요.
Amazon EKS 클러스터의 Linux 노드의 AWS Elastic Fabric Adapter(EFA) 지표는 기본적으로 EKS 추가 기능 또는 차트 Helm 버전 `v1.5.2-eksbuild.1`과 CloudWatch 에이전트 버전 `1.300037.0`부터 수집됩니다. 수집되는 지표 목록과 전제 조건은 [AWS Elastic Fabric Adapter(EFA) 지표](Container-Insights-metrics-enhanced-EKS.md#Container-Insights-metrics-EFA) 섹션을 참조하세요.
CloudWatch 에이전트 구성 파일의 `accelerated_compute_metrics` 필드를 `false`로 설정하여 이러한 지표 수집을 옵트아웃할 수 있습니다. 이 필드는 CloudWatch 구성 파일의 `metrics_collected` 섹션의 `kubernetes` 섹션에 있습니다. 다음은 옵트아웃 구성의 예입니다. 사용자 지정 CloudWatch 에이전트 구성을 사용하는 방법에 대한 자세한 내용은 [사용자 지정 CloudWatch 에이전트 구성 사용](#CloudWatch-Observability-EKS-addon-CustomAgentConfig) 섹션을 참조하세요.
```
{
"logs": {
"metrics_collected": {
"kubernetes": {
"enhanced_container_insights": true,
"accelerated_compute_metrics": false
}
}
}
}
```
### 사용자 지정 CloudWatch 에이전트 구성 사용
CloudWatch 에이전트를 사용하여 다른 지표, 로그 또는 트레이스를 수집하려면 Container Insights와 CloudWatch Application Signals를 활성화한 상태로 유지하면서 사용자 지정 구성을 지정할 수 있습니다. 이렇게 하려면 EKS 추가 기능 또는 차트 Helm을 생성하거나 업데이트할 때 사용할 수 있는 고급 구성의 에이전트 키 아래에 있는 구성 키 내에 CloudWatch 에이전트 구성 파일을 포함합니다. 다음은 추가 구성을 제공하지 않은 경우의 기본 에이전트 구성을 나타냅니다.
**중요**
추가 구성 설정을 사용하여 제공하는 모든 사용자 지정 구성은 에이전트가 사용하는 기본 구성보다 우선합니다. 향상된 관찰성을 갖춘 Container Insights 및 CloudWatch Application Signals와 같이 기본적으로 활성화되는 기능을 실수로 비활성화하지 않도록 주의합니다. 사용자 지정 에이전트 구성을 제공해야 하는 시나리오에서는 다음 기본 구성을 기준으로 사용하고 그에 따라 수정하는 것이 좋습니다.
+ Amazon CloudWatch Observability EKS 추가 기능을 사용하는 경우
```
--configuration-values '{
"agent": {
"config": {
"logs": {
"metrics_collected": {
"application_signals": {},
"kubernetes": {
"enhanced_container_insights": true
}
}
},
"traces": {
"traces_collected": {
"application_signals": {}
}
}
}
}
}'
```
+ 차트 Helm을 사용하는 경우
```
--set agent.config='{
"logs": {
"metrics_collected": {
"application_signals": {},
"kubernetes": {
"enhanced_container_insights": true
}
}
},
"traces": {
"traces_collected": {
"application_signals": {}
}
}
}'
```
다음 예시는 Windows의 CloudWatch 에이전트에 대한 기본 에이전트 구성을 보여줍니다. Windows의 CloudWatch 에이전트는 사용자 지정 구성을 지원하지 않습니다.
```
{
"logs": {
"metrics_collected": {
"kubernetes": {
"enhanced_container_insights": true
},
}
}
}
```
### 승인 웹후크 TLS 인증서 관리
Amazon CloudWatch Observability EKS 추가 기능과 차트 Helm은 Kubernetes [승인 웹후크](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/)를 활용하여 `AmazonCloudWatchAgent` 및 `Instrumentation` 사용자 지정 리소스(CR) 요청과 클러스터에 대한 Kubernetes 포드 요청(CloudWatch Application Signals가 활성화된 경우)을 검증하고 변경합니다. Kubernetes에서 웹후크에는 보안 통신을 보장하기 위해 API 서버가 신뢰할 수 있도록 구성된 TLS 인증서가 필요합니다.
기본적으로 Amazon CloudWatch Observability EKS 추가 기능과 차트 Helm은 API 서버와 웹후크 서버 간의 통신을 보호하기 위해 자체 서명된 CA와 이 CA에서 서명한 TLS 인증서를 자동으로 생성합니다. 이 자동 생성된 인증서의 기본 만료 기한은 10년이며 만료 시 자동 갱신되지 않습니다. 또한 추가 기능 또는 차트 Helm을 업그레이드하거나 다시 설치할 때마다 CA 번들과 인증서가 다시 생성되므로 만료 기한이 재설정됩니다. 자동 생성된 인증서의 기본 만료 기한을 변경하려면 추가 기능을 만들거나 업데이트할 때 다음과 같은 추가 구성을 사용합니다. *expiry-in-days*를 원하는 만료 기간(일)으로 바꿉니다.
+ Amazon CloudWatch Observability EKS 추가 기능에 사용
```
--configuration-values '{ "admissionWebhooks": { "autoGenerateCert": { "expiryDays": expiry-in-days } } }'
```
+ 차트 Helm에 사용
```
--set admissionWebhooks.autoGenerateCert.expiryDays=expiry-in-days
```
보다 안전하고 기능이 풍부한 인증 기관 솔루션을 위해 이 추가 기능에는 [cert-manager](https://cert-manager.io/docs/)에 대한 옵트인 지원이 있습니다. 이 솔루션은 Kubernetes에서 TLS 인증서 관리를 위해 널리 채택되고 있으며, 이를 통해 인증서를 획득, 갱신, 관리 및 사용하는 프로세스가 간소화됩니다. 인증서가 유효하고 최신 상태인지 확인하고 만료되기 전에 구성된 시간에 인증서 갱신을 시도합니다. cert-manager는 또한 [AWS Certificate Manager Private Certificate Authority](https://aws.amazon.com/private-ca/)를 포함하여 지원되는 다양한 소스에서 인증서 발급을 용이하게 합니다.
클러스터의 TLS 인증서 관리에 대한 모범 사례를 검토하고 프로덕션 환경에서는 cert-manager로 옵트인하는 것이 좋습니다. 승인 웹후크 TLS 인증서를 관리하기 위해 cert-manager를 활성화하도록 옵트인 경우 Amazon CloudWatch Observability EKS 추가 기능 또는 차트 Helm을 설치하기 전에 Amazon EKS 클러스터에 cert-manager를 미리 설치해야 합니다. 사용 가능한 설치 옵션에 대한 자세한 내용은 [cert-manager 설명서](https://cert-manager.io/docs/installation/)를 참조하세요. 설치한 후에는 다음 추가 구성을 사용하여 승인 웹후크 TLS 인증서를 관리하는 데 cert-manager를 사용하도록 옵트인할 수 있습니다.
+ Amazon CloudWatch Observability EKS 추가 기능을 사용하는 경우
```
--configuration-values '{ "admissionWebhooks": { "certManager": { "enabled": true } } }'
```
+ 차트 Helm을 사용하는 경우
```
--set admissionWebhooks.certManager.enabled=true
```
```
--configuration-values '{ "admissionWebhooks": { "certManager": { "enabled": true } } }'
```
이 섹션에서 설명하는 고급 구성에서는 기본적으로 [ SelfSigned](https://cert-manager.io/docs/configuration/selfsigned/) 발급자를 사용합니다.
### Amazon EBS 볼륨 ID 수집
성능 로그에서 Amazon EBS 볼륨 ID를 수집하려는 경우 워커 노드나 서비스 계정에 연결된 IAM 역할에 다른 정책을 추가해야 합니다. 다음 내용을 인라인 정책으로 추가합니다. 자세한 내용은 [IAM 자격 증명 권한 추가 및 제거](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html)를 참조하세요.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ec2:DescribeVolumes"
],
"Resource": "*",
"Effect": "Allow"
}
]
}
```
------
## Java Management Extensions(JMX) 지표 수집
CloudWatch 에이전트는 Amazon EKS에서 Java Management Extensions(JMX) 지표 수집을 지원합니다. 이를 사용하면 Amazon EKS 클러스터에서 실행되는 Java 애플리케이션에서 추가 지표를 수집하여 성능, 메모리 사용량, 트래픽 및 기타 중요한 지표에 대한 인사이트를 얻을 수 있습니다. 자세한 내용은 [Java Management Extensions(JMX) 지표 수집](CloudWatch-Agent-JMX-metrics.md) 섹션을 참조하세요.
## Kueue 지표 활성화
CloudWatch Observability EKS 추가 기능의 `v2.4.0-eksbuild.1` 버전부터는 Container Insights for Amazon EKS는 Amazon EKS 클러스터에서 Kueue 지표를 자동으로 수집합니다. 이러한 지표에 대한 자세한 내용은 [Kueue 지표](Container-Insights-metrics-EKS.md#Container-Insights-metrics-Kueue) 섹션을 참조하세요.
Amazon SageMaker AI Hyperpod Task Governance EKS 추가 기능을 사용할 경우, **사전 조건** 섹션의 단계를 건너뛰고 [구성 플래그 활성화](#enable-Kueue-metrics-flag)의 단계를 따르기만 하면 됩니다.
### 사전 조건
Amazon EKS 클러스터에 Kueue를 설치하기 전에 매니페스트 파일에서 아래의 업데이트를 수행해야 합니다.
1. Kueue에 대한 선택적 클러스터 대기열 리소스 지표를 활성화합니다. 이렇게 하려면 `kueue-system` ConfigMap에서 인라인 `controller_manager_config.yaml`을 수정합니다. `metrics` 섹션에서 `enableClusterQueueResources: true` 행을 추가하거나 주석 처리를 해제합니다.
```
apiVersion: v1
data:
controller_manager_config.yaml: |
apiVersion: config.kueue.x-k8s.io/v1beta1
kind: Configuration
health:
healthProbeBindAddress: :8081
metrics:
bindAddress: :8080
enableClusterQueueResources: true <-- ADD/UNCOMMENT THIS LINE
```
1. 기본적으로 모든 `k8s` 서비스는 클러스터 전체에서 사용 가능합니다. Kueue는 지표를 노출하기 위해 `kueue-controller-manager-metrics-service` 서비스를 생성합니다. 지표에 대한 중복 관찰을 방지하려면 동일한 노드에서 지표 서비스에 대한 액세스만 허용하도록 이 서비스를 수정합니다. 이렇게 하려면 `internalTrafficPolicy: Local` 행을 `kueue-controller-manager-metrics-service` 정의에 추가합니다.
```
apiVersion: v1
kind: Service
metadata:
labels:
...
name: kueue-controller-manager-metrics-service
namespace: kueue-system
spec:
ports:
- name: https
port: 8443
protocol: TCP
targetPort: https
internalTrafficPolicy: Local <-- ADD THIS LINE
selector:
control-plane: controller-manager
```
1. 마지막으로, `kueue-controller-manager` 포드는 `kube-rbac-proxy` 컨테이너를 생성합니다. 현재 이 컨테이너는 로깅 상세 수준이 높으므로, 지표 스크레이퍼가 `kueue-controller-manager-metrics-service`에 액세스할 경우 클러스터의 베어러 토큰이 해당 컨테이너에 의해 로깅됩니다. 이 로깅 상세 수준을 줄이는 것이 좋습니다. Kueue에서 배포한 매니페스트의 기본값은 10이지만, 0으로 변경하는 것이 좋습니다.
```
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
...
name: kueue-controller-manager
namespace: kueue-system
spec:
...
template:
...
spec:
containers:
...
- args:
- --secure-listen-address=0.0.0.0:8443
- --upstream=http://127.0.0.1:8080/
- --logtostderr=true
- --v=0 <-- CHANGE v=10 TO v=0
image: gcr.io/kubebuilder/kube-rbac-proxy:v0.8.0
name: kube-rbac-proxy
...
```
### 구성 플래그 활성화
Kueue 지표를 활성화하려면 추가 기능 추가 구성에서 `kueue_container_insights`를 활성화해야 합니다. AWS CLI를 사용하여 EKS 관찰성 추가 기능을 설정하거나, Amazon EKS 콘솔을 사용하여 이 작업을 수행할 수 있습니다.
다음 방법 중 하나를 사용하여 EKS 관찰성 추가 기능을 성공적으로 설치한 후에는 HyperPod 콘솔의 **대시보드** 탭에서 Amazon EKS 클러스터 지표를 볼 수 있습니다.
------
#### [ AWS CLI ]
**AWS CLI를 사용하여 Kueue 지표를 활성화하려면 다음을 수행합니다.**
+ 다음 AWS CLI 명령을 입력하여 추가 기능을 설치합니다.
```
aws eks create-addon --cluster-name cluster-name --addon-name amazon-cloudwatch-observability --configuration-values "configuration_json_file"
```
다음은 구성 값이 있는 JSON 파일의 예입니다.
```
{
"agent": {
"config": {
"logs": {
"metrics_collected": {
"kubernetes": {
"kueue_container_insights": true,
"enhanced_container_insights": true
},
"application_signals": { }
}
},
"traces": {
"traces_collected": {
"application_signals": { }
}
}
},
},
}
```
------
#### [ Amazon EKS console ]
**Amazon EKS 콘솔을 사용하여 Kueue 지표를 활성화하려면 다음을 수행합니다.**
1. [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters)에서 Amazon EKS 콘솔을 엽니다.
1. 클러스터 이름을 선택합니다.
1. **애드온 기능**을 선택합니다.
1. 목록에서 **Amazon CloudWatch Observability** 추가 기능을 찾아 설치합니다. 이때 **선택적 구성**을 선택하고 아래의 JSON 구성 값을 포함합니다.
```
{
"agent": {
"config": {
"logs": {
"metrics_collected": {
"kubernetes": {
"kueue_container_insights": true,
"enhanced_container_insights": true
},
"application_signals": { }
}
},
"traces": {
"traces_collected": {
"application_signals": { }
}
}
},
},
}
```
------
## OpenTelemetry 수집기 구성 파일 추가
CloudWatch 에이전트는 자체 구성 파일과 함께 추가 OpenTelemetry 수집기 구성 파일을 지원합니다. 이 기능을 사용하면 CloudWatch 에이전트 구성을 통해 CloudWatch 에이전트 기능(예: CloudWatch Application Signals 또는 Container Insights)을 사용하고, 단일 에이전트를 활용하여 기존 OpenTelemetry 수집기 구성을 가져올 수 있습니다.
CloudWatch 에이전트가 자동으로 생성한 파이프라인과의 병합 충돌을 방지하려면, OpenTelemetry 수집기 구성의 각 구성 요소 및 파이프라인에 사용자 지정 접미사를 추가하는 것이 좋습니다. 이렇게 하면 충돌 및 병합 충돌이 방지됩니다.
+ Amazon CloudWatch Observability EKS 추가 기능을 사용하는 경우
```
--configuration-values file://values.yaml
```
또는
```
--configuration-values '
agent:
otelConfig:
receivers:
otlp/custom-suffix:
protocols:
http: {}
exporters:
awscloudwatchlogs/custom-suffix:
log_group_name: "test-group"
log_stream_name: "test-stream"
service:
pipelines:
logs/custom-suffix:
receivers: [otlp/custom-suffix]
exporters: [awscloudwatchlogs/custom-suffix]
'
```
+ 차트 Helm을 사용하는 경우
```
--set agent.otelConfig='
receivers:
otlp/custom-suffix:
protocols:
http: {}
exporters:
awscloudwatchlogs/custom-suffix:
log_group_name: "test-group"
log_stream_name: "test-stream"
service:
pipelines:
logs/custom-suffix:
receivers: [otlp/custom-suffix]
exporters: [awscloudwatchlogs/custom-suffix]
'
```
## Amazon EKS 클러스터의 Application Signals를 통해 APM 활성화
CloudWatch Observability EKS 애드온(5.0.0 이상 버전) 또는 헬름 차트를 설치할 경우, Application Signals를 통해 OpenTelemetry(OTEL) 기반의 Application Performance Monitoring(APM)이 기본적으로 활성화됩니다. Amazon EKS 추가 기능에 대한 고급 구성을 사용하거나 헬름 차트로 값을 재정의하여 특정 설정을 추가로 사용자 지정할 수 있습니다.
**참고**
OpenTelemetry(OTEL) 기반 APM 솔루션을 사용할 경우, Application Signals를 활성화하면 기존 관찰성 설정에 영향을 미칩니다. 계속 진행하기 전에 현재 구현을 검토하시기 바랍니다. 5.0.0 이상 버전으로 업그레이드한 후 기존 APM 설정을 유지하려면 [Application Signals 옵트아웃](#Opting-out-App-Signals) 섹션을 참조하세요.
**Application Signals 자동 모니터**
CloudWatch Observability Amazon EKS 추가 기능의 버전 5.0.0과 헬름 차트에서 새로운 기능이 도입됩니다. 이제 자동 모니터 구성을 통해 EKS 클러스터의 모든 또는 특정 서비스 워크로드에 대해 Application Signals를 자동으로 활성화할 수 있습니다. 고급 구성의 `manager` 섹션 아래에 있는 `applicationSignals` 섹션 내에서 다음 `autoMonitor` 설정을 지정할 수 있습니다.
+ *monitorAllServices* - 자동 모니터를 통해 모든 서비스 워크로드에 대한 모니터링을 활성화(true) 또는 비활성화(false)하는 부울 플래그입니다. 기본값은 true입니다. 이 플래그를 활성화하면 Kubernetes Service에 매핑된 클러스터의 모든 Kubernetes 워크로드(Deployment, DaemonSet 및 StatefulSet)가 처음으로 시작될 때(또는 기존 워크로드에 대해 다시 시작될 때) Application Signals의 자동 활성화 범위에 포함됩니다. 시스템에서 기본적으로 `kube-system` 및 `amazon-cloudwatch` 네임스페이스의 워크로드는 제외됩니다.
+ *languages* - `monitorAllServices`가 활성화되면 Application Signals에서 서비스를 자동으로 계측하려고 시도하는 언어 집합을 지정하는 문자열 목록입니다. 모든 [지원되는 언어](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html)가 기본값으로 설정됩니다.
+ *restartPods* - 구성 변경 후 워크로드의 재시작 여부를 제어하는 부울 플래그입니다. 기본값은 false입니다. 이 플래그를 `true`로 활성화하면 구성 변경 사항을 저장할 때 자동 모니터 범위 내에 있는 Kubernetes 워크로드가 자동으로 다시 시작되는지 여부를 제어할 수 있습니다. `updateStrategy`와 같이 포드 재시작에 영향을 미치는 Kubernetes 워크로드의 모든 설정이 고려됩니다. 다시 시작하면 서비스 가동 중지 시간이 발생할 수 있습니다.
+ *customSelector* - 특정 Kubernetes 네임스페이스 또는 워크로드의 자동 모니터 대상으로 선택하는 설정입니다.
+ *java* - Java로 자동 계측할 워크로드를 지정합니다.
+ *python* - Python으로 자동 계측할 워크로드를 지정합니다.
+ *nodejs* - Node.js로 자동 계측할 워크로드를 지정합니다.
+ *dotnet* - .NET으로 자동 계측할 워크로드를 지정합니다.
위의 각 언어에 대해 다음 필드를 구성할 수 있습니다.
+ *namespaces* - 선택할 네임스페이스를 지정하는 문자열 목록입니다. 기본값은 빈 목록, 즉 []입니다.
+ *deployments* - 선택할 배포를 지정하는 문자열 목록입니다. `namespace/deployment` 형식으로 지정합니다. 기본값은 빈 목록, 즉 []입니다.
+ *daemonsets* - 선택할 DaemonSet를 지정하는 문자열 목록입니다. `namespace/daemonset` 형식으로 지정합니다. 기본값은 빈 목록, 즉 []입니다.
+ *statefulsets* - 선택할 StatefulSet를 지정하는 문자열 목록입니다. `namespace/statefulset` 형식으로 지정합니다. 기본값은 빈 목록, 즉 []입니다.
+ *exclude* - 자동 모니터에서 특정 Kubernetes 네임스페이스 또는 워크로드를 제외하는 설정입니다. 동일한 워크로드가 `monitorAllServices` 또는 `customSelector`의 범위 내에 있는 경우 워크로드 제외가 우선 적용됩니다.
+ *java* - Java를 사용한 자동 계측에서 제외할 워크로드를 지정합니다.
+ *python* - Python을 사용한 자동 계측에서 제외할 워크로드를 지정합니다.
+ *nodejs* - Node.js를 사용한 자동 계측에서 제외할 워크로드를 지정합니다.
+ *dotnet* - .NET을 사용한 자동 계측에서 제외할 워크로드를 지정합니다.
위의 각 언어에 대해 다음 필드를 구성할 수 있습니다.
+ *namespaces* - 제외할 네임스페이스를 지정하는 문자열 목록입니다. 기본값은 빈 목록, 즉 []입니다.
+ *deployments* - 제외할 배포를 지정하는 문자열 목록입니다. `namespace/deployment` 형식으로 지정합니다. 기본값은 빈 목록, 즉 []입니다.
+ *daemonsets* - 제외할 DaemonSet를 지정하는 문자열 목록입니다. `namespace/daemonset` 형식으로 지정합니다. 기본값은 빈 목록, 즉 []입니다.
+ *statefulsets* - 제외할 StatefulSet를 지정하는 문자열 목록입니다. `namespace/statefulset` 형식으로 지정합니다. 기본값은 빈 목록, 즉 []입니다.
다음은 클러스터의 모든 기존 및 새로운 서비스 워크로드에 대해 Application Signals를 자동으로 활성화하는 구성의 예제입니다.
```
manager:
applicationSignals:
autoMonitor:
monitorAllServices: true
restartPods: true
```
다음은 새로운 서비스 워크로드와 클러스터에서 명시적으로 다시 시작된 기존 서비스 워크로드에 대해 Application Signals를 자동으로 활성화하는 구성의 예제입니다.
```
manager:
applicationSignals:
autoMonitor:
monitorAllServices: true
```
다음은 `pet-warehouse` 네임스페이스의 워크로드에 해당하는 모든 기존 및 새 포드에 대해 Java로 Application Signals를 자동으로 활성화하는 구성의 예제입니다.
```
manager:
applicationSignals:
autoMonitor:
restartPods: true
customSelector:
java:
namespaces: ["pet-warehouse"]
```
다음은 `pet-clinic` 배포를 제외하고 클러스터의 모든 기존 및 새로운 서비스 워크로드에 대해 Python으로 Application Signals를 자동으로 활성화하는 구성의 예제입니다.
```
manager:
applicationSignals:
autoMonitor:
monitorAllServices: true
languages: ["python"]
restartPods: true
exclude:
python:
deployments: ["pet-warehouse/pet-clinic"]
```
다음은 `python-apps` 네임스페이스의 워크로드를 제외하고 클러스터의 모든 서비스 워크로드에 대해 Java로 Application Signals를 자동으로 활성화한 다음 `python-apps` 네임스페이스의 `sample-python-app` 배포에 대해 Python으로 Application Signals를 추가로 활성화하는 구성의 예제입니다.
```
manager:
applicationSignals:
autoMonitor:
monitorAllServices: true
languages: ["java"]
restartPods: true
customSelector:
python:
deployments: ["python-apps/sample-python-app"]
exclude:
java:
namespaces: ["python-apps"]
```
## Amazon CloudWatch Observability EKS 추가 기능 또는 차트 Helm 문제 해결
다음은 Amazon CloudWatch Observability EKS 추가 기능 또는 차트 Helm 관련 문제를 해결하는 데 도움이 되는 정보입니다.
**Topics**
+ [Amazon CloudWatch Observability EKS 추가 기능 또는 차트 Helm 업데이트 및 삭제](#EKS-addon-troubleshoot-update)
+ [Amazon CloudWatch Observability EKS 추가 기능 또는 차트 Helm에서 사용하는 CloudWatch 에이전트의 버전 확인](#EKS-addon-troubleshoot-version)
+ [추가 기능 또는 차트 Helm 관리 시 ConfigurationConflict 처리](#EKS-addon-troubleshoot-conflict)
### Amazon CloudWatch Observability EKS 추가 기능 또는 차트 Helm 업데이트 및 삭제
Amazon CloudWatch Observability EKS 추가 기능의 업데이트 또는 삭제에 대한 지침은 [Amazon EKS 추가 기능 관리](https://docs.aws.amazon.com/eks/latest/userguide/managing-add-ons.html)를 참조하세요. 추가 기능 이름으로 `amazon-cloudwatch-observability`를 사용합니다.
클러스터에서 차트 Helm을 삭제하려면 다음 명령을 입력합니다.
```
helm delete amazon-cloudwatch-observability -n amazon-cloudwatch --wait
```
### Amazon CloudWatch Observability EKS 추가 기능 또는 차트 Helm에서 사용하는 CloudWatch 에이전트의 버전 확인
Amazon CloudWatch Observability EKS 추가 기능 또는 차트 Helm은 사용 중인 CloudWatch 에이전트의 버전을 포함하여 클러스터에서 CloudWatch 에이전트 대몬 세트의 동작을 제어하는 `AmazonCloudWatchAgent` 종류의 사용자 지정 리소스를 설치합니다. 다음 명령을 입력하면 클러스터에 설치된 모든 `AmazonCloudWatchAgent` 사용자 지정 리소스 목록을 가져올 수 있습니다.
```
kubectl get amazoncloudwatchagent -A
```
이 명령의 출력에서 CloudWatch 에이전트의 버전을 확인할 수 있습니다. 또는 클러스터에서 실행 중인 `amazoncloudwatchagent` 리소스 또는 `cloudwatch-agent-*` 포드 중 하나를 설명하여 사용 중인 이미지를 검사할 수도 있습니다.
### 추가 기능 또는 차트 Helm 관리 시 ConfigurationConflict 처리
Amazon CloudWatch Observability EKS 추가 기능 또는 차트 Helm을 설치하거나 업데이트할 때 기존 리소스로 인해 장애가 발생하는 경우, 클러스터에 이미 CloudWatch 에이전트와 관련 구성 요소(예: ServiceAccount, ClusterRole 및 ClusterRoleBinding)가 설치되어 있기 때문일 수 있습니다.
추가 기능에 의해 표시되는 오류에는 `Conflicts found when trying to apply. Will not continue due to resolve conflicts mode` 메시지가 포함됩니다.
차트 Helm에 표시되는 오류는 `Error: INSTALLATION FAILED: Unable to continue with install and invalid ownership metadata.`와 비슷합니다.
추가 기능 또는 차트 Helm이 CloudWatch 에이전트 및 연결된 구성 요소를 설치하려고 할 때 콘텐츠의 변경 사항이 탐지되면 기본적으로 클러스터의 리소스 상태를 덮어쓰지 않도록 설치 또는 업데이트가 실패합니다.
Amazon CloudWatch Observability EKS 추가 기능에 온보딩하려고 하는데 이 오류가 표시되는 경우 이전에 클러스터에 설치한 기존 CloudWatch 에이전트 설정을 삭제한 다음, EKS 추가 기능 또는 차트 Helm을 설치하는 것이 좋습니다. 사용자 지정 에이전트 구성과 같이 원래 CloudWatch 에이전트 설정에 대한 모든 사용자 지정을 백업하고 다음에 설치하거나 업데이트할 때 Amazon CloudWatch Observability EKS 추가 기능 또는 차트 Helm에 제공합니다. 이전에 Container Insights 온보딩을 위해 CloudWatch 에이전트를 설치한 경우 자세한 내용은 [Container Insights의 CloudWatch 에이전트 및 Fluent Bit 삭제](ContainerInsights-delete-agent.md) 섹션을 참조하세요.
또는 추가 기능은 `OVERWRITE`를 지정하는 기능이 있는 충돌 해결 구성 옵션을 지원합니다. 이 옵션을 사용하면 클러스터의 충돌을 덮어써서 추가 기능 설치 또는 업데이트를 진행할 수 있습니다. Amazon EKS 콘솔을 사용하는 경우 추가 기능을 생성하거나 업데이트할 때 **선택적 구성 설정**을 선택하면 **충돌 해결 방법**을 찾을 수 있습니다. AWS CLI를 사용하는 경우 명령에 `--resolve-conflicts OVERWRITE`를 제공하여 추가 기능을 생성하거나 업데이트할 수 있습니다.
## Application Signals 옵트아웃
CloudWatch 콘솔 또는 SDK를 사용하여 서비스 모니터링 기본 설정을 미세 조정합니다.
5.0.0 이전 버전의 경우, Application Signals 자동 모니터링을 비활성화하려면 아래 절차를 따릅니다.
**CLI 또는 SDK 사용**
다음 구성은 EKS 애드온에 고급 구성으로 적용하거나, 헬름 차트를 사용할 때 값 재정의로 적용할 수 있습니다.
```
{
"manager": {
"applicationSignals": {
"autoMonitor": {
"monitorAllServices": false
}
}
}
}
```
서비스를 다시 시작하여 변경 사항을 적용합니다.
**콘솔 사용**
[https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **Application Signals(APM)**, **서비스**를 선택합니다.
1. 활성화 페이지를 보려면 **Application Signals 활성화**를 선택합니다.
1. 모니터링하지 않을 각 서비스에 대해 **Auto-Monitor** 확인란의 선택을 취소합니다.
1. 서비스를 다시 시작하여 변경 사항을 적용합니다.