DEV Community

AWS Heroes profile image Vadym Kazulkin
Vadym Kazulkin for AWS Heroes

Posted on

Amazon Bedrock AgentCore Gateway - Part 4 AgentCore Gateway Observability

#aws #serverless #agenticai #mcp

Introduction

In the part 2 and part 3 of this series, we've already explained the CloudWatch metrics provided for Amazon Bedrock CloudWatch metrics.

Those metrics included:

  • Invocations : The total number of requests made to each Data Plane API. Each API call counts as one invocation regardless of the response status.

  • Throttles [429] : The number of requests throttled (status code 429) by the service.

  • SystemErrors [5xx] : The number of requests which failed with 5xx status code.

  • UserErrors [4xx] : The number of requests which failed with 4xx status codes other than 429.

  • Latency : The time elapsed between when the service receives the request and when it begins sending the first response token.

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

  • TargetExecutionTime : The total time it takes to execute the target over Lambda, OpenAPI, etc. This metric helps you to determine the contribution of the target to the total Latency.

  • TargetType : The total number of requests served by each type of target (MCP, Lambda, OpenAPI).

AgentCore Gateway Tracing

Also in the article Amazon Bedrock AgentCore Runtime - Part 3 AgentCore Observability , we introduced AgentCore Observability for the agents hosted on the AgentCore Runtime and explained how to enable this observability. Moreover, we looked into the sessions and especially traces and introduced spans, timeline and trajectory views. The invocation to the AgentCore was displayed as HTTP POST request like this:

If we go to the span data, we see the following information:

The only information we have in this span is the http.url property which ends with /mcp, so we know that this is the exact exposed AgentCore Gateway URL and that's why we know that behind this URL we exposed Open API target (in our case Amazon API Gateway Order API) as a set MCP-compatible tools. But we don't know what requests we're sending to this Gateway Target and what tools we're using. Here is where AgentCore Gateway CloudWatch Log comes to the rescue.

AgentCore Gateway Logs

AgentCore provides logs that help us monitor and troubleshoot key AgentCore gateway resource processes. To enable this log data, we need to create a log destination.

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

AgentCore logs the following information for gateway resources:

  • Start and completion of gateway requests processing
  • Error messages for Target configurations
  • MCP Requests with missing or incorrect authorization headers
  • MCP Requests with incorrect request parameters (tools, method)

We can add log delivery to every created AgentCore Gateway by selecting it and scrolling down to the "Log Delivery" section:

In our case we select "Amazon CloudWatch Logs" as destination and leave "Log type" and "Destination log group" information as suggested:

After pressing "Add" button, Log delivery will be created:

After asking agent some questions (please provide information about the order with the number 12345) we can look into the content of the CloudWatch logs for the AgentCore Gateway.

For example, this log entry:

gives us information about communicating with the particular AgentCore Gateway (see its logged ARN) about the retrieving its complete list of MCP-compatible tools, indicated by the information "Received request for tools/call method".

Let’s look at another log entry:

gives us the information that we asked the same AgentCore Gateway (see its logged ARN) to use the MCP tool with the name DemoOpenAPITargetS3OrderAPI___getOrderById from the Gateway Target with id 7HIDDVWIFP (which in our case is Open API target with Amazon API Gateway Order API behind it), indicated by the information "Executing tool DemoOpenAPITargetS3OrderAPI___getOrderById from target 7HIDDVWIFP".

This is helpful additional information about the invitation, but I’d also wish to have 2 things in addition:

  1. Log input parameters when the MCP-compatible tools are invoked. In our case we pass order id to the DemoOpenAPITargetS3OrderAPI___getOrderById tool invocation.
  2. Optionally, log response as a result of the tool invocation that I have one place to check the whole AgentCore Gateway request and response.

Of course, I can retrieve both information either from the agent log by actively logging the communication with the AgentCore Gateway or by logging in the Gateway Target itself. For example, this can be:

  • in the Lambda function
  • in the exposed Open API in case we have access to it like it's in our case. It's our Amazon API Gateway Order API with the Lambda function behind where we can log the information.

Conclusion

In this article, we explored Amazon Bedrock AgentCore Gateway observability and how to combine available information in the CloudWatch GenAI Observability (agent, session and traces views) for the agents hosted on the AgentCore Runtime with Gateway log delivery to gain the additional visibility to the communication with the AgentCore Gateway.

Also please check out my article series about Amazon Bedrock AgentCore Runtime.

Top comments (0)