CloudWatch 로그를 사용하여 지식 베이스를 모니터링하세요 - Amazon Bedrock

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

CloudWatch 로그를 사용하여 지식 베이스를 모니터링하세요

Amazon Bedrock은 지식 베이스에 대한 모든 데이터 통합 작업의 실행을 이해하는 데 도움이 되는 모니터링 시스템을 지원합니다. 다음 섹션에서는 두 가지를 모두 사용하여 Amazon Bedrock 지식 베이스의 로깅 시스템을 활성화하고 구성하는 방법을 다룹니다. AWS Management Console 그리고. CloudWatch API 이 로깅 시스템을 사용하면 지식창고 리소스의 데이터 수집에 대한 가시성을 확보할 수 있습니다.

콘솔을 사용한 지식 기반 로깅

다음을 사용하여 Amazon Bedrock 지식 베이스에 대한 로깅을 활성화하려면 AWS Management Console:

  1. 지식 기반 생성: 사용 AWS Management Console Amazon Bedrock이 새 지식 베이스를 만들 수 있도록 지원합니다.

  2. 로그 전송 옵션 추가: 지식 베이스를 생성한 후 지식 베이스를 편집하거나 업데이트하여 로그 전송 옵션을 추가하십시오.

    로그 전송 세부 정보 구성: 다음을 포함하여 로그 전달에 대한 세부 정보를 입력합니다.

    • 로깅 대상 ( CloudWatch 로그, 아마존 S3, 아마존 데이터 파이어호스 중 하나)

    • ( CloudWatch 로그를 로깅 대상으로 사용하는 경우) 로그 그룹 이름

    • (Amazon S3를 로깅 대상으로 사용하는 경우) 버킷 이름

    • (Amazon Data Firehose를 로깅 대상으로 사용하는 경우) Firehose 스트림

  3. 액세스 권한 포함: 콘솔에 로그인한 사용자는 수집된 로그를 선택한 대상에 기록하는 데 필요한 권한이 있어야 합니다.

    콘솔에 로그인한 사용자에게 다음 예제 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:*" ] }] }
  4. 전송 상태 확인: 콘솔에서 로그 전송 상태가 “전송 활성”인지 확인합니다.

를 사용한 지식 기반 로깅 CloudWatch API

다음을 사용하여 Amazon Bedrock 지식 베이스에 대한 로깅을 활성화하려면: CloudWatch API

  1. 지식창고 활용하기: Amazon Bedrock API 또는 Amazon Bedrock 콘솔을 사용하여 지식베이스를 생성한 후 지식베이스의 Amazon 리소스 이름을 가져오십시오. ARN 를 호출하여 Amazon 리소스 이름을 얻을 수 GetKnowledgeBaseAPI있습니다. 지식창고 Amazon 리소스 이름은 다음 형식을 따릅니다.arn:aws:bedrock:your-region:your-account-id:knowledge-base/knowledge-base-id

  2. 전화 PutDeliverySource: CloudWatch Amazon에서 PutDeliverySourceAPI제공한 정보를 사용하여 지식 베이스의 전송 소스를 생성합니다. 지식 기반 Amazon 리소스 이름을 로 전달합니다resourceArn. logTypeAPPLICATION_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" }
  3. 전화 PutDeliveryDestination: CloudWatch Amazon에서 PutDeliveryDestinationAPI제공한 정보를 사용하여 로그를 저장할 위치를 구성합니다. CloudWatch 로그, Amazon S3 또는 Amazon Data Firehose를 로그 저장 대상으로 선택할 수 있습니다. 로그를 저장할 대상 옵션 중 하나의 Amazon 리소스 이름을 지정해야 합니다. 로그를 다음 outputFormat 중 하나로 선택할 수 있습니다.json,plain, w3craw,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 정책은 한 계정에서 다른 계정으로 전송할 수 있도록 허용합니다.

  4. 통화 CreateDelivery: CreateDeliveryAPI통화를 사용하여 이전 단계에서 생성한 목적지에 전송 소스를 연결합니다. 이 API 작업은 배달 소스를 최종 목적지와 연결합니다.

    { "deliveryDestinationArn": "string", "deliverySourceName": "string", "tags": { "string" : "string" } }
참고

를 사용하려는 경우 AWS CloudFormation, 다음을 사용할 수 있습니다.

ResourceArn KnowledgeBaseARN 이며 지원되는 로그 LogType 유형이어야 APPLICATION_LOGS 합니다.

지원되는 로그 유형

Amazon Bedrock 지식 베이스는 다음과 같은 로그 유형을 지원합니다.

  • APPLICATION_LOGS: 데이터 수집 작업 중 특정 파일의 현재 상태를 추적하는 로그입니다.

사용자 권한 및 제한

Amazon Bedrock 지식 베이스에 대한 로깅을 활성화하려면 콘솔에 로그인한 사용자 계정에 대해 다음과 같은 권한이 필요합니다.

  1. 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_STARTEDEMBEDDING_COMPLETED: 이 상태 값은 리소스의 벡터 임베딩이 시작되고 완료된 시기를 나타냅니다.

  • INDEXING_STARTEDINDEXING_COMPLETED: 이 상태 값은 리소스에 대한 인덱싱이 시작되고 완료된 시기를 나타냅니다.

  • DELETION_STARTEDDELETION_COMPLETED: 이 상태 값은 리소스 삭제가 시작되고 완료된 시기를 나타냅니다.

  • METADATA_UPDATE_STARTEDMETADATA_UPDATE_COMPLETED: 이 상태 값은 리소스의 메타데이터 업데이트 시작 및 완료 시기를 나타냅니다.

  • EMBEDDING_FAILED, INDEXING_FAILEDDELETION_FAILED, 및METADATA_UPDATE_FAILED: 이러한 상태 값은 리소스 처리가 실패했음을 나타내며, 이유는 status_reasons 속성 내에 자세히 설명되어 있습니다.

  • INDEXEDDELETED,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"