기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
Amazon Bedrock은 모니터링 시스템을 지원하므로 지식 기반에 대한 모든 데이터 수집 작업의 실행을 이해하는 데 도움이 됩니다. 다음 섹션에서는 AWS Management Console 및 CloudWatch API를 모두 사용하여 Amazon Bedrock 지식 기반에 대한 로깅 시스템을 활성화하고 구성하는 방법을 다룹니다. 이 로깅 시스템을 사용하여 지식 기반 리소스의 데이터 수집을 확인할 수 있습니다.
콘솔을 사용한 지식 기반 로깅
AWS Management Console을 사용하여 Amazon Bedrock 지식 기반에 대한 로깅을 활성화하는 방법
-
지식 기반 생성: Amazon Bedrock용 AWS Management Console을 사용하여 새 지식 기반을 만듭니다.
-
로그 전송 옵션 추가: 지식 기반을 만든 후 지식 기반을 편집하거나 업데이트하여 로그 전송 옵션을 추가합니다.
로그 전송 세부 정보 구성: 다음을 포함하여 로그 전송에 대한 세부 정보를 입력합니다.
-
로깅 대상(CloudWatch Logs, Amazon S3, Amazon Data Firehose 중 하나)
-
(CloudWatch Logs를 로깅 대상으로 사용하는 경우) 로그 그룹 이름
-
(Amazon S3를 로깅 대상으로 사용하는 경우) 버킷 이름
-
(Amazon Data Firehose를 로깅 대상으로 사용하는 경우) Firehose 스트림
-
-
액세스 권한 포함: 콘솔에 로그인한 사용자는 수집된 로그를 선택한 대상에 쓰는 데 필요한 권한이 있어야 합니다.
다음 예제 IAM 정책을 콘솔에 로그인한 사용자에게 연결하여 CloudWatch Logs를 사용할 때 필요한 권한을 부여할 수 있습니다.
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "logs:CreateDelivery", "Resource": [ "arn:aws:logs:your-region:your-account-id:delivery-source:*", "arn:aws:logs:your-region:your-account-id:delivery:*", "arn:aws:logs:your-region:your-account-id:delivery-destination:*" ] }] } -
전송 상태 확인: 콘솔에서 로그 전송 상태가 '전송 활성화'인지 확인합니다.
CloudWatch API를 사용한 지식 기반 로깅
CloudWatch API를 사용하여 Amazon Bedrock 지식 기반에 대한 로깅을 활성화하는 방법
-
지식 기반의 ARN 가져오기: Amazon Bedrock API 또는 Amazon Bedrock 콘솔을 사용하여 지식 기반을 만든 후, 지식 기반의 Amazon 리소스 이름(ARN)을 가져옵니다. GetKnowledgeBase API를 직접적으로 호출하여 Amazon 리소스 이름(ARN)을 가져올 수 있습니다. 지식 기반 Amazon 리소스 이름(ARN)은 다음 형식을 따릅니다.
arn:aws:bedrock:your-region:your-account-id:knowledge-base/knowledge-base-id -
PutDeliverySource직접 호출: Amazon CloudWatch에서 제공하는 PutDeliverySource 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" } -
PutDeliveryDestination직접 호출: Amazon CloudWatch에서 제공하는 PutDeliveryDestination 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" } }교차 계정을 로그로 전송하는 경우
PutDeliveryDestinationPolicyAPI를 사용하여 대상 계정에 AWS Identity and Access Management (IAM) 정책을 할당해야 합니다. IAM 정책은 한 계정에서 다른 계정으로의 전송을 허용합니다. -
CreateDelivery직접 호출: CreateDelivery API 직접 호출을 사용하여 이전 단계에서 만든 대상에 전송 소스를 연결합니다. 이 API 작업은 전송 소스를 최종 대상과 연결합니다.{ "deliveryDestinationArn": "string", "deliverySourceName": "string", "tags": { "string" : "string" } }
참고
AWS CloudFormation을 사용하려면 다음을 사용하세요.
ResourceArn은 KnowledgeBaseARN이며 LogType은 지원되는 로그 유형의 APPLICATION_LOGS여야 합니다.
지원되는 로그 유형
Amazon Bedrock 지식 기반은 다음 로그 유형을 지원합니다.
-
APPLICATION_LOGS: 데이터 수집 작업 중에 특정 파일의 현재 상태를 추적하는 로그입니다.
사용자 권한 및 제한
Amazon Bedrock 지식 기반에 대한 로깅을 활성화하려면 콘솔에 로그인한 사용자 계정에 다음 권한이 필요합니다.
-
bedrock:AllowVendedLogDeliveryForResource- 지식 기반 리소스에 대한 로그 전달을 허용하는 데 필요합니다.특정 로깅 대상에 필요한 모든 권한이 포함된 IAM 역할/권한 정책의 예를 확인할 수 있습니다. Vended logs permissions for different delivery destinations를 참조하고, 특정 로깅 대상 리소스(CloudWatch Logs, Amazon S3 또는 Amazon Data Firehose)에 대한 업데이트 허용을 포함하여 로깅 대상에 대한 IAM 역할/권한 정책 예제를 따릅니다.
CloudWatch Logs 서비스 할당량 설명서에서 CloudWatch Logs 전송 관련 API 직접 호출을 수행하는 데 할당량 제한이 있는지 확인할 수도 있습니다. 할당량 제한은 API를 직접적으로 호출하거나 리소스를 만들 수 있는 최대 횟수를 설정합니다. 한도를 초과하면 ServiceQuotaExceededException 오류가 발생합니다.
지식 기반 로그 예제
Amazon Bedrock 지식 기반에는 데이터 수집 수준 로그와 리소스 수준 로그가 있습니다.
다음은 데이터 수집 작업 로그의 예제입니다.
{
"event_timestamp": 1718683433639,
"event": {
"ingestion_job_id": "<IngestionJobId>",
"data_source_id": "<IngestionJobId>",
"ingestion_job_status": "INGESTION_JOB_STARTED" | "COMPLETE" | "FAILED" | "CRAWLING_COMPLETED"
"knowledge_base_arn": "arn:aws:bedrock:<region>:<accountId>:knowledge-base/<KnowledgeBaseId>",
"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": "<IngestionJobId>",
"data_source_id": "<IngestionJobId>",
"knowledge_base_arn": "arn:aws:bedrock:<region>:<accountId>:knowledge-base/<KnowledgeBaseId>",
"document_location": {
"type": "S3",
"s3_location": {
"uri": "s3:/<BucketName>/<ObjectKey>"
}
},
"status": "<ResourceStatus>"
"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://<bucketName>/<objectKey>" -
데이터 수집 작업 중에 무시된 모든 문서를 쿼리합니다.
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"
