Skip to main content
Amazon Bedrock model invocations (the Converse, ConverseStream, InvokeModel, and InvokeModelWithResponseStream APIs, plus the OpenAI-compatible APIs on the bedrock-runtime endpoint) don’t send OpenTelemetry traces anywhere by themselves. The recommended way to collect Bedrock telemetry is to instrument the application that calls Bedrock with OpenTelemetry and forward it to Bronto through an OTel Collector. Instrumentation gives you the full GenAI signal — model id, token usage, latency, and prompt/response content — as traces that link to the rest of your application. Bedrock can also write model invocation logs to a CloudWatch log group or Amazon S3 (see Alternatives), but these are per-call log records, not traces.

​
Two requirements

1

Instrument your application

Add the OpenTelemetry SDK and the AWS SDK auto-instrumentation to the service that calls Bedrock. The botocore/AWS SDK instrumentation traces Converse / InvokeModel calls and, on a recent enough version, enriches them with GenAI semantic-convention attributes (token usage, model, finish reason). See Amazon Bedrock LLM observability with OpenTelemetry for the full setup.
2

Run an OTel Collector to forward to Bronto

The instrumented app exports OTLP to a Collector, which adds the Bronto credentials and forwards each signal to Bronto. On AWS the recommended Collector is ADOT, run as a sidecar (ECS / Fargate) or daemonset (EKS).
ADOT — the AWS Distro for OpenTelemetry Collector — receives OTLP from your application and forwards logs, metrics and traces to Bronto over OTLP/HTTP, with consistent service.name / service.namespace identity. Only logs use those attributes for dataset and collection routing. The same sidecar pattern works on the ECS / Fargate and EKS launch types you are likely already running your Bedrock app on. Pair it with application instrumentation for your language:

OpenTelemetry overview

How application instrumentation maps each signal to its Bronto destination.

Python

Most common runtime for Bedrock apps; richest GenAI auto-instrumentation.

Node.js

Instrument a Node.js service that calls the Bedrock APIs.

Java / Go / .NET

All OTLP-capable runtimes export to the same Collector.

​
LLM observability for Bedrock

For the GenAI-specific signal — capturing token usage, model metadata, and prompt/response content following the OpenTelemetry GenAI semantic conventions — see Amazon Bedrock LLM observability under AI assisted observability.

​
Alternatives

  • Model invocation logging — Bedrock’s account-level invocation logging (off by default) writes one JSON record per call to a CloudWatch log group and/or Amazon S3. Each record holds the model id, the caller’s IAM identity, input and output token counts, and the request and response bodies up to 100 KB. Forward the log group with the CloudWatch Log Forwarder, or the S3 objects with the S3 Log Forwarder. This needs no code changes, but it doesn’t produce traces. Calls through the bedrock-mantle endpoint aren’t logged.
  • Self-managed OTel Collector — when you need custom processors, sampling, or fan-out to multiple backends alongside Bronto.
  • Direct export — for local development or short-lived jobs you can export OTLP straight from the SDK to Bronto with an API key; see the direct export section on any language page.
See Ingesting AWS Data into Bronto for the full service-to-method mapping.

​
References