本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
使用 CloudWatch 記錄監控知識庫
Amazon 基岩支援監控系統,協助您了解知識庫中任何資料擷取任務的執行情況。以下各節說明如何使用這兩種方式啟用和設定 Amazon 基岩知識庫的記錄系統 AWS Management Console 和 CloudWatch API。您可以透過此記錄系統,瞭解知識庫資源的資料擷取。
使用主控台記錄知識庫
若要啟用 Amazon 基岩知識庫的記錄,請使用 AWS Management Console:
-
建立知識庫:使用 AWS Management Console 為 Amazon 基岩創建一個新的知識庫。
-
新增記錄傳送選項:建立知識庫之後,請編輯或更新知識庫,以新增記錄傳送選項。
設定記錄傳送詳細資訊:輸入記錄傳送的詳細資料,包括:
-
記錄目的地 ( CloudWatch 日誌、Amazon S3、Amazon 資料 Firehose)
-
(如果使用記 CloudWatch 錄檔做為記錄目的地) 記錄群組名稱
-
(如果使用 Amazon S3 做為記錄目的地) 儲存貯體名稱
-
(如果使用 Amazon 數據防火軟管作為日誌記錄目的地)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 基岩知識庫的日誌記錄: CloudWatch API
-
掌握您ARN的知識庫:使用 Amazon 基岩API或 Amazon 基岩主控台建立知識庫後,取得知識庫的 Amazon 資源名稱。您可以通過調用獲取 Amazon 資源名稱GetKnowledgeBaseAPI。知識庫 Amazon 資源名稱遵循以下格式:
arn:aws:bedrock:your-region:your-account-id:knowledge-base/knowledge-base-id
-
呼叫
PutDeliverySource
:使用 Amazon PutDeliverySourceAPI提供 CloudWatch 的知識庫創建交付源。通過知識庫 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
:使用 Amazon PutDeliveryDestinationAPI提供 CloudWatch 的配置日誌的存儲位置。您可以選擇 CloudWatch 日誌、Amazon S3 或 Amazon 資料 Firehose 做為存放日誌的目的地。您必須指定存放日誌的其中一個目的地選項的 Amazon 資源名稱。您可以選outputFormat
擇記錄為下列其中一項:json
、、plain
、w3c
、raw
、parquet
。以下是將日誌設定為以JSON格式存放在 Amazon S3 儲存貯體中的範例。{ "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 基岩知識庫支援下列日誌類型:
-
APPLICATION_LOGS
:在資料擷取工作期間追蹤特定檔案目前狀態的記錄檔。
使用者權限和限制
若要啟用 Amazon 基岩知識庫的記錄功能,登入主控台的使用者帳戶需要下列許可:
-
bedrock:AllowVendedLogDeliveryForResource
— 允許為知識庫資源傳送記錄檔所需。您可以檢視範例IAM角色/權限原則,其中包含特定記錄目的地的所有必要權限。請參閱不同交付目的地的付費日誌許可,並遵循日誌目的地的IAM角色/權限政策示例,包括允許更新您的特定日誌記錄目的地資源 (無論是 CloudWatch 日誌、Amazon S3 還是 Amazon Data Firehose)。
您也可以在記錄服務配額說明文件中,檢查是否有任何配額限制來進行CloudWatch 記 CloudWatch 錄傳送相關API呼叫。配額限制可設定您可呼叫API或建立資源的次數上限。如果超過限制,則會導致ServiceQuotaExceededException
錯誤。
知識庫記錄的範例
有適用於 Amazon 基岩知識庫的資料擷取層級日誌和資源層級日誌。
以下是資料擷取工作記錄的範例。
{ "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 記錄檔:
-
查詢針對特定 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"