기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
CloudWatch 로그를 사용하여 지식 베이스를 모니터링하세요
Amazon Bedrock은 지식 베이스에 대한 모든 데이터 통합 작업의 실행을 이해하는 데 도움이 되는 모니터링 시스템을 지원합니다. 다음 섹션에서는 두 가지를 모두 사용하여 Amazon Bedrock 지식 베이스의 로깅 시스템을 활성화하고 구성하는 방법을 다룹니다. AWS Management Console 그리고. CloudWatch API 이 로깅 시스템을 사용하면 지식창고 리소스의 데이터 수집에 대한 가시성을 확보할 수 있습니다.
콘솔을 사용한 지식 기반 로깅
다음을 사용하여 Amazon Bedrock 지식 베이스에 대한 로깅을 활성화하려면 AWS Management Console:
-
지식 기반 생성: 사용 AWS Management Console Amazon Bedrock이 새 지식 베이스를 만들 수 있도록 지원합니다.
-
로그 전송 옵션 추가: 지식 베이스를 생성한 후 지식 베이스를 편집하거나 업데이트하여 로그 전송 옵션을 추가하십시오.
로그 전송 세부 정보 구성: 다음을 포함하여 로그 전달에 대한 세부 정보를 입력합니다.
-
로깅 대상 ( CloudWatch 로그, 아마존 S3, 아마존 데이터 파이어호스 중 하나)
-
( CloudWatch 로그를 로깅 대상으로 사용하는 경우) 로그 그룹 이름
-
(Amazon S3를 로깅 대상으로 사용하는 경우) 버킷 이름
-
(Amazon Data Firehose를 로깅 대상으로 사용하는 경우) Firehose 스트림
-
-
액세스 권한 포함: 콘솔에 로그인한 사용자는 수집된 로그를 선택한 대상에 기록하는 데 필요한 권한이 있어야 합니다.
콘솔에 로그인한 사용자에게 다음 예제 IAM 정책을 첨부하여 CloudWatch 로그를 사용할 때 필요한 권한을 부여할 수 있습니다.
{ "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
다음을 사용하여 Amazon Bedrock 지식 베이스에 대한 로깅을 활성화하려면: CloudWatch API
-
지식창고 활용하기: Amazon Bedrock API 또는 Amazon Bedrock 콘솔을 사용하여 지식베이스를 생성한 후 지식베이스의 Amazon 리소스 이름을 가져오십시오. ARN 를 호출하여 Amazon 리소스 이름을 얻을 수 GetKnowledgeBaseAPI있습니다. 지식창고 Amazon 리소스 이름은 다음 형식을 따릅니다.
arn:aws:bedrock:your-region:your-account-id:knowledge-base/knowledge-base-id
-
전화
PutDeliverySource
: CloudWatch Amazon에서 PutDeliverySourceAPI제공한 정보를 사용하여 지식 베이스의 전송 소스를 생성합니다. 지식 기반 Amazon 리소스 이름을 로 전달합니다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
: CloudWatch Amazon에서 PutDeliveryDestinationAPI제공한 정보를 사용하여 로그를 저장할 위치를 구성합니다. CloudWatch 로그, Amazon S3 또는 Amazon Data Firehose를 로그 저장 대상으로 선택할 수 있습니다. 로그를 저장할 대상 옵션 중 하나의 Amazon 리소스 이름을 지정해야 합니다. 로그를 다음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 정책은 한 계정에서 다른 계정으로 전송할 수 있도록 허용합니다. -
통화
CreateDelivery
: CreateDeliveryAPI통화를 사용하여 이전 단계에서 생성한 목적지에 전송 소스를 연결합니다. 이 API 작업은 배달 소스를 최종 목적지와 연결합니다.{ "deliveryDestinationArn": "string", "deliverySourceName": "string", "tags": { "string" : "string" } }
참고
를 사용하려는 경우 AWS CloudFormation, 다음을 사용할 수 있습니다.
는 ResourceArn
KnowledgeBaseARN
이며 지원되는 로그 LogType
유형이어야 APPLICATION_LOGS
합니다.
지원되는 로그 유형
Amazon Bedrock 지식 베이스는 다음과 같은 로그 유형을 지원합니다.
-
APPLICATION_LOGS
: 데이터 수집 작업 중 특정 파일의 현재 상태를 추적하는 로그입니다.
사용자 권한 및 제한
Amazon Bedrock 지식 베이스에 대한 로깅을 활성화하려면 콘솔에 로그인한 사용자 계정에 대해 다음과 같은 권한이 필요합니다.
-
bedrock:AllowVendedLogDeliveryForResource
— 지식 기반 리소스에 대한 로그 전달을 허용하는 데 필요합니다.특정 IAM 로깅 대상에 필요한 모든 권한이 포함된 예제 역할/권한 정책을 볼 수 있습니다. 다양한 전송 목적지의 벤디드 로그 권한을 참조하고, 특정 IAM 로깅 대상 리소스 (Logs, Amazon S3 또는 Amazon Data Firehose) 에 대한 업데이트 허용을 포함하여 로깅 대상의 역할/권한 정책 예제를 따르십시오. CloudWatch
또한 로그 서비스 할당량 설명서에서 CloudWatch 로그 전송 관련 API 호출을 위한 할당량 한도가 있는지 확인할 수 있습니다. CloudWatch 할당량 한도는 리소스를 호출하거나 리소스를 생성할 수 있는 최대 횟수를 설정합니다. 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
동안 이벤트 상태가 있는 모든 문서를 쿼리할 수 있습니다.
다음은 Logs Insights를 사용하여 CloudWatch 생성된 로그를 디버깅하는 데 사용할 수 있는 몇 가지 일반적인 쿼리입니다.
-
특정 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"