AgentCore generate memory observability data - Amazon Bedrock AgentCore
Provided memory metricsProvided span dataProvided log data

AgentCore generate memory observability data

For the AgentCore memory resource type, AgentCore outputs metrics to Amazon CloudWatch by default. AgentCore also outputs a default set of spans and logs, if you enable these. See Enabling observability for AgentCore runtime, memory, gateway, built-in tools, and identity resources to learn more about enabling spans and logs.

Refer to the following sections to learn more about the provided observability data for your agent memory stores.

Provided memory metrics

The AgentCore memory resource type provides the following metrics by default.

Latency

The total time elapsed between receiving the request and sending the final response token. Represents complete end-to-end processing of the request.

Invocations

The total number of API requests made to the data plane and control plane. This metric also tracks the number of memory ingestion events.

System Errors

Number of invocations that result in AWS server-side errors.

User Errors

Number of invocations that result in client-side errors.

Errors

Total number of errors that occur while processing API requests in the data plane and control plane. This metric also tracks the total errors that occur during memory ingestion.

Throttles

Number of invocations that the system throttled. Throttled requests count as invocations, errors, and user errors.

Creation Count

Counts the number of created memory events and memory records.

Provided span data

To enhance observability, AgentCore provides structured spans that trace the relationship between events and the memories they generate or access. To enable this span data, you need to instrument your agent code. See Add observability to your Amazon Bedrock AgentCore resources to learn more.

This span data is available in full in CloudWatch Logs and CloudWatch Application Signals. To learn more about viewing observability data, see View observability data for your Amazon Bedrock AgentCore agents.

The following table defines the operations for which spans are created and the attributes for each captured span.

Operation name Span attributes Description

CreateEvent

memory.id , session.id , event.id , actor.id , throttled , error , fault

Creates a new event within a memory session

GetEvent

memory.id , session.id , event.id , actor.id , throttled , error , fault

Retrieves an existing memory event

ListEvents

memory.id , session.id , event.id , actor.id , throttled , error , fault

Lists events within a session

DeleteEvent

memory.id , session.id , event.id , actor.id , throttled , error , fault

Deletes an event from memory

RetrieveMemoryRecords

memory.id , namespace , throttled , error , fault

Retrieves memory records for a given namespace

ListMemoryRecords

memory.id , namespace , throttled , error , fault

Lists available memory records

Provided log data

AgentCore provides structured logs that help you monitor and troubleshoot key AgentCore Memory resource processes. To enable this log data, you need to instrument your agent code. See Add observability to your Amazon Bedrock AgentCore resources to learn more.

AgentCore can output logs to CloudWatch Logs, Amazon S3, or Firehose stream. If you use a CloudWatch Logs destination, these logs are stored under the default log group /aws/vendedlogs/bedrock-agentcore/memory/APPLICATION_LOGS/{memory_id} or under a custom log group starting with /aws/vendedlogs/ . See Enabling observability for AgentCore runtime, memory, gateway, built-in tools, and identity resources to learn more.

When the DeleteMemory operation is called, logs are generated for the start and completion of the deletion process. Any corresponding deletion error logs will be provided with insights into why the call failed.

We also provide logs for various stages in the long-term memory creation process, namely extraction and consolidation. When new short term memory events are provided, AgentCore extracts key concepts from responses to begin the formation of new long-term memory records. Once these have been created, they are integrated with existing memory records to create a unified store of distinct memories.

See the following breakdown to learn how each workflow helps you monitor the formation of new memories:

Extraction logs

  • Start and completion of extraction processing

  • Number of memories successfully extracted

  • Any errors in deserializing or processing input events

Consolidation logs:

  • Start and completion of consolidation processing

  • Number of memories requiring consolidation

  • Success/failure of memory additions and updates

  • Related memory retrieval status

The following table provides a more detailed breakdown of how different memory resource workflows use log fields alongside the log body itself to provide request-specific information.

Workflow name Log fields Description

Extraction

resource_arn, event_timestamp, memory_strategy_id, namespace, actor_id, session_id, event_id, requestId, isError

Analyzes incoming conversations to generate new memories

Consolidation

resource_arn, event_timestamp, memory_strategy_id, namespace, session_id, requestId, isError

Combines extracted memories with existing memories