> ## 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, and send them to Bronto 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)