# 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. 서비스를 다시 시작하여 변경 사항을 적용합니다.