> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bronto.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Amazon Bedrock Logs, Metrics and Traces

> Collect OpenTelemetry logs, metrics, and traces from applications that call the Amazon Bedrock Converse and InvokeModel APIs via an OTel Collector.

Amazon Bedrock model invocations (the `Converse`, `ConverseStream`, `InvokeModel`, and `InvokeModelWithResponseStream` APIs) do not emit telemetry to Bronto on their own. You collect Bedrock telemetry by **instrumenting the application that calls Bedrock** with OpenTelemetry and forwarding it to Bronto through an **OTel Collector**.

This is different from log-only AWS services: there is no CloudWatch log group or Firehose stream to point at Bronto. The rich GenAI signal — model id, token usage, latency, and prompt/response content — is produced by instrumenting your code.

## Two requirements

<Steps>
  <Step title="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](/ai-features/aws-bedrock) for the full setup.
  </Step>

  <Step title="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](./aws-adot), run as a sidecar (ECS / Fargate) or daemonset (EKS).
  </Step>
</Steps>

## Recommended method

[**ADOT**](./aws-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` routing (see [Data Organization](/Search-and-Visualize/Partitions)). The same sidecar pattern works on the [ECS / Fargate](./aws-ecs) and [EKS](./aws-eks) launch types you are likely already running your Bedrock app on.

Pair it with application instrumentation for your language:

<CardGroup cols={2}>
  <Card title="OpenTelemetry overview" href="/opentelemetry/overview">
    How application instrumentation maps to Bronto datasets and collections.
  </Card>

  <Card title="Python" href="/opentelemetry/python">
    Most common runtime for Bedrock apps; richest GenAI auto-instrumentation.
  </Card>

  <Card title="Node.js" href="/opentelemetry/nodejs">
    Instrument a Node.js service that calls the Bedrock APIs.
  </Card>

  <Card title="Java / Go / .NET" href="/opentelemetry/overview">
    All OTLP-capable runtimes export to the same Collector.
  </Card>
</CardGroup>

## 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](/ai-features/aws-bedrock) under AI assisted observability.

## Alternatives

* [**Self-managed OTel Collector**](./aws-custom-otel) — 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](/opentelemetry/python#direct-export-to-bronto) on any language page.

See [Ingesting AWS Data into Bronto](./aws-overview) for the full service-to-method mapping.

## References

* [Amazon Bedrock Converse API](https://docs.aws.amazon.com/bedrock/latest/userguide/conversation-inference.html)
* [AWS Distro for OpenTelemetry](https://aws-otel.github.io/)
* [OpenTelemetry GenAI semantic conventions](https://github.com/open-telemetry/semantic-conventions-genai/blob/main/docs/gen-ai/aws-bedrock.md)