CloudWatch Logs를 사용하여 지식 기반 모니터링 - Amazon Bedrock

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

CloudWatch Logs를 사용하여 지식 기반 모니터링

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

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

AWS Management Console을 사용하여 Amazon Bedrock 지식 기반에 대한 로깅을 활성화하는 방법

  1. 지식 기반 생성: Amazon Bedrock용 AWS Management Console을 사용하여 새 지식 기반을 만듭니다.

  2. 로그 전송 옵션 추가: 지식 기반을 만든 후 지식 기반을 편집하거나 업데이트하여 로그 전송 옵션을 추가합니다.

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

    • 로깅 대상(CloudWatch Logs, Amazon S3, Amazon Data Firehose 중 하나)

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

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

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

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

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

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

CloudWatch API를 사용하여 Amazon Bedrock 지식 기반에 대한 로깅을 활성화하는 방법

  1. 지식 기반의 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

  2. 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" }
  3. PutDeliveryDestination 직접 호출: Amazon CloudWatch에서 제공하는 PutDeliveryDestination API를 사용하여 로그가 저장될 위치를 구성합니다. CloudWatch Logs, Amazon S3 또는 Amazon Data Firehose 중 하나를 로그 저장 대상으로 선택할 수 있습니다. 로그가 저장될 대상 옵션 중 하나의 Amazon 리소스 이름(ARN)을 지정해야 합니다. 로그의 outputFormatjson, 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 정책은 한 계정에서 다른 계정으로의 전송을 허용합니다.

  4. CreateDelivery 직접 호출: CreateDelivery API 직접 호출을 사용하여 이전 단계에서 만든 대상에 전송 소스를 연결합니다. 이 API 작업은 전송 소스를 최종 대상과 연결합니다.

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

AWS CloudFormation을 사용하려면 다음을 사용하세요.

ResourceArnKnowledgeBaseARN이며 LogType은 지원되는 로그 유형의 APPLICATION_LOGS여야 합니다.

지원되는 로그 유형

Amazon Bedrock 지식 기반은 다음 로그 유형을 지원합니다.

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

사용자 권한 및 제한

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

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

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

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

  • METADATA_UPDATE_STARTEDMETADATA_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"