기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 로깅 및 모니터링
모니터링은 EMR Serverless 애플리케이션 및 작업의 신뢰성, 가용성 및 성능을 유지 관리하는 중요한 역할을 합니다. EMR Serverless 솔루션의 모든 부분에서 모니터링 데이터를 수집하여 다중 지점 장애가 발생할 경우 더 쉽게 디버깅할 수 있도록 해야 합니다.
**Topics**
+ [로그 저장](logging.md)
+ [로그 교체](rotating-logs.md)
+ [로그 암호화](jobs-log-encryption.md)
+ [Amazon EMR Serverless에 대한 Apache Log4j2 속성 구성](log4j2.md)
+ [EMR Serverless 모니터링](metrics.md)
+ [를 사용하여 EMR Serverless 자동화 Amazon EventBridge](using-eventbridge.md)
# 로그 저장
EMR Serverless에서 작업 진행 상황을 모니터링하고 작업 실패 문제를 해결하기 위해 EMR Serverless에서 애플리케이션 로그를 저장하고 제공하는 방법을 선택합니다. 작업 실행을 제출하는 경우 관리형 스토리지, Amazon S3 및 Amazon CloudWatch를 로깅 옵션으로 지정합니다.
CloudWatch를 사용하면 사용하려는 로그 유형 및 로그 위치를 지정하거나 기본 유형 및 위치를 수락합니다. Cloudwatch 로그에 대한 자세한 내용은 [Amazon CloudWatch를 사용하는 EMR Serverless에 대한 로깅](#jobs-log-storage-cw) 섹션을 참조하세요. 다음 표에서는 관리형 스토리지 및 S3 로깅을 사용하는 경우 [관리형 스토리지](#jobs-log-storage-managed-storage), [Amazon S3 버킷](#jobs-log-storage-s3-buckets) 또는 둘 다를 선택할 때 예상할 수 있는 로그 위치와 UI 가용성을 나열합니다.
| 옵션 | 이벤트 로그 | 컨테이너 로그 | 애플리케이션 UI |
| --- | --- | --- | --- |
| 관리형 스토리지 | 관리형 스토리지에 저장됨 | 관리형 스토리지에 저장됨 | 지원됨 |
| 관리형 스토리지와 S3 버킷 모두 | 두 장소에 모두 저장됨 | S3 버킷에 저장됨 | 지원됨 |
| Amazon S3 버킷 | S3 버킷에 저장됨 | S3 버킷에 저장됨 | 지원되지 않음1 |
1 **관리형 스토리지** 옵션을 선택한 상태로 유지하는 것이 좋습니다. 그렇지 않으면 기본 제공 애플리케이션 UI를 사용할 수 없습니다.
## 관리형 스토리지를 사용하는 EMR Serverless에 대한 로깅
기본적으로 EMR Serverless는 애플리케이션 로그를 Amazon EMR 관리형 스토리지에 최대 30일 동안 안전하게 저장합니다.
**참고**
기본 옵션을 끄면 Amazon EMR에서 사용자를 대신하여 작업 문제를 해결할 수 없습니다. 예: EMR Serverless Console에서 Spark-UI에 액세스할 수 없습니다.
EMR Studio에서이 옵션을 끄려면 **작업 제출** 페이지의 **추가 설정** 섹션에서 **30일 동안 로그 AWS 보존 허용** 확인란의 선택을 취소합니다.
에서이 옵션을 끄려면 작업 실행을 제출할 때 `managedPersistenceMonitoringConfiguration` 구성을 AWS CLI사용합니다.
```
{
"monitoringConfiguration": {
"managedPersistenceMonitoringConfiguration": {
"enabled": false
}
}
}
```
EMR Serverless 애플리케이션이 Amazon S3용 VPC 엔드포인트가 있는 프라이빗 서브넷에 있고 엔드포인트 정책을 연결하여 액세스를 제어하는 경우 EMR Serverless가 애플리케이션 로그를 저장하고 제공할 수 있도록 다음 권한을 추가합니다. [Amazon S3에 액세스하는 프라이빗 서브넷에 대한 샘플 정책](https://docs.aws.amazon.com/emr/latest/ManagementGuide/private-subnet-iampolicy.html#private-subnet-iampolicy-regions)의 사용 가능한 지역 테이블에서 `Resource`를 `AppInfo` 버킷으로 바꿉니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EMRServerlessManagedLogging",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:PutObjectAcl"
],
"Resource": [
"arn:aws:s3:::prod.us-east-1.appinfo.src",
"arn:aws:s3:::prod.us-east-1.appinfo.src/*"
],
"Condition": {
"StringEquals": {
"aws:PrincipalServiceName": "emr-serverless.amazonaws.com",
"aws:SourceVpc": "vpc-12345678"
}
}
}
]
}
```
------
또한 `aws:SourceVpc` 조건 키를 사용하여 요청이 VPC 엔드포인트가 연결된 VPC를 통해 전달되도록 합니다.
## Amazon S3 버킷을 사용하는 EMR Serverless에 대한 로깅
작업에서 Amazon S3로 로그 데이터를 전송하려면 먼저 작업 실행 역할에 대한 권한 정책에 다음 권한을 포함시킵니다. `amzn-s3-demo-logging-bucket`을 로깅 버킷의 이름으로 바꿉니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/*"
],
"Sid": "AllowS3Putobject"
}
]
}
```
------
의 로그를 저장하도록 Amazon S3 버킷을 설정하려면 작업 실행을 시작할 때 `s3MonitoringConfiguration` 구성을 AWS CLI사용합니다. 이를 수행하려면 구성에서 다음 `--configuration-overrides`를 제공합니다.
```
{
"monitoringConfiguration": {
"s3MonitoringConfiguration": {
"logUri": "s3://amzn-s3-demo-logging-bucket/logs/"
}
}
}
```
재시도를 활성화하지 않은 배치 작업의 경우 EMR Serverless는 로그를 다음 경로로 전송합니다.
```
'/applications//jobs/'
```
EMR Serverless는 Spark 드라이버 로그를 다음 경로에 저장합니다.
```
'/applications//jobs//SPARK_DRIVER/'
```
EMR Serverless는 Spark 실행기 로그를 다음 경로에 저장합니다.
```
'/applications//jobs//SPARK_EXECUTOR/'
```
는 정수입니다.
EMR Serverless 릴리스 7.1.0 이상에서는 스트리밍 작업 및 배치 작업에 대한 재시도를 지원합니다. 재시도가 활성화된 상태에서 작업을 실행하면 EMR Serverless는 로그 경로 접두사에 시도 번호를 자동으로 추가하므로, 로그를 효과적으로 식별하고 추적할 수 있습니다.
```
'/applications//jobs//attempts//'
```
## Amazon CloudWatch를 사용하는 EMR Serverless에 대한 로깅
EMR Serverless 애플리케이션에 작업을 제출하는 경우 Amazon CloudWatch를 애플리케이션 로그를 저장하는 옵션으로 선택합니다. 이를 통해 CloudWatch Logs Insights 및 Live Tail과 같은 CloudWatch 로그 분석 기능을 사용할 수 있습니다. 추가 분석을 위해 CloudWatch에서 OpenSearch와 같은 다른 시스템으로 로그를 스트리밍할 수도 있습니다.
EMR Serverless는 드라이버 로그에 대한 실시간 로깅을 제공합니다. CloudWatch Live Tail 기능을 사용하거나 CloudWatch CLI 테일 명령을 통해 로그에 실시간으로 액세스할 수 있습니다.
기본적으로 EMR Serverless에서는 CloudWatch 로깅이 비활성화됩니다. 이를 활성화하려면 [AWS CLI](#jobs-log-storage-cw-cli)의 구성을 사용합니다.
**참고**
Amazon CloudWatch는 로그를 실시간으로 게시하므로 작업자에서 더 많은 리소스가 사용됩니다. 더 적은 작업자 용량을 선택하면 작업 런타임에 미치는 영향이 커질 수 있습니다. CloudWatch 로깅을 활성화하는 경우 더 큰 워커 용량을 선택하는 것이 좋습니다. 초당 트랜잭션 수(TPS) 비율이 `PutLogEvents`에서 너무 낮으면 로그 게시가 스로틀링될 수도 있습니다. CloudWatch 스로틀링 구성은 EMR Serverless를 포함한 모든 서비스에 대해 전역으로 적용됩니다. 자세한 내용은 *AWS re:post*의 [CloudWatch Logs의 스로틀링 오류를 해결하려면 어떻게 해야 합니까?](https://repost.aws/knowledge-center/cloudwatch-logs-throttling)를 참조하세요.
### CloudWatch를 사용하여 로깅하는 데 필요한 권한
작업에서 Amazon CloudWatch로 로그 데이터를 전송하려면 먼저 작업 실행 역할에 대한 권한 정책에 다음 권한을 포함시킵니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:DescribeLogGroups"
],
"Resource": [
"arn:aws:logs:*:123456789012:*"
],
"Sid": "AllowLOGSDescribeloggroups"
},
{
"Effect": "Allow",
"Action": [
"logs:PutLogEvents",
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:DescribeLogStreams"
],
"Resource": [
"arn:aws:logs:*:123456789012:log-group:my-log-group-name:*"
],
"Sid": "AllowLOGSPutlogevents"
}
]
}
```
------
### AWS CLI
에서 EMR Serverless에 대한 로그를 저장하도록 Amazon CloudWatch를 설정하려면 작업 실행을 시작할 때 `cloudWatchLoggingConfiguration` 구성을 AWS CLI사용합니다. 이를 수행하려면 다음 구성 재정의를 제공합니다. 선택적으로 로그 그룹 이름, 로그 스트림 접두사 이름, 로그 유형 및 암호화 키 ARN도 제공합니다.
선택적 값을 지정하지 않으면 CloudWatch는 기본 로그 스트림 `/applications/applicationId/jobs/jobId/worker-type`을 사용하여 로그를 기본 로그 그룹 `/aws/emr-serverless`에 게시합니다.
EMR Serverless 릴리스 7.1.0 이상에서는 스트리밍 작업 및 배치 작업에 대한 재시도를 지원합니다. 작업에 대한 재시도를 활성화하면 EMR Serverless는 로그 경로 접두사에 시도 번호를 자동으로 추가하므로, 로그를 효과적으로 식별하고 추적할 수 있습니다.
```
'/applications//jobs//attempts//worker-type'
```
다음에서는 EMR Serverless의 기본 설정으로 Amazon CloudWatch 로깅을 활성화하는 데 필요한 최소 구성을 보여줍니다.
```
{
"monitoringConfiguration": {
"cloudWatchLoggingConfiguration": {
"enabled": true
}
}
}
```
다음 예제에서는 EMR Serverless에 대해 Amazon CloudWatch 로깅을 켤 때 지정하는 모든 필수 및 선택적 구성을 보여줍니다. 지원되는 `logTypes` 값은 다음 예제에 나열되어 있습니다.
```
{
"monitoringConfiguration": {
"cloudWatchLoggingConfiguration": {
"enabled": true, // Required
"logGroupName": "Example_logGroup", // Optional
"logStreamNamePrefix": "Example_logStream", // Optional
"encryptionKeyArn": "key-arn", // Optional
"logTypes": {
"SPARK_DRIVER": ["stdout", "stderr"] //List of values
}
}
}
}
```
기본적으로 EMR Serverless는 드라이버 stdout 및 stderr 로그만 CloudWatch에 게시합니다. 다른 로그를 원하는 경우 `logTypes` 필드를 사용하여 컨테이너 역할 및 해당 로그 유형을 지정합니다.
다음 목록에서는 `logTypes` 구성에 지정할 수 있는 지원되는 워커 유형을 보여줍니다.
**Spark**
+ `SPARK_DRIVER : ["STDERR", "STDOUT"]`
+ `SPARK_EXECUTOR : ["STDERR", "STDOUT"]`
**Hive**
+ `HIVE_DRIVER : ["STDERR", "STDOUT", "HIVE_LOG", "TEZ_AM"]`
+ `TEZ_TASK : ["STDERR", "STDOUT", "SYSTEM_LOGS"]`
# 로그 교체
Amazon EMR Serverless는 Spark 애플리케이션 로그 및 이벤트 로그를 교체할 수 있습니다. 로그 교체는 모든 디스크 공간을 차지할 수 있는 대용량 로그 파일을 생성하는 장기 실행 작업의 문제를 해결하는 데 도움이 됩니다. 로그를 교체하면 디스크 스토리지를 절약하고 디스크에 남은 추가 공간이 없어서 실패하는 작업 수를 줄일 수 있습니다.
로그 교체는 기본적으로 활성화되어 있으며, Spark 작업에만 사용할 수 있습니다.
**Spark 이벤트 로그**
**참고**
Spark 이벤트 로그 교체는 모든 Amazon EMR 릴리스 레이블에서 사용할 수 있습니다.
EMR Serverless는 단일 이벤트 로그 파일을 생성하는 대신, 이벤트 로그를 정기적으로 교체하고 이전 이벤트 로그 파일을 제거합니다. 로그 교체는 S3 버킷에 업로드된 로그에 영향을 주지 않습니다.
**Spark 애플리케이션 로그**
**참고**
Spark 애플리케이션 로그 교체는 모든 Amazon EMR 릴리스 레이블에서 사용할 수 있습니다.
또한 EMR Serverless는 `stdout` 및 `stderr` 파일과 같은 드라이버 및 실행기에 대한 Spark 애플리케이션 로그도 교체합니다. Spark 기록 서버 및 Live UI 링크를 사용하여 Studio에서 로그 링크를 선택해 최신 로그 파일에 액세스할 수 있습니다. 로그 파일은 최신 로그의 잘린 버전입니다. 이전의 교체된 로그를 보려면 로그를 저장할 때 Amazon S3 위치를 지정합니다. 자세한 내용은 [Amazon S3 버킷을 사용하는 EMR Serverless에 대한 로깅](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/logging.html#jobs-log-storage-s3-buckets)을 참조하세요.
다음 위치에서 최신 로그 파일을 찾을 수 있습니다. EMR Serverless는 15초마다 파일을 새로 고칩니다. 이러한 파일의 범위는 0MB\$1128MB입니다.
```
/applications//jobs//SPARK_DRIVER/stderr.gz
```
다음 위치에는 이전의 교체된 파일이 포함되어 있습니다. 각 파일은 128MB입니다.
```
/applications//jobs//SPARK_DRIVER/archived/stderr_.gz
```
동일한 동작이 Spark 실행기에도 적용됩니다. 이 변경 사항은 S3 로깅에만 적용됩니다. 로그 교체 시 Amazon CloudWatch에 업로드된 로그 스트림에 변경 사항을 도입하지 않습니다.
EMR Serverless 릴리스 7.1.0 이상에서는 스트리밍 및 배치 작업에 대한 재시도를 지원합니다. 작업에서 재시도를 활성화한 경우 EMR Serverless는 해당 작업의 로그 경로에 접두사를 추가하므로 로그를 효과적으로 추적하고 다른 로그와 구분할 수 있습니다. 이 경로에는 교체된 모든 로그가 포함됩니다.
```
'/applications//jobs//attempts//'.
```
# 로그 암호화
## 관리형 스토리지를 사용하는 EMR Serverless 로그 암호화
자체 KMS 키를 사용하여 관리형 스토리지에서 로그를 암호화하려면 작업 실행을 제출할 때 `managedPersistenceMonitoringConfiguration` 구성을 사용합니다.
```
{
"monitoringConfiguration": {
"managedPersistenceMonitoringConfiguration" : {
"encryptionKeyArn": "key-arn"
}
}
}
```
## Amazon S3 버킷을 사용하는 EMR Serverless 로그 암호화
자체 KMS 키를 사용하여 Amazon S3 버킷에서 로그를 암호화하려면 작업 실행을 제출할 때 `s3MonitoringConfiguration` 구성을 사용합니다.
```
{
"monitoringConfiguration": {
"s3MonitoringConfiguration": {
"logUri": "s3://amzn-s3-demo-logging-bucket/logs/",
"encryptionKeyArn": "key-arn"
}
}
}
```
## Amazon CloudWatch를 사용하는 EMR Serverless 로그 암호화
자체 KMS 키로 Amazon CloudWatch에서 로그를 암호화하려면 작업 실행을 제출할 때 `cloudWatchLoggingConfiguration` 구성을 사용합니다.
```
{
"monitoringConfiguration": {
"cloudWatchLoggingConfiguration": {
"enabled": true,
"encryptionKeyArn": "key-arn"
}
}
}
```
## 로그 암호화에 필요한 권한
**Topics**
+ [필요한 사용자 권한](#jobs-log-encryption-permissions-user)
+ [Amazon S3 및 관리형 스토리지에 대한 암호화 키 권한](#jobs-log-encryption-permissions-s3)
+ [Amazon CloudWatch에 대한 암호화 키 권한](#jobs-log-encryption-permissions-cw)
### 필요한 사용자 권한
작업을 제출하거나 로그 또는 애플리케이션 UI를 보는 사용자는 키를 사용할 권한이 있어야 합니다. 사용자, 그룹 또는 역할에 대한 IAM 정책 또는 KMS 키 정책에서 권한을 지정할 수 있습니다. 작업을 제출하는 사용자에게 KMS 키 권한이 없는 경우 EMR Serverless는 작업 실행 제출을 거부합니다.
**예제 키 정책**
다음 키 정책에서는 `kms:GenerateDataKey` 및 `kms:Decrypt`에 대한 권한을 제공합니다.
```
{
"Effect": "Allow",
"Principal":{
"AWS": "arn:aws:iam::111122223333:user/user-name"
},
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "*"
}
```
**IAM 정책 예제**
다음 IAM 정책은 `kms:GenerateDataKey` 및 `kms:Decrypt`에 대한 권한을 제공합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:*:123456789012:key/12345678-1234-1234-1234-123456789012"
],
"Sid": "AllowKMSGeneratedatakey"
}
]
}
```
------
Spark 또는 Tez UI를 시작하려면 사용자, 그룹 또는 역할에 다음과 같이 `emr-serverless:GetDashboardForJobRun` API에 액세스할 수 있는 권한을 부여합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"emr-serverless:GetDashboardForJobRun"
],
"Resource": [
"*"
],
"Sid": "AllowEMRSERVERLESSGetdashboardforjobrun"
}
]
}
```
------
### Amazon S3 및 관리형 스토리지에 대한 암호화 키 권한
관리형 스토리지 또는 S3 버킷에서 자체 암호화 키로 로그를 암호화하는 경우 다음과 같이 KMS 키 권한을 구성합니다.
`emr-serverless.amazonaws.com` 위탁자는 KMS 키에 대한 정책에 다음 권한이 있어야 합니다.
```
{
"Effect": "Allow",
"Principal":{
"Service": "emr-serverless.amazonaws.com"
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": "*"
"Condition": {
"StringLike": {
"aws:SourceArn": "arn:aws:emr-serverless:region:aws-account-id:/applications/application-id"
}
}
}
```
보안 모범 사례로 `aws:SourceArn` 조건 키를 KMS 키 정책에 추가하는 것이 좋습니다. IAM 전역 조건 키 `aws:SourceArn`은 EMR Serverless가 애플리케이션 ARN에 대해서만 KMS 키를 사용하도록 하는 데 도움이 됩니다.
작업 런타임 역할에는 IAM 정책에 다음 권한이 있어야 합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:*:123456789012:key/12345678-1234-1234-1234-123456789012"
],
"Sid": "AllowKMSGeneratedatakey"
}
]
}
```
------
### Amazon CloudWatch에 대한 암호화 키 권한
KMS 키 ARN을 로그 그룹에 연결하려면 작업 런타임 역할에 대해 다음 IAM 정책을 사용합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:AssociateKmsKey"
],
"Resource": [
"arn:aws:logs:*:123456789012:log-group:my-log-group-name:*"
],
"Sid": "AllowLOGSAssociatekmskey"
}
]
}
```
------
Amazon CloudWatch에 KMS 권한을 부여하도록 KMS 키 정책을 구성합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "key-default-1",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": [
"*"
],
"Condition": {
"ArnLike": {
"kms:EncryptionContext:aws:logs:arn": "arn:aws:logs:*:123456789012:*"
}
},
"Sid": "AllowKMSDecrypt"
}
]
}
```
------
# Amazon EMR Serverless에 대한 Apache Log4j2 속성 구성
이 페이지에서는 `StartJobRun`에서 EMR Serverless 작업에 대한 사용자 지정 [Apache Log4j 2.x](https://logging.apache.org/log4j/2.x/) 속성을 구성하는 방법을 설명합니다. 애플리케이션 수준에서 Log4j 분류를 구성하려면 [EMR Serverless에 대한 기본 애플리케이션 구성](default-configs.md) 섹션을 참조하세요.
## Amazon EMR Serverless에 대한 Spark Log4j2 속성 구성
Amazon EMR 릴리스 6.8.0 이상에서는 [Apache Log4j 2.x](https://logging.apache.org/log4j/2.x/) 속성을 사용자 지정하여 세분화된 로그 구성을 지정할 수 있습니다. 그러면 EMR Serverless에서 Spark 작업의 문제 해결이 간소화됩니다. 이러한 속성을 구성하려면 `spark-driver-log4j2` 및 `spark-executor-log4j2` 분류를 사용합니다.
**Topics**
+ [Spark에 대한 Log4j2 분류](#log4j2-spark-class)
+ [Spark에 대한 Log4j2 구성 예제](#log4j2-spark-example)
+ [샘플 Spark 작업의 Log4j2](#log4j2-spark-jobs)
+ [Spark에 대한 Log4j2 고려 사항](#log4j2-spark-considerations)
### Spark에 대한 Log4j2 분류
Spark 로그 구성을 사용자 지정하려면 [https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_ConfigurationOverrides.html#emrserverless-Type-ConfigurationOverrides-applicationConfiguration](https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_ConfigurationOverrides.html#emrserverless-Type-ConfigurationOverrides-applicationConfiguration)에서 다음 분류를 사용합니다. Log4j 2.x 속성을 구성하려면 다음 [https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_Configuration.html#emrserverless-Type-Configuration-properties](https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_Configuration.html#emrserverless-Type-Configuration-properties)를 사용합니다.
**`spark-driver-log4j2`**
이 분류는 드라이버에 대한 `log4j2.properties` 파일의 값을 설정합니다.
**`spark-executor-log4j2`**
이 분류는 실행기에 대한 `log4j2.properties` 파일의 값을 설정합니다.
### Spark에 대한 Log4j2 구성 예제
다음 예제에서는 Spark 드라이버 및 실행기에 대한 Log4j2 구성을 사용자 지정하기 위해 `applicationConfiguration`을 사용해 Spark 작업을 제출하는 방법을 보여줍니다.
작업을 제출할 때 대신 애플리케이션 수준에서 Log4j 분류를 구성하려면 [EMR Serverless에 대한 기본 애플리케이션 구성](default-configs.md) 섹션을 참조하세요.
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"sparkSubmit": {
"entryPoint": "/usr/lib/spark/examples/jars/spark-examples.jar",
"entryPointArguments": ["1"],
"sparkSubmitParameters": "--class org.apache.spark.examples.SparkPi --conf spark.executor.cores=4 --conf spark.executor.memory=20g --conf spark.driver.cores=4 --conf spark.driver.memory=8g --conf spark.executor.instances=1"
}
}'
--configuration-overrides '{
"applicationConfiguration": [
{
"classification": "spark-driver-log4j2",
"properties": {
"rootLogger.level":"error", // will only display Spark error logs
"logger.IdentifierForClass.name": "classpath for setting logger",
"logger.IdentifierForClass.level": "info"
}
},
{
"classification": "spark-executor-log4j2",
"properties": {
"rootLogger.level":"error", // will only display Spark error logs
"logger.IdentifierForClass.name": "classpath for setting logger",
"logger.IdentifierForClass.level": "info"
}
}
]
}'
```
### 샘플 Spark 작업의 Log4j2
다음 코드 샘플에서는 애플리케이션에 대한 사용자 지정 Log4j2 구성을 초기화하는 동안 Spark 애플리케이션을 생성하는 방법을 보여줍니다.
------
#### [ Python ]
**Example - Python에서 Spark 작업에 Log4j2 사용**
```
import os
import sys
from pyspark import SparkConf, SparkContext
from pyspark.sql import SparkSession
app_name = "PySparkApp"
if __name__ == "__main__":
spark = SparkSession\
.builder\
.appName(app_name)\
.getOrCreate()
spark.sparkContext._conf.getAll()
sc = spark.sparkContext
log4jLogger = sc._jvm.org.apache.log4j
LOGGER = log4jLogger.LogManager.getLogger(app_name)
LOGGER.info("pyspark script logger info")
LOGGER.warn("pyspark script logger warn")
LOGGER.error("pyspark script logger error")
// your code here
spark.stop()
```
Spark 작업을 실행하는 경우 드라이버에 대해 Log4j2를 사용자 지정하려면 다음 구성을 사용할 수 있습니다.
```
{
"classification": "spark-driver-log4j2",
"properties": {
"rootLogger.level":"error", // only display Spark error logs
"logger.PySparkApp.level": "info",
"logger.PySparkApp.name": "PySparkApp"
}
}
```
------
#### [ Scala ]
**Example - Scala에서 Spark 작업에 Log4j2 사용**
```
import org.apache.log4j.Logger
import org.apache.spark.sql.SparkSession
object ExampleClass {
def main(args: Array[String]): Unit = {
val spark = SparkSession
.builder
.appName(this.getClass.getName)
.getOrCreate()
val logger = Logger.getLogger(this.getClass);
logger.info("script logging info logs")
logger.warn("script logging warn logs")
logger.error("script logging error logs")
// your code here
spark.stop()
}
}
```
Spark 작업을 실행하는 경우 드라이버에 대해 Log4j2를 사용자 지정하려면 다음 구성을 사용할 수 있습니다.
```
{
"classification": "spark-driver-log4j2",
"properties": {
"rootLogger.level":"error", // only display Spark error logs
"logger.ExampleClass.level": "info",
"logger.ExampleClass.name": "ExampleClass"
}
}
```
------
### Spark에 대한 Log4j2 고려 사항
다음 Log4j2.x 속성은 Spark 프로세스에 대해 구성할 수 없습니다.
+ `rootLogger.appenderRef.stdout.ref`
+ `appender.console.type`
+ `appender.console.name`
+ `appender.console.target`
+ `appender.console.layout.type`
+ `appender.console.layout.pattern`
구성할 수 있는 Log4j2.x 속성에 대한 자세한 내용은 GitHub의 [`log4j2.properties.template` 파일](https://github.com/apache/spark/blob/v3.3.0/conf/log4j2.properties.template)을 참조하세요.
# EMR Serverless 모니터링
이 섹션에서는 Amazon EMR Serverless 애플리케이션 및 작업을 모니터링하는 방법을 다룹니다.
**Topics**
+ [EMR Serverless 애플리케이션 및 작업 모니터링](app-job-metrics.md)
+ [Amazon Managed Service for Prometheus를 사용하여 Spark 지표 모니터링](monitor-with-prometheus.md)
+ [EMR Serverless 사용 지표](monitoring-usage.md)
# EMR Serverless 애플리케이션 및 작업 모니터링
EMR Serverless에 대한 Amazon CloudWatch 지표를 사용하면 1분 CloudWatch 지표를 수신하고 CloudWatch 대시보드에 액세스하여 거의 실시간에 가까운 EMR Serverless 애플리케이션의 작업 및 성능에 액세스할 수 있습니다.
EMR Serverless는 매분 CloudWatch로 지표를 전송합니다. EMR Serverless는 애플리케이션 수준과 작업, 작업자 유형 및 용량 할당 유형 수준에서 이러한 지표를 내보냅니다.
시작하려면 [EMR Serverless GitHub 리포지토리](https://github.com/aws-samples/emr-serverless-samples/tree/main/cloudformation/emr-serverless-cloudwatch-dashboard/)에서 제공하는 EMR Serverless CloudWatch 대시보드 템플릿을 사용하고 배포합니다.
**참고**
[EMR Serverless 대화형 워크로드](interactive-workloads.md)에서는 애플리케이션 수준 모니터링만 활성화되며, 새로운 작업자 유형 차원(`Spark_Kernel`)을 포함합니다. 대화형 워크로드를 모니터링 및 디버깅하기 위해 [EMR Studio Workspace 내](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-studio-debug.html#emr-studio-debug-serverless)에서 로그 및 Apache Spark UI에 액세스할 수 있습니다.
## 지표 모니터링
**중요**
지표 표시를 재구성하여 `ApplicationName` 및 `JobName`을 차원으로 추가합니다. 릴리스 7.10 이상에서는 이전 지표가 더 이상 업데이트되지 않습니다. EMR 릴리스 7.10 이하의 경우 이전 지표를 계속 사용할 수 있습니다.
**현재 차원**
아래 표에서는 `AWS/EMR Serverless` 네임스페이스 내에서 사용할 수 있는 EMR Serverless 차원을 설명합니다.
**EMR Serverless 지표의 차원**
| 차원 | 설명 |
| --- | --- |
| ApplicationId | 애플리케이션 ID를 사용하여 EMR Serverless 애플리케이션의 모든 지표를 필터링합니다. |
| ApplicationName | 이름을 사용하여 EMR Serverless 애플리케이션의 모든 지표를 필터링합니다. 이름이 지정되지 않거나 ASCII가 아닌 문자가 포함된 경우 **[지정되지 않음]**으로 게시됩니다. |
| JobId | EMR Serverless의 모든 메트릭을 작업 실행 ID로 필터링합니다. |
| JobName | 이름을 사용하여 실행되는 EMR Serverless 작업의 모든 메트릭에 대한 필터입니다. 이름이 지정되지 않거나 ASCII가 아닌 문자가 포함된 경우 **[지정되지 않음]**으로 게시됩니다. |
| WorkerType | 주어진 작업자 유형의 모든 지표를 필터링합니다. 예를 들어, Spark 작업에 대해 `SPARK_DRIVER` 및 `SPARK_EXECUTORS`를 필터링할 수 있습니다. |
| CapacityAllocationType | 주어진 용량 할당 유형의 모든 지표를 필터링합니다. 예를 들어, 사전 초기화된 용량에 대해서는 `PreInitCapacity`, 이와 모든 항목에 대해서는 `OnDemandCapacity`를 필터링할 수 있습니다. |
## 애플리케이션 수준 모니터링
Amazon CloudWatch 지표를 사용하여 EMR Serverless 애플리케이션 수준에서 용량 사용량을 모니터링할 수 있습니다. 또한 CloudWatch 대시보드에서 애플리케이션 용량 사용량을 모니터링하도록 단일 보기를 설정할 수도 있습니다.
**EMR Serverless 애플리케이션 지표**
| 지표 | 설명 | 단위 | 측정 기준 |
| --- | --- | --- | --- |
| MaxCPUAllowed | 애플리케이션에 대해 허용되는 최대 CPU. | vCPU | ApplicationId, ApplicationName |
| MaxMemoryAllowed | 애플리케이션에 대해 허용되는 GB 단위의 최대 메모리. | 기가바이트(GB) | ApplicationId, ApplicationName |
| MaxStorageAllowed | 애플리케이션에 대해 허용되는 GB 단위의 최대 스토리지. | 기가바이트(GB) | ApplicationId, ApplicationName |
| CPUAllocated | 할당된 총 vCPU 수. | vCPU | ApplicationId, ApplicationName, WorkerType, CapacityAllocationType |
| IdleWorkerCount | 유휴 상태인 총 작업자 수. | 개수 | ApplicationId, ApplicationName, WorkerType, CapacityAllocationType |
| MemoryAllocated | 할당된 GB 단위의 총 메모리. | 기가바이트(GB) | ApplicationId, ApplicationName, WorkerType, CapacityAllocationType |
| PendingCreationWorkerCount | 생성 보류 중인 총 작업자 수. | 개수 | ApplicationId, ApplicationName, WorkerType, CapacityAllocationType |
| RunningWorkerCount | 애플리케이션에서 사용 중인 총 작업자 수. | 개수 | ApplicationId, ApplicationName, WorkerType, CapacityAllocationType |
| StorageAllocated | 할당된 GB 단위의 총 디스크 스토리지. | 기가바이트(GB) | ApplicationId, ApplicationName, WorkerType, CapacityAllocationType |
| TotalWorkerCount | 사용 가능한 총 작업자 수. | 개수 | ApplicationId, ApplicationName, WorkerType, CapacityAllocationType |
## 작업 수준 모니터링
Amazon EMR Serverless는 1분마다 Amazon CloudWatch 로 다음과 같은 작업 수준 지표를 전송합니다. 작업 실행 상태별로 집계 작업 실행의 지표 값에 액세스할 수 있습니다. 각 지표의 단위는 *개수*입니다.
**EMR Serverless 작업 수준 지표**
| 지표 | 설명 | 측정 기준 |
| --- | --- | --- |
| SubmittedJobs | 제출됨 상태의 최대 작업 수. | ApplicationId, ApplicationName |
| PendingJobs | 보류 중 상태의 작업 수. | ApplicationId, ApplicationName |
| ScheduledJobs | 예약된 상태의 작업 수. | ApplicationId, ApplicationName |
| RunningJobs | 실행 중 상태의 작업 수. | ApplicationId, ApplicationName |
| SuccessJobs | 성공 상태의 작업 수. | ApplicationId, ApplicationName |
| FailedJobs | 실패 상태의 작업 수. | ApplicationId, ApplicationName |
| CancellingJobs | 취소 중 상태의 작업 수. | ApplicationId, ApplicationName |
| CancelledJobs | 취소됨 상태의 작업 수. | ApplicationId, ApplicationName |
엔진별 애플리케이션 UI를 사용하여 EMR Serverless의 실행 중인 작업 및 완료된 작업에 대한 엔진별 지표를 모니터링할 수 있습니다. 실행 중인 작업의 UI에 접근하면 실시간 업데이트가 적용된 라이브 애플리케이션 UI가 표시됩니다. 완료된 작업의 UI에 접근하면 영구 앱 UI가 표시됩니다.
**작업 실행**
EMR Serverless의 실행 중인 작업에 대해서는 엔진별 지표를 제공하는 실시간 인터페이스에 액세스할 수 있습니다. Apache Spark UI 또는 Hive Tez UI를 사용하여 작업을 모니터링하고 디버깅할 수 있습니다. 이러한 UI에 액세스하려면 EMR Studio 콘솔을 사용하거나 AWS Command Line Interface를 사용하여 보안 URL 엔드포인트를 요청합니다.
**작업 완료됨**
완료된 EMR Serverless 작업의 경우 Spark 기록 서버 또는 영구 Hive Tez UI를 사용하여 Spark 또는 Hive 작업 실행에 대한 작업 세부 정보, 단계, 태스크 및 지표에 액세스할 수 있습니다. 이러한 UI에 액세스하려면 EMR Studio 콘솔을 사용하거나 AWS Command Line Interface를 사용하여 보안 URL 엔드포인트를 요청합니다.
## 작업 작업자 수준 모니터링
Amazon EMR Serverless는 `AWS/EMRServerless` 네임스페이스 및 `Job Worker Metrics` 지표 그룹에서 사용할 수 있는 다음과 같은 작업 작업자 수준 지표를 Amazon CloudWatch로 전송합니다. EMR Serverless는 작업 수준, 작업자 유형 및 용량 할당 유형 수준에서 작업이 실행되는 동안 개별 작업자로부터 데이터 포인트를 수집합니다. `ApplicationId`를 차원으로 사용하여 동일한 애플리케이션에 속하는 여러 작업을 모니터링할 수 있습니다.
**참고**
Amazon CloudWatch 콘솔에서 지표를 볼 때 EMR Serverless 작업에서 사용하는 총 CPU 및 메모리를 보려면 통계를 합계로, 기간을 1분으로 사용합니다.
**EMR Serverless 작업 작업자 수준 지표**
| 지표 | 설명 | 단위 | 측정 기준 |
| --- | --- | --- | --- |
| WorkerCpuAllocated | 작업 실행에서 작업자에 대해 할당된 총 vCPU 코어 수. | vCPU | JobId, JobName, ApplicationId, ApplicationName, WorkerType, 및 CapacityAllocationType |
| WorkerCpuUsed | 작업 실행에서 작업자가 활용하는 총 vCPU 코어 수. | vCPU | JobId, JobName, ApplicationId, ApplicationName, WorkerType, 및 CapacityAllocationType |
| WorkerMemoryAllocated | 작업 실행에서 작업자에 대해 할당된 GB 단위의 총 메모리. | 기가바이트(GB) | JobId, JobName, ApplicationId, ApplicationName, WorkerType, 및 CapacityAllocationType |
| WorkerMemoryUsed | 작업 실행에서 작업자가 활용하는 GB 단위의 총 메모리. | 기가바이트(GB) | JobId, JobName, ApplicationId, ApplicationName, WorkerType, 및 CapacityAllocationType |
| WorkerEphemeralStorageAllocated | 작업 실행에서 작업자에 대해 할당된 임시 스토리지의 바이트 수. | 기가바이트(GB) | JobId, JobName, ApplicationId, ApplicationName, WorkerType, 및 CapacityAllocationType |
| WorkerEphemeralStorageUsed | 작업 실행에서 작업자가 활용하는 임시 스토리지의 바이트 수. | 기가바이트(GB) | JobId, JobName, ApplicationId, ApplicationName, WorkerType, 및 CapacityAllocationType |
| WorkerStorageReadBytes | 작업 실행에서 작업자가 스토리지에서 읽은 바이트 수. | 바이트 | JobId, JobName, ApplicationId, ApplicationName, WorkerType, 및 CapacityAllocationType |
| WorkerStorageWriteBytes | 작업 실행에서 작업자의 스토리지에 쓴 바이트 수. | 바이트 | JobId, JobName, ApplicationId, ApplicationName, WorkerType, 및 CapacityAllocationType |
아래 단계에서는 다양한 유형의 지표에 액세스하는 방법을 설명합니다.
------
#### [ Console ]
**콘솔을 사용하여 애플리케이션 UI에 액세스하는 방법**
1. [콘솔에서 시작하기](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/getting-started.html#gs-console)의 지침에 따라 EMR Studio에서 EMR Serverless 애플리케이션으로 이동합니다.
1. 실행 중인 작업에 대한 엔진별 애플리케이션 UI 및 로그에 액세스하려면 다음을 수행합니다.
1. `RUNNING` 상태의 작업을 선택합니다.
1. **애플리케이션 세부 정보** 페이지에서 작업을 선택하거나 작업에 대한 **작업 세부 정보** 페이지로 이동합니다.
1. **UI 표시** 드롭다운 메뉴에서 **Spark UI** 또는 **Hive Tez UI**를 선택하여 작업 유형에 맞는 애플리케이션 UI로 이동합니다.
1. Spark 엔진 로그에 액세스하려면 Spark UI의 **실행기** 탭으로 이동하여 드라이버의 **로그** 링크를 선택합니다. Hive 엔진 로그에 액세스하려면 Hive Tez UI에서 적절한 DAG에 대한 **로그** 링크를 선택합니다.
1. 완료된 작업에 대한 엔진별 애플리케이션 UI 및 로그에 액세스하려면 다음을 수행합니다.
1. `SUCCESS` 상태의 작업을 선택합니다.
1. 애플리케이션의 **애플리케이션 세부 정보** 페이지에서 작업을 선택하거나 작업의 **작업 세부 정보** 페이지로 이동합니다.
1. **UI 표시** 드롭다운 메뉴에서 **Spark 기록 서버** 또는 **영구 Hive Tez UI**를 선택하여 작업 유형에 맞는 애플리케이션 UI로 이동합니다.
1. Spark 엔진 로그에 액세스하려면 Spark UI의 **실행기** 탭으로 이동하여 드라이버의 **로그** 링크를 선택합니다. Hive 엔진 로그에 액세스하려면 Hive Tez UI에서 적절한 DAG에 대한 **로그** 링크를 선택합니다.
------
#### [ AWS CLI ]
**를 사용하여 애플리케이션 UI에 액세스하려면 AWS CLI**
+ 실행 중인 작업과 완료된 작업에 대해 애플리케이션 UI에 액세스하는 데 사용할 수 있는 URL을 생성하려면 `GetDashboardForJobRun` API를 직접 호출합니다.
```
aws emr-serverless get-dashboard-for-job-run /
--application-id /
--job-run-id
```
생성하는 URL은 1시간 동안 유효합니다.
------
# Amazon Managed Service for Prometheus를 사용하여 Spark 지표 모니터링
Amazon EMR 릴리스 7.1.0 이상에서는 Amazon Managed Service for Prometheus에 EMR Serverless를 통합하여 EMR Serverless 작업 및 애플리케이션에 대한 Apache Spark 지표를 수집할 수 있습니다. 이 통합은 콘솔, AWS EMR Serverless API 또는를 사용하여 작업을 제출하거나 애플리케이션을 생성할 때 사용할 수 있습니다 AWS CLI.
## 사전 조건
Amazon Managed Service for Prometheus에 Spark 지표를 전달하려면 먼저 다음 사전 조건을 완료합니다.
+ [Amazon Managed Service for Prometheus WorkSpace를 생성합니다.](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html) 이 Workspace는 수집 엔드포인트 역할을 합니다. **엔드포인트 - 원격 쓰기 URL**에 표시되는 URL을 기록합니다. EMR Serverless 애플리케이션을 생성하는 경우 URL을 지정해야 합니다.
+ 모니터링 목적으로 Amazon Managed Service for Prometheus에 작업에 대한 액세스 권한을 부여하려면 작업 실행 역할에 다음 정책을 추가합니다.
```
{
"Sid": "AccessToPrometheus",
"Effect": "Allow",
"Action": ["aps:RemoteWrite"],
"Resource": "arn:aws:aps:::workspace/"
}
```
## 설정
**AWS 콘솔을 사용하여 Amazon Managed Service for Prometheus와 통합된 애플리케이션을 생성하려면**
1. 애플리케이션을 생성하려면 [Amazon EMR Serverless 시작하기](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/getting-started.html )를 참조하세요.
1. 애플리케이션을 생성하는 동안 **사용자 지정 설정 사용**을 선택한 다음, 구성하려는 필드에 정보를 지정하여 애플리케이션을 구성합니다.
1. **애플리케이션 로그 및 지표**에서 **Amazon Managed Service for Prometheus에 엔진 지표 전달**을 선택한 다음, 원격 쓰기 URL을 지정합니다.
1. 원하는 다른 구성 설정을 지정한 다음, **애플리케이션 생성 및 시작**을 선택합니다.
** AWS CLI 또는 EMR Serverless API 사용**
AWS CLI 또는 `create-application` `start-job-run` 명령을 실행할 때 또는 EMR Serverless API를 사용하여 EMR Serverless 애플리케이션을 Amazon Managed Service for Prometheus와 통합할 수도 있습니다.
------
#### [ create-application ]
```
aws emr-serverless create-application \
--release-label emr-7.1.0 \
--type "SPARK" \
--monitoring-configuration '{
"prometheusMonitoringConfiguration": {
"remoteWriteUrl": "https://aps-workspaces..amazonaws.com/workspaces//api/v1/remote_write"
}
}'
```
------
#### [ start-job-run ]
```
aws emr-serverless start-job-run \
--application-id \
--execution-role-arn \
--job-driver '{
"sparkSubmit": {
"entryPoint": "local:///usr/lib/spark/examples/src/main/python/pi.py",
"entryPointArguments": ["10000"],
"sparkSubmitParameters": "--conf spark.dynamicAllocation.maxExecutors=10"
}
}' \
--configuration-overrides '{
"monitoringConfiguration": {
"prometheusMonitoringConfiguration": {
"remoteWriteUrl": "https://aps-workspaces..amazonaws.com/workspaces//api/v1/remote_write"
}
}
}'
```
------
명령에 `prometheusMonitoringConfiguration`을 포함하면 EMR Serverless가 Spark 지표를 수집하고 Amazon Managed Service for Prometheus의 `remoteWriteUrl` 엔드포인트에 쓰는 에이전트와 함께 Spark 작업을 실행해야 함을 나타냅니다. 그런 다음, 시각화, 알림 및 분석을 위해 Amazon Managed Service for Prometheus의 Spark 지표를 사용할 수 있습니다.
## 고급 구성 속성
EMR Serverless는 Spark 내 구성 요소(`PrometheusServlet`)를 사용하여 Spark 지표를 수집하고 성능 데이터를 Amazon Managed Service for Prometheus와 호환되는 데이터로 변환합니다. 기본적으로 EMR Serverless는 Spark에서 기본값을 설정하고 `PrometheusMonitoringConfiguration`을 사용하여 작업을 제출할 때 드라이버 및 실행기 지표를 구문 분석합니다.
다음 표에서는 Amazon Managed Service for Prometheus로 지표를 전송하는 Spark 작업을 제출하는 경우 구성할 수 있는 모든 속성을 설명합니다.
| Spark 속성 | 기본값 | 설명 |
| --- | --- | --- |
| spark.metrics.conf.\$1.sink.prometheusServlet.class | org.apache.spark.metrics.sink.PrometheusServlet | Spark가 Amazon Managed Service for Prometheus로 지표를 전송하는 데 사용하는 클래스. 기본 동작을 재정의하려면 사용자 지정 클래스를 지정합니다. |
| spark.metrics.conf.\$1.source.jvm.class | org.apache.spark.metrics.source.JvmSource | Spark가 기본 Java 가상 머신에서 중요한 지표를 수집하고 전송하는 데 사용하는 클래스. JVM 지표 수집을 중지하려면 빈 문자열(예: `""`)로 설정하여 이 속성을 비활성화합니다. 기본 동작을 재정의하려면 사용자 지정 클래스를 지정합니다. |
| spark.metrics.conf.driver.sink.prometheusServlet.path | /metrics/prometheus | Amazon Managed Service for Prometheus가 드라이버에서 지표를 수집하는 데 사용하는 고유한 URL. 기본 동작을 재정의하려면 자체 경로를 지정합니다. 드라이버 지표 수집을 중지하려면 빈 문자열(예: `""`)로 설정하여 이 속성을 비활성화합니다. |
| spark.metrics.conf.executor.sink.prometheusServlet.path | /metrics/executor/prometheus | Amazon Managed Service for Prometheus가 실행기에서 지표를 수집하는 데 사용하는 고유한 URL. 기본 동작을 재정의하려면 자체 경로를 지정합니다. 실행기 지표 수집을 중지하려면 빈 문자열(예: `""`)로 설정하여 이 속성을 비활성화합니다. |
Spark 지표에 대한 자세한 내용은 [Apache Spark metrics](https://spark.apache.org/docs/3.5.0/monitoring.html#metrics)를 참조하세요.
## 고려 사항 및 제한 사항
Amazon Managed Service for Prometheus를 사용하여 EMR Serverless에서 지표를 수집하는 경우 다음 고려 사항 및 제한 사항을 고려합니다.
+ [Amazon Managed Service for Prometheus가 정식 출시된AWS 리전](https://docs.aws.amazon.com/general/latest/gr/prometheus-service.html)에서만 EMR Serverless에서 Amazon Managed Service for Prometheus 사용에 대한 지원이 제공됩니다.
+ Amazon Managed Service for Prometheus에서 Spark 지표를 수집하기 위해 에이전트를 실행하는 경우 작업자의 리소스가 더 필요합니다. vCPU 작업자 한 명과 같이 더 작은 작업자 크기를 선택하면 작업 실행 시간이 늘어날 수 있습니다.
+ EMR Serverless에서 Amazon Managed Service for Prometheus 사용 지원은 Amazon EMR 릴리스 7.1.0 이상에서만 사용 가능합니다.
+ 지표를 수집하려면 EMR Serverless를 실행하는 동일한 계정에 Amazon Managed Service for Prometheus를 배포해야 합니다.
# EMR Serverless 사용 지표
Amazon CloudWatch 사용 지표를 사용하여 계정에서 사용하는 리소스에 대한 가시성을 제공할 수 있습니다. 이러한 지표를 사용하여 CloudWatch 그래프 및 대시보드에서 서비스 사용량을 시각화합니다.
EMR Serverless 사용 지표는 서비스 할당량에 해당합니다. 사용량이 서비스 할당량에 가까워지면 경고하는 경보를 구성할 수 있습니다. 자세한 내용은 *CloudWatch 사용 설명서*의 [Service Quotas 및 Amazon CloudWatch 경보](https://docs.aws.amazon.com/servicequotas/latest/userguide/configure-cloudwatch.html)를 참조하세요.
EMR Serverless Service Quotas에 대한 자세한 내용은 [EMR Serverless에 대한 엔드포인트 및 할당량](endpoints-quotas.md) 섹션을 참조하세요.
## EMR Serverless에 대한 서비스 할당량 사용 지표
EMR Serverless는 `AWS/Usage` 네임스페이스에서 다음과 같은 서비스 할당량 사용 지표를 게시합니다.
****
| 지표 | 설명 |
| --- | --- |
| `ResourceCount` | 계정에서 실행 중인 지정된 리소스의 총 수. 리소스는 지표와 연결된 [차원](#usage-metrics-dimensions)으로 정의됩니다. |
## EMR Serverless 서비스 할당량 사용 지표에 대한 차원
다음 차원을 사용하여 EMR Serverless에서 게시하는 사용 지표를 세분화할 수 있습니다.
****
| 측정 기준 | 값 | 설명 |
| --- | --- | --- |
| `Service` | EMR Serverless | 리소스 AWS 서비스 가 포함된의 이름입니다. |
| `Type` | Resource | EMR Serverless에서 보고하는 엔터티의 유형. |
| `Resource` | vCPU | EMR Serverless에서 추적하는 리소스 유형. |
| `Class` | 없음 | EMR Serverless에서 추적하는 리소스의 클래스. |
# 를 사용하여 EMR Serverless 자동화 Amazon EventBridge
Amazon EventBridge 를 사용하여를 자동화 AWS 서비스 하고 애플리케이션 가용성 문제 또는 리소스 변경과 같은 시스템 이벤트에 자동으로 대응할 수 있습니다. EventBridge는 AWS 리소스의 변경 사항을 설명하는 시스템 이벤트 스트림을 거의 실시간으로 제공합니다. 원하는 이벤트만 표시하도록 간단한 규칙을 작성한 후 규칙과 일치하는 이벤트 발생 시 실행할 자동화 작업을 지정할 수 있습니다. EventBridge를 사용하면 자동으로 다음을 수행할 수 있습니다.
+ AWS Lambda 함수 호출
+ Amazon Kinesis Data Streams로 이벤트 릴레이
+ AWS Step Functions 상태 시스템 활성화
+ Amazon SNS 주제 또는 Amazon SQS 대기열 알림
예를 들어, EMR Serverless에서 EventBridge를 사용하는 경우 ETL 작업이 성공하면 AWS Lambda 함수를 활성화하거나 ETL 작업이 실패하면 Amazon SNS 주제를 알릴 수 있습니다.
EMR Serverless는 네 가지 종류의 이벤트를 생성합니다.
+ 애플리케이션 상태 변경 이벤트 - 애플리케이션의 모든 상태 변경을 내보내는 이벤트. 애플리케이션 상태에 대한 자세한 내용은 [애플리케이션 상태](applications.md#application-states) 섹션을 참조하세요.
+ 작업 실행 상태 변경 이벤트 - 작업 실행의 모든 상태 변경을 내보내는 이벤트. 이에 대한 자세한 내용은 [작업 실행 상태](job-states.md) 섹션을 참조하세요.
+ 작업 실행 재시도 이벤트 - Amazon EMR Serverless 릴리스 7.1.0 이상에서 작업 실행의 모든 재시도를 내보내는 이벤트.
+ 작업 리소스 사용률 업데이트 이벤트 - 약 30분 간격으로 작업 실행에 대한 리소스 사용률 업데이트를 내보내는 이벤트.
## 샘플 EMR Serverless EventBridge 이벤트
EMR Serverless에서 보고하는 이벤트에는 다음 예제와 같이 `source`에 `aws.emr-serverless`의 값이 할당됩니다.
**애플리케이션 상태 변경 이벤트**
다음 예제 이벤트에서는 `CREATING` 상태의 애플리케이션을 보여줍니다.
```
{
"version": "0",
"id": "9fd3cf79-1ff1-b633-4dd9-34508dc1e660",
"detail-type": "EMR Serverless Application State Change",
"source": "aws.emr-serverless",
"account": "123456789012",
"time": "2022-05-31T21:16:31Z",
"region": "us-east-1",
"resources": [],
"detail": {
"applicationId": "00f1cbsc6anuij25",
"applicationName": "3965ad00-8fba-4932-a6c8-ded32786fd42",
"arn": "arn:aws:emr-serverless:us-east-1:111122223333:/applications/00f1cbsc6anuij25",
"releaseLabel": "emr-6.6.0",
"state": "CREATING",
"type": "HIVE",
"createdAt": "2022-05-31T21:16:31.547953Z",
"updatedAt": "2022-05-31T21:16:31.547970Z",
"autoStopConfig": {
"enabled": true,
"idleTimeout": 15
},
"autoStartConfig": {
"enabled": true
}
}
}
```
**작업 실행 상태 변경 이벤트**
다음 예제 이벤트에서는 `SCHEDULED` 상태에서 `RUNNING` 상태로 전환되는 작업 실행을 보여줍니다.
```
{
"version": "0",
"id": "00df3ec6-5da1-36e6-ab71-20f0de68f8a0",
"detail-type": "EMR Serverless Job Run State Change",
"source": "aws.emr-serverless",
"account": "123456789012",
"time": "2022-05-31T21:07:42Z",
"region": "us-east-1",
"resources": [],
"detail": {
"jobRunId": "00f1cbn5g4bb0c01",
"applicationId": "00f1982r1uukb925",
"arn": "arn:aws:emr-serverless:us-east-1:123456789012:/applications/00f1982r1uukb925/jobruns/00f1cbn5g4bb0c01",
"releaseLabel": "emr-6.6.0",
"state": "RUNNING",
"previousState": "SCHEDULED",
"createdBy": "arn:aws:sts::123456789012:assumed-role/TestRole-402dcef3ad14993c15d28263f64381e4cda34775/6622b6233b6d42f59c25dd2637346242",
"updatedAt": "2022-05-31T21:07:42.299487Z",
"createdAt": "2022-05-31T21:07:25.325900Z"
}
}
```
**작업 실행 재시도 이벤트**
다음은 작업 실행 재시도 레코드의 예제입니다.
```
{
"version": "0",
"id": "00df3ec6-5da1-36e6-ab71-20f0de68f8a0",
"detail-type": "EMR Serverless Job Run Retry",
"source": "aws.emr-serverless",
"account": "123456789012",
"time": "2022-05-31T21:07:42Z",
"region": "us-east-1",
"resources": [],
"detail": {
"jobRunId": "00f1cbn5g4bb0c01",
"applicationId": "00f1982r1uukb925",
"arn": "arn:aws:emr-serverless:us-east-1:123456789012:/applications/00f1982r1uukb925/jobruns/00f1cbn5g4bb0c01",
"releaseLabel": "emr-6.6.0",
"createdBy": "arn:aws:sts::123456789012:assumed-role/TestRole-402dcef3ad14993c15d28263f64381e4cda34775/6622b6233b6d42f59c25dd2637346242",
"updatedAt": "2022-05-31T21:07:42.299487Z",
"createdAt": "2022-05-31T21:07:25.325900Z",
//Attempt Details
"previousAttempt": 1,
"previousAttemptState": "FAILED",
"previousAttemptCreatedAt": "2022-05-31T21:07:25.325900Z",
"previousAttemptEndedAt": "2022-05-31T21:07:30.325900Z",
"newAttempt": 2,
"newAttemptCreatedAt": "2022-05-31T21:07:30.325900Z"
}
}
```
**작업 리소스 사용률 업데이트**
다음 예제 이벤트에서는 실행 후 터미널 상태로 전환되는 작업에 대한 최종 리소스 사용률 업데이트를 보여줍니다.
```
{
"version": "0",
"id": "00df3ec6-5da1-36e6-ab71-20f0de68f8a0",
"detail-type": "EMR Serverless Job Resource Utilization Update",
"source": "aws.emr-serverless",
"account": "123456789012",
"time": "2022-05-31T21:07:42Z",
"region": "us-east-1",
"resources": [
"arn:aws:emr-serverless:us-east-1:123456789012:/applications/00f1982r1uukb925/jobruns/00f1cbn5g4bb0c01"
],
"detail": {
"applicationId": "00f1982r1uukb925",
"jobRunId": "00f1cbn5g4bb0c01",
"attempt": 1,
"mode": "BATCH",
"createdAt": "2022-05-31T21:07:25.325900Z",
"startedAt": "2022-05-31T21:07:26.123Z",
"calculatedFrom": "2022-05-31T21:07:42.299487Z",
"calculatedTo": "2022-05-31T21:07:30.325900Z",
"resourceUtilizationFinal": true,
"resourceUtilizationForInterval": {
"vCPUHour": 0.023,
"memoryGBHour": 0.114,
"storageGBHour": 0.228
},
"billedResourceUtilizationForInterval": {
"vCPUHour": 0.067,
"memoryGBHour": 0.333,
"storageGBHour": 0
},
"totalResourceUtilization": {
"vCPUHour": 0.023,
"memoryGBHour": 0.114,
"storageGBHour": 0.228
},
"totalBilledResourceUtilization": {
"vCPUHour": 0.067,
"memoryGBHour": 0.333,
"storageGBHour": 0
}
}
}
```
작업이 실행 중 상태로 전환된 경우에만 **startedAt** 필드가 이벤트 내에 표시됩니다.