기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Beanstalk 클러스터 환경 모니터링
Beanstalk 클러스터 환경은 Beanstalk 표준 환경과 동일한 Elastic Beanstalk 상태 모델 및 APIs를 통해 환경 수준 상태를 보고합니다. Elastic Beanstalk 콘솔에서 상태 및 색상을 보고를 호출`DescribeEnvironmentHealth`하여 현재 색상, 상태 및 이를 설명하는 원인을 읽을 수 있습니다. 상태 색상과 상태는 두 모드 모두에서 동일한 의미를 갖습니다.
Beanstalk 클러스터 환경에서 Application Load Balancer를 사용하는 경우 Elastic Beanstalk는 요청 속도, HTTP 4xx 및 5xx 응답을 반환하는 요청의 비율, 응답 지연 시간 등 환경의 로드 밸런서 지표에서 애플리케이션 상태를 결정합니다. 요청을 성공적으로 처리하는 환경은 상태를 보고합니다. 실패한 요청의 비율이 증가하면 상태가 점점 더 심각해집니다. Elastic Beanstalk가 요청 속도가 유휴 환경에 대해 예상되는 상태를 결정하기에 충분하지 않다는 보고서를 평가하기에는 트래픽이 너무 적은 환경입니다. 로드 밸런서 유형을 로 설정하면 `None`이 로드 밸런서 평가가 적용되지 않습니다.
Beanstalk 표준 환경과 달리 Beanstalk 클러스터 환경은 인스턴스당 상태를 보고하지 않습니다. Beanstalk 클러스터는 인스턴스 상태 에이전트를 사용하지 않으며 표준 환경에 적용되는 인스턴스 수준 상태 보고 설정은 적용되지 않습니다.
컨테이너 프로브는 애플리케이션 복제본이 트래픽을 수신하고 다시 시작할 때를 제어합니다. 준비 프로브는 서비스에서 준비되지 않은 복사본을 제거하고, 라이브니스 프로브는 비정상 상태로 유지되는 복사본을 다시 시작하고, 시작 프로브는 초기화하는 데 느린 시작 복사 시간을 제공합니다. 에서 프로브 네임스페이스를 사용하여 프로브를 구성합니다`aws:elasticbeanstalk:eks:environment`. [컨테이너 프로브 네임스페이스](command-options-general-eks.md#command-options-eks-probes)을(를) 참조하세요.
## 지표, 로그 및 추적
애플리케이션 관찰성은 환경 상태와는 별개입니다. `aws:elasticbeanstalk:eks:observability` 네임스페이스의 구성 옵션을 사용하여 애플리케이션의 지표, 로그 및 트레이스에 대한 백엔드를 선택합니다. 기본적으로 Elastic Beanstalk는 애플리케이션의 지표와 로그를 Amazon CloudWatch(CloudWatch)로 전송하며, 트레이스에는 백엔드가 없습니다. 대신 Amazon S3로 로그를 전송하고, Amazon Managed Service for Prometheus로 지표를 전송하고, 로 추적을 전송할 수 있습니다 AWS X-Ray. OpenTelemetry 데이터를 허용하는 타사 백엔드로 세 가지 중 하나를 보낼 수도 있습니다. 단원을 참조하십시오[타사 백엔드로 관찰성 데이터 전송](#monitoring-cluster-environments-custom-backend). 사용 가능한 옵션은 섹션을 참조하세요[aws:elasticbeanstalk:eks:observability](command-options-general-eks.md#command-options-eks-observability).
Elastic Beanstalk는 컬렉션 구성 요소를 프로비저닝 및 운영하고 사용자를 대신하여 인프라 지표를 게시합니다. 원하는 지표, 로그 및 추적을 내보내도록 애플리케이션을 계측하고 선택한 대상에 대한 액세스를 제공하고 유지 관리하는 것은 사용자의 책임입니다.
애플리케이션이 백엔드가 무언가를 수신하려면 OpenTelemetry 데이터를 내보내야 합니다. 애플리케이션을 변경하지 않고 이를 가져오려면 `aws:elasticbeanstalk:eks:environment` 네임스페이스의 `language` 옵션을 애플리케이션의 런타임으로 설정합니다. Elastic Beanstalk는 모든 백엔드 AWS 와 타사 모두에 적용되는 해당 런타임에 대한 OpenTelemetry 자동 계측을 컨테이너에 추가합니다. 자동 계측은 Java, Node.js, Python 및 .NET 애플리케이션에서 사용할 수 있습니다. Java 애플리케이션의 경우 에이전트는 Log4j2, Logback 및 도 연결하여 애플리케이션의 로그가 애플리케이션 변경 없이 로그 백엔드에 도달`java.util.logging`하도록 합니다.
로그 백엔드와 별도로 Elastic Beanstalk는 각 환경 작업에 대한 배포 로그를 수집합니다. 여기에는 포드의 컨테이너 로그와 작업의 Kubernetes 이벤트가 포함되어 있으므로 작업이 실패할 때 확인할 수 있습니다. 자세한 내용은 [배포 로그](environments-deployment-logs.md) 단원을 참조하십시오.
### CloudWatch에서 로그 및 지표 찾기
기본 백엔드를 사용하면 Elastic Beanstalk는 4개의 CloudWatch 로그 그룹에 씁니다. 로그 그룹 이름은 고정되며 변경할 수 없습니다.
**Beanstalk 클러스터 환경에 대한 CloudWatch 로그 그룹**
| **로그 그룹:** | **목차** | **로그 스트림 이름** | **존재하는 경우** |
| --- | --- | --- | --- |
| `/aws/elasticbeanstalk/application/logs` | 애플리케이션의 컨테이너에서 출력합니다. | `eb-{{environment-name}}.{{pod-name}}` | `logs-backend`가 `cloudwatch`인 경우 기본값입니다. |
| `/aws/elasticbeanstalk/application/metrics` | 애플리케이션이 내보내는 지표입니다. | `{{environment-name}}/{{pod-name}}` | `metrics-backend`가 `cloudwatch`인 경우 기본값이며 애플리케이션이 지표를 내보냅니다. |
| `/aws/elasticbeanstalk/infrastructure/logs` | Elastic Beanstalk가 사용자를 대신하여 클러스터에서 실행하는 구성 요소의 출력입니다. | `{{kubernetes-namespace}}.{{pod-name}}` | 항상. |
| `/aws/elasticbeanstalk/infrastructure/metrics` | Elastic Beanstalk가 게시하는 지표는 임베디드 지표 형식으로 표시됩니다. | `{{kubernetes-namespace}}.{{pod-name}}` | 항상. |
**참고**
이러한 로그 그룹은 공유됩니다. AWS 계정 및 리전의 모든 Beanstalk 클러스터 환경은 모든 클러스터에서 동일한 4개 그룹에 씁니다. 환경의 데이터는 로그 그룹이 아닌 로그 스트림 이름으로 구분됩니다. Elastic Beanstalk는 라는 Kubernetes 네임스페이스에서 각 환경을 실행한 `eb-` 후 환경 이름을 지정하므로 애플리케이션의 로그 스트림은 `eb-{{environment-name}}` 및 마침표로 시작합니다. 애플리케이션의 지표 스트림은 `eb-` 접두사 없이 환경 이름과 슬래시로 시작합니다.
Elastic Beanstalk는 보존 정책 없이 이러한 로그 그룹을 생성하므로 콘텐츠가 만료되지 않습니다. 로그 스트림 이름에는 포드 이름이 포함되어 있으므로 모든 배포는 새 스트림을 생성하고 이전 배포의 스트림은 그대로 유지됩니다. 저장 내용을 제한하도록 각 로그 그룹에 보존 정책을 설정합니다.
Elastic Beanstalk가 게시하는 지표는 세 개의 CloudWatch 네임스페이스에 도착합니다. 세 가지 모두 지표당 지불하는 사용자 지정 네임스페이스입니다. Beanstalk Standard 환경은 대신 CloudWatch가 무료로 제공하는 `AWS/ElasticBeanstalk` 네임스페이스에 게시합니다. Beanstalk 클러스터 환경은 각 복제본에 대해 아래 컨테이너 지표를 게시하므로 사용자 지정 지표 수는 실행하는 복제본 수에 따라 증가합니다. 현재 요금은 [Amazon CloudWatch 요금을](https://aws.amazon.com/cloudwatch/pricing/) 참조하세요.
**Beanstalk 클러스터 환경에 대한 CloudWatch 지표**
| **네임스페이스** | **Metrics** | **Dimensions** |
| --- | --- | --- |
| `ElasticBeanstalk/Infrastructure` | 애플리케이션의 컨테이너: `container_cpu_usage_seconds_total`, `container_memory_working_set_bytes`및 `EnvironmentReplicas`의 경우 준비된 복제본 수입니다. | 두 컨테이너 지표는 `namespace`, `pod` `container` 및와 함께 게시됩니다`namespace`. `EnvironmentReplicas`는와 함께 게시`namespace`됩니다. |
| `ElasticBeanstalk/System` | Elastic Beanstalk가 애플리케이션 대신 클러스터에서 실행하는 구성 요소에 대해 동일한 두 컨테이너 지표입니다. | `namespace`, `container`, `pod`및를 `namespace` 단독으로 사용합니다. |
| `ElasticBeanstalk/Application` | 자동 계측이 생성하는 런타임 지표를 포함하여 애플리케이션이 내보내는 지표입니다. | `EnvironmentName`. 요청 기간은 `http.method`, `http.route`및와 함께 게시됩니다`http.status_code`. |
`namespace` 차원은 Kubernetes 네임스페이스이므로 값 `eb-` 뒤에 환경 이름이 옵니다. 대신 `ElasticBeanstalk/Application` 네임스페이스는 값이 환경 이름 자체인 `EnvironmentName`차원을 사용합니다. 쿼리하려는 네임스페이스와 일치하는 값을 사용합니다.
`logs-backend`를 로 설정하면 `s3`Elastic Beanstalk는 Kubernetes 네임스페이스, 포드 이름 및 날짜에서 빌드된 키 아래에 `elasticbeanstalk-logs-{{account-id}}-{{region}}-an` 애플리케이션의 로그를 라는 버킷에 씁니다. 그러면 아무것도 로 전달되지 않습니다`/aws/elasticbeanstalk/application/logs`. Elastic Beanstalk는 이러한 업로드를 일괄 처리하므로 객체가 표시되는 데 최대 1분이 걸릴 수 있습니다. `logs-backend` 또는를 `metrics-backend`로 설정하면 `custom`해당 데이터는 구성한 백엔드로 이동하며 이러한 로그 그룹에는 표시되지 않습니다. [타사 백엔드로 관찰성 데이터 전송](#monitoring-cluster-environments-custom-backend)을(를) 참조하세요.
## 타사 백엔드로 관찰성 데이터 전송
Beanstalk 클러스터는 OpenTelemetry 수집기를 사용하여 애플리케이션의 원격 측정을 수집하므로 AWS 대상 대신 Datadog 또는 Splunk와 같은 OpenTelemetry 데이터를 허용하는 모든 백엔드로 전송할 수 있습니다. 파이프라인 구성과 필요한 자격 증명을 제공하면 Elastic Beanstalk는 파이프라인을 애플리케이션 포드의 사이드카 컨테이너로 실행합니다.
타사 백엔드를 구성하려면 다음 네 가지가 필요합니다.
1. 리디렉션할 각 신호를 설정합니다`custom`. 신호는 독립적이므로 추적이 계속 진행되는 동안 타사 백엔드로 지표와 로그를 보낼 수 있습니다 AWS X-Ray. `aws:elasticbeanstalk:eks:observability` 네임스페이스`traces-backend`에서 `logs-backend`, 및 `metrics-backend`를 사용합니다.
1. 수집기의 파이프라인 구성`custom-config`으로 JSON으로 설정합니다. 구성에 값을 입력하지 않고 각 자격 증명을 `${{{NAME}}}` 자리 표시자로 참조합니다.
1. 자격 증명을에 저장 AWS Secrets Manager 하고 보안 암호의 ARN`custom-credentials`으로 설정합니다. 보안 암호 값은 키가 구성의 자리 표시자 이름과 일치하는 JSON 객체여야 합니다.
1. `aws:elasticbeanstalk:eks:environment` 네임스페이스에서 `application-role` 옵션을 설정하고 해당 역할에 보안 암호를 읽을 수 있는 권한을 부여합니다. 수집기는 관찰성 역할이 아닌 런타임에 애플리케이션 역할을 사용하며 `application-role`가 설정된 경우에만 존재하는 포드의 자격 증명을 통해 보안 암호에 도달합니다. 그렇지 않으면 탑재가 실패하고 복제본이 시작되지 않습니다.
다음 예제에서는 지표와 로그를 Datadog으로 전송하고 추적을 로 유지합니다 AWS X-Ray. 먼저 구성에서 참조하는 자격 증명을 포함하는 보안 암호를 생성합니다.
```
$ aws secretsmanager create-secret \
--name {{my-app/otel-credentials}} \
--secret-string '{"DD_API_KEY":"{{your-api-key}}"}'
```
수집기가 런타임에 가져올 수 있도록 애플리케이션 역할에 읽기 권한을 부여합니다.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue",
"secretsmanager:DescribeSecret"
],
"Resource": "{{arn:aws:secretsmanager:us-east-1:111122223333:secret:my-app/otel-credentials-AbCdEf}}"
}
]
}
```
Elastic Beanstalk는 일정에 따라 탑재된 자격 증명을 새로 고치고 새로 고침은 보안 암호의 현재 버전을 확인하므로 `secretsmanager:DescribeSecret` 외에도를 부여합니다`secretsmanager:GetSecretValue`. 환경은 `GetSecretValue` 단독으로 시작하지만 나중에 새로 고칠 때마다 실패합니다.
그런 다음 옵션 설정을 파일에 넣습니다. 수집기 구성에는의 간편 구문이 구분자로 `--option-settings` 취급되는 쉼표가 포함되어 있으므로 대신 설정을 JSON으로 전달합니다. 파이프라인 구성을 `custom-config` 값에 JSON 문자열로 `options.json`하여 다음을 로 저장합니다.
```
[
{
"Namespace": "aws:elasticbeanstalk:eks:observability",
"OptionName": "metrics-backend",
"Value": "custom"
},
{
"Namespace": "aws:elasticbeanstalk:eks:observability",
"OptionName": "logs-backend",
"Value": "custom"
},
{
"Namespace": "aws:elasticbeanstalk:eks:observability",
"OptionName": "traces-backend",
"Value": "xray"
},
{
"Namespace": "aws:elasticbeanstalk:eks:observability",
"OptionName": "custom-config",
"Value": "{\"receivers\":{\"otlp\":{\"protocols\":{\"grpc\":{\"endpoint\":\"0.0.0.0:4317\"},\"http\":{\"endpoint\":\"0.0.0.0:4318\"}}}},\"processors\":{\"batch\":{}},\"exporters\":{\"datadog\":{\"api\":{\"site\":\"{{datadoghq.com}}\",\"key\":\"${DD_API_KEY}\"}}},\"service\":{\"pipelines\":{\"metrics\":{\"receivers\":[\"otlp\"],\"processors\":[\"batch\"],\"exporters\":[\"datadog\"]},\"logs\":{\"receivers\":[\"otlp\"],\"processors\":[\"batch\"],\"exporters\":[\"datadog\"]}}}}"
},
{
"Namespace": "aws:elasticbeanstalk:eks:observability",
"OptionName": "custom-credentials",
"Value": "{{arn:aws:secretsmanager:us-east-1:111122223333:secret:my-app/otel-credentials-AbCdEf}}"
}
]
```
조직에서 사용하는 Datadog 사이트`site`로 설정합니다. 그런 다음 파일을 적용합니다.
```
$ aws elasticbeanstalk update-environment \
--environment-name {{my-cluster-env}} \
--option-settings file://options.json
```
로 설정한 각 신호에 대한 파이프라인을 정의합니다`custom`. AWS 대상에 남긴 신호는 Elastic Beanstalk가 작동하는 컬렉션을 계속 사용하며 자체 파이프라인이 필요하지 않습니다.
설정이 없는 구성 요소는 로 빈 객체를 사용합니다`"batch": {}`. `receivers` 블록은 선택 사항입니다. 생략하면 Elastic Beanstalk는 애플리케이션이 보내는 OTLP 수신기를 추가하고 추가를 보고하는 환경 이벤트를 기록합니다. 앞의 예제에서는 수신기를 명시적으로 정의합니다.
이를 설정하는 동안 각 파이프라인에 `debug` 내보내기를 추가하고 파이프라인 `exporters` 목록에 포함합니다. 그런 다음 수집기는 수신하고 내보내는 원격 측정을 로깅하여 데이터가 수집기에 도달하는지 여부와 수집기가 백엔드에 도달할 수 있는지 여부를 개별적으로 알려줍니다.