기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# CloudWatch Logs를 사용하여 지식 기반 모니터링
Amazon Bedrock은 모니터링 시스템을 지원하므로 지식 기반에 대한 모든 데이터 수집 작업의 실행을 이해하는 데 도움이 됩니다. 다음 섹션에서는 및 CloudWatch API를 모두 사용하여 Amazon Bedrock 지식 기반에 대한 로깅 시스템을 활성화 AWS Management Console 하고 구성하는 방법을 다룹니다. 이 로깅 시스템을 사용하여 지식 기반 리소스의 데이터 수집을 확인할 수 있습니다.
## 콘솔을 사용한 지식 기반 로깅
AWS Management Console을 사용하여 Amazon Bedrock 지식 기반에 대한 로깅을 활성화하는 방법:
1. **지식 기반 생성**: Amazon Bedrock AWS Management Console 용를 사용하여 [새 지식 기반을 생성합니다](https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-create.html).
1. **로그 전송 옵션 추가**: 지식 기반을 만든 후 지식 기반을 편집하거나 업데이트하여 로그 전송 옵션을 추가합니다.
**참고**
구조화된 데이터 스토어 또는 Kendra GenAI 인덱스를 사용하여 지식 기반을 생성할 때는 로그 전송이 지원되지 않습니다.
**로그 전송 세부 정보 구성**: 다음을 포함하여 로그 전송에 대한 세부 정보를 입력합니다.
+ 로깅 대상(CloudWatch Logs, Amazon S3, Amazon Data Firehose 중 하나)
+ (CloudWatch Logs를 로깅 대상으로 사용하는 경우) 로그 그룹 이름
+ (Amazon S3를 로깅 대상으로 사용하는 경우) 버킷 이름
+ (Amazon Data Firehose를 로깅 대상으로 사용하는 경우) Firehose 스트림
1. **액세스 권한 포함**: 콘솔에 로그인한 사용자는 수집된 로그를 선택한 대상에 쓰는 데 필요한 권한이 있어야 합니다.
다음 예제 IAM 정책을 콘솔에 로그인한 사용자에게 연결하여 CloudWatch Logs를 사용할 때 필요한 권한을 부여할 수 있습니다
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "logs:CreateDelivery",
"Resource": [
"arn:aws:logs:{{us-east-1}}:{{123456789012}}:delivery-source:*",
"arn:aws:logs:{{us-east-1}}:{{123456789012}}:delivery:*",
"arn:aws:logs:{{us-east-1}}:{{123456789012}}:delivery-destination:*"
]
}
]
}
```
------
1. **전송 상태 확인**: 콘솔에서 로그 전송 상태가 “전송 활성화”인지 확인합니다.
## CloudWatch API를 사용한 지식 기반 로깅
CloudWatch API를 사용하여 Amazon Bedrock 지식 기반에 대한 로깅을 활성화하는 방법:
1. **지식 기반의 ARN 가져오기**: Amazon Bedrock API 또는 Amazon Bedrock 콘솔을 사용하여 [지식 기반을 만든](https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-create.html) 후, 지식 기반의 Amazon 리소스 이름(ARN)을 가져옵니다. [GetKnowledgeBase](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_GetKnowledgeBase.html) API를 직접적으로 호출하여 Amazon 리소스 이름(ARN)을 가져올 수 있습니다. 지식 기반 Amazon 리소스 이름(ARN)은 {{arn:aws:bedrock:your-region:your-account-id:knowledge-base/knowledge-base-id}} 형식을 따릅니다
1. **`PutDeliverySource` 직접 호출**: Amazon CloudWatch에서 제공하는 [PutDeliverySource](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliverySource.html) API를 사용하여 지식 기반에 대한 전송 소스를 만듭니다. 지식 기반 Amazon 리소스 이름(ARN)을 `resourceArn`으로 전달합니다. `logType`은 수집되는 로그 유형을 `APPLICATION_LOGS`로 지정합니다. `APPLICATION_LOGS`는 수집 작업 중에 파일의 현재 상태를 추적합니다.
```
{
"logType": "APPLICATION_LOGS",
"name": "my-knowledge-base-delivery-source",
"resourceArn": "arn:aws:bedrock:your-region:your-account-id:knowledge-base/knowledge_base_id"
}
```
1. **`PutDeliveryDestination` 직접 호출**: Amazon CloudWatch에서 제공하는 [PutDeliveryDestination](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html) API를 사용하여 로그가 저장될 위치를 구성합니다. CloudWatch Logs, Amazon S3 또는 Amazon Data Firehose 중 하나를 로그 저장 대상으로 선택할 수 있습니다. 로그가 저장될 대상 옵션 중 하나의 Amazon 리소스 이름(ARN)을 지정해야 합니다. 로그의 `outputFormat`을 `json`, `plain`, `w3c`, `raw`, `parquet` 중 하나로 선택할 수 있습니다. 다음은 Amazon S3 버킷에 JSON 형식으로 저장할 로그를 구성하는 예제입니다.
```
{
"deliveryDestinationConfiguration": {
"destinationResourceArn": "arn:aws:s3:::bucket-name"
},
"name": "string",
"outputFormat": "json",
"tags": {
"key" : "value"
}
}
```
교차 계정 로그를 전송하는 경우 `PutDeliveryDestinationPolicy` API를 사용하여 대상 계정에 AWS Identity and Access Management (IAM) 정책을 할당해야 합니다. IAM 정책은 한 계정에서 다른 계정으로의 전송을 허용합니다.
1. **`CreateDelivery` 직접 호출**: [CreateDelivery](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateDelivery.html) API 직접 호출을 사용하여 이전 단계에서 만든 대상에 전송 소스를 연결합니다. 이 API 작업은 전송 소스를 최종 대상과 연결합니다.
```
{
"deliveryDestinationArn": "string",
"deliverySourceName": "string",
"tags": {
"string" : "string"
}
}
```
**참고**
를 사용하려면 다음을 사용할 CloudFormation수 있습니다.
[Delivery](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-delivery.html)
[DeliveryDestination](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-deliverydestination.html)
[DeliverySource](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-deliverysource.html)
`ResourceArn`은 `KnowledgeBaseARN`이며 `LogType`은 지원되는 로그 유형의 `APPLICATION_LOGS`여야 합니다.
## 지원되는 로그 유형
Amazon Bedrock 지식 기반은 다음 로그 유형을 지원합니다.
+ `APPLICATION_LOGS`: 데이터 수집 작업 중에 특정 파일의 현재 상태를 추적하는 로그입니다.
## 사용자 권한 및 제한
Amazon Bedrock 지식 기반에 대한 로깅을 활성화하려면 콘솔에 로그인한 사용자 계정에 다음 권한이 필요합니다.
1. `bedrock:AllowVendedLogDeliveryForResource` - 지식 기반 리소스에 대한 로그 전달을 허용하는 데 필요합니다.
특정 로깅 대상에 필요한 모든 권한이 포함된 IAM 역할/권한 정책의 예를 확인할 수 있습니다. [다양한 전달 대상에 대한 제공 로그 권한](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-vended-logs-permissions-V2)을 참조하고, 특정 로깅 대상 리소스(CloudWatch Logs, Amazon S3 또는 Amazon Data Firehose)에 대한 업데이트 허용을 포함하여 로깅 대상에 대한 IAM 역할/권한 정책 예제를 따릅니다.
[CloudWatch Logs 서비스 할당량 설명서](https://docs.aws.amazon.com/general/latest/gr/cwl_region.html)에서 CloudWatch Logs 전송 관련 API 직접 호출을 수행하는 데 할당량 제한이 있는지 확인할 수도 있습니다. 할당량 제한은 API를 직접적으로 호출하거나 리소스를 만들 수 있는 최대 횟수를 설정합니다. 한도를 초과하면 `ServiceQuotaExceededException` 오류가 발생합니다.
## 지식 기반 로그 예제
Amazon Bedrock 지식 기반에는 데이터 수집 수준 로그와 리소스 수준 로그가 있습니다.
다음은 데이터 수집 작업 로그의 예제입니다.
```
{
"event_timestamp": 1718683433639,
"event": {
"ingestion_job_id": "",
"data_source_id": "",
"ingestion_job_status": "INGESTION_JOB_STARTED" | "STOPPED" | "COMPLETE" | "FAILED" | "CRAWLING_COMPLETED"
"knowledge_base_arn": "arn:aws:bedrock:::knowledge-base/",
"resource_statistics": {
"number_of_resources_updated": int,
"number_of_resources_ingested": int,
"number_of_resources_scheduled_for_update": int,
"number_of_resources_scheduled_for_ingestion": int,
"number_of_resources_scheduled_for_metadata_update": int,
"number_of_resources_deleted": int,
"number_of_resources_with_metadata_updated": int,
"number_of_resources_failed": int,
"number_of_resources_scheduled_for_deletion": int
}
},
"event_version": "1.0",
"event_type": "StartIngestionJob.StatusChanged",
"level": "INFO"
}
```
다음은 리소스 수준 로그의 예제입니다.
```
{
"event_timestamp": 1718677342332,
"event": {
"ingestion_job_id": "",
"data_source_id": "",
"knowledge_base_arn": "arn:aws:bedrock:::knowledge-base/",
"document_location": {
"type": "S3",
"s3_location": {
"uri": "s3://"
}
},
"status": ""
"status_reasons": String[],
"chunk_statistics": {
"ignored": int,
"created": int,
"deleted": int,
"metadata_updated": int,
"failed_to_create": int,
"failed_to_delete": int,
"failed_to_update_metadata": int
},
},
"event_version": "1.0",
"event_type": "StartIngestionJob.ResourceStatusChanged",
"level": "INFO" | "WARN" | "ERROR"
}
```
리소스의 `status`는 다음 중 하나일 수 있습니다.
+ `SCHEDULED_FOR_INGESTION`, `SCHEDULED_FOR_DELETION`, `SCHEDULED_FOR_UPDATE`, `SCHEDULED_FOR_METADATA_UPDATE`: 이러한 상태 값은 지식 기반의 현재 상태와 데이터 소스의 변경 사항 간의 차이를 계산한 후 리소스 처리가 예약되었음을 나타냅니다.
+ `RESOURCE_IGNORED`: 이 상태 값은 리소스가 처리에서 무시되었음을 나타내며, 그 이유는 `status_reasons` 속성 내에 자세히 설명되어 있습니다.
+ `EMBEDDING_STARTED` 및 `EMBEDDING_COMPLETED`: 이러한 상태 값은 리소스에 대한 벡터 임베딩이 시작되고 완료된 시기를 나타냅니다.
+ `INDEXING_STARTED` 및 `INDEXING_COMPLETED`: 이러한 상태 값은 리소스에 대한 인덱싱이 시작되고 완료된 시기를 나타냅니다.
+ `DELETION_STARTED` 및 `DELETION_COMPLETED`: 이러한 상태 값은 리소스에 대한 삭제가 시작되고 완료된 시기를 나타냅니다.
+ `METADATA_UPDATE_STARTED` 및 `METADATA_UPDATE_COMPLETED`: 이러한 상태 값은 리소스에 대한 메타데이터 업데이트가 시작되고 완료된 시기를 나타냅니다.
+ `EMBEDDING_FAILED`, `INDEXING_FAILED`, `DELETION_FAILED`, `METADATA_UPDATE_FAILED`: 이러한 상태 값은 리소스 처리가 실패했음을 나타내며, 그 이유는 `status_reasons` 속성 내에 자세히 설명되어 있습니다.
+ `INDEXED`, `DELETED`, `PARTIALLY_INDEXED`, `METADATA_PARTIALLY_INDEXED`, `FAILED`: 문서 처리가 완료되면 문서의 최종 상태와 `chunk_statistics` 속성 내 처리 요약이 포함된 로그가 게시됩니다.
## 지식 기반 로그를 디버깅하기 위한 일반적인 쿼리의 예
쿼리를 사용하여 로그와 상호 작용할 수 있습니다. 예를 들어, 문서 또는 데이터를 수집하는 동안 `RESOURCE_IGNORED` 이벤트 상태의 모든 문서를 쿼리할 수 있습니다.
다음은 CloudWatch Logs Insights를 사용하여 생성된 로그를 디버깅하는 데 사용할 수 있는 몇 가지 일반적인 쿼리입니다.
+ 특정 S3 문서에 대해 생성된 모든 로그를 쿼리합니다.
`filter event.document_location.s3_location.uri = "s3:///"`
+ 데이터 수집 작업 중에 무시된 모든 문서를 쿼리합니다.
`filter event.status = "RESOURCE_IGNORED"`
+ 문서의 벡터 임베딩 중에 발생한 모든 예외를 쿼리합니다.
`filter event.status = "EMBEDDING_FAILED"`
+ 문서를 벡터 데이터베이스로 인덱싱하는 동안 발생한 모든 예외를 쿼리합니다.
`filter event.status = "INDEXING_FAILED"`
+ 벡터 데이터베이스에서 문서를 삭제하는 동안 발생한 모든 예외를 쿼리합니다.
`filter event.status = "DELETION_FAILED"`
+ 벡터 데이터베이스에서 문서의 메타데이터를 업데이트하는 동안 발생한 모든 예외를 쿼리합니다.
`filter event.status = "DELETION_FAILED"`
+ 데이터 수집 작업을 실행하는 동안 발생한 모든 예외를 쿼리합니다.
`filter level = "ERROR" or level = "WARN"`