> ## 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.

# Connect Odigos to Bronto

> Configure Odigos to auto-instrument Kubernetes workloads with eBPF and forward their traces, metrics, and logs to Bronto over OTLP.

Odigos auto-instruments Kubernetes workloads with eBPF and forwards their traces, metrics, and logs to Bronto via OTLP/HTTP. Unlike the other agents on this page, it also **generates** the telemetry: your applications need no SDK, no code changes, and no rebuilt images. This page covers Odigos destination configuration only.

For installation instructions, see the [Odigos installation guide](https://docs.odigos.io/setup/installation).

## Endpoint and authentication

Use the endpoints for your Bronto region:

| Region | Logs endpoint                            | Metrics endpoint                            | Traces endpoint                            |
| ------ | ---------------------------------------- | ------------------------------------------- | ------------------------------------------ |
| EU     | `https://ingestion.eu.bronto.io/v1/logs` | `https://ingestion.eu.bronto.io/v1/metrics` | `https://ingestion.eu.bronto.io/v1/traces` |
| US     | `https://ingestion.us.bronto.io/v1/logs` | `https://ingestion.us.bronto.io/v1/metrics` | `https://ingestion.us.bronto.io/v1/traces` |

Bronto authenticates with a header rather than basic auth or a bearer token, so the API key goes in the destination's `OTLP_HTTP_HEADERS` field:

| Header                | Required | Description                                                               |
| --------------------- | -------- | ------------------------------------------------------------------------- |
| `x-bronto-api-key`    | Required | Your [Bronto API key](/Account-Management/API-Keys#create-a-new-api-key). |
| `x-bronto-dataset`    | Optional | Overrides `service.name` as the dataset.                                  |
| `x-bronto-collection` | Optional | Overrides `service.namespace` as the collection.                          |

## Minimal configuration

Create a `Destination` resource in the `odigos-system` namespace. `OTLP_HTTP_HEADERS` takes a JSON array of `{"key": ..., "value": ...}` objects.

```yaml bronto-destination.yaml theme={"dark"}
apiVersion: odigos.io/v1alpha1
kind: Destination
metadata:
  name: bronto
  namespace: odigos-system
spec:
  type: otlphttp
  destinationName: bronto
  signals:
    - TRACES
    - METRICS
    - LOGS
  data:
    OTLP_HTTP_ENDPOINT: "https://ingestion.<REGION>.bronto.io"
    OTLP_HTTP_TRACES_ENDPOINT: "https://ingestion.<REGION>.bronto.io/v1/traces"
    OTLP_HTTP_METRICS_ENDPOINT: "https://ingestion.<REGION>.bronto.io/v1/metrics"
    OTLP_HTTP_LOGS_ENDPOINT: "https://ingestion.<REGION>.bronto.io/v1/logs"
    OTLP_HTTP_COMPRESSION: "gzip"
    OTLP_HTTP_TLS_ENABLED: "true"
    OTLP_HTTP_HEADERS: '[{"key":"x-bronto-api-key","value":"<YOUR_API_KEY>"}]'
```

```bash theme={"dark"}
kubectl apply -f bronto-destination.yaml
```

The same destination can be added through the Odigos UI (`odigos ui`) by selecting **OTLP http** and entering the endpoints and header.

<Warning>
  Odigos does not treat custom headers as secret, so the API key is stored in plain text in the `Destination` resource rather than in a Kubernetes `Secret`. Restrict RBAC on the `odigos-system` namespace, and avoid committing the manifest to source control.
</Warning>

## Send only the signals you need

`spec.signals` controls which pipelines Odigos builds. Remove any of `TRACES`, `METRICS`, or `LOGS` to stop sending that signal; the corresponding endpoint field can be removed with it.

<Note>
  OTLP metrics ingestion is in public beta. Bronto supports sums, gauges, summaries, and explicit histograms. Sum and histogram metrics can be ingested as delta or cumulative, but delta is strongly recommended to get the best value from the current set of supported functions. Exponential histograms are not supported, and the Metric Explorer does not currently provide a Rate function.
</Note>

## Instrumenting workloads

Odigos only instruments workloads you mark as sources:

```bash theme={"dark"}
odigos sources create <NAME>-src \
  --workload-kind=Deployment \
  --workload-name=<NAME> \
  --workload-namespace=<NAMESPACE> \
  -n <NAMESPACE>
```

Odigos rolls the affected pods once to attach instrumentation. Confirm agents are attached with `kubectl -n <NAMESPACE> get instrumentationinstances`.

Odigos derives `service.name` from the workload name, which becomes the Bronto dataset. Traces are stored in the `.traces` collection, one dataset per service. Every span is enriched with Kubernetes context — `k8s.deployment.name`, `k8s.namespace.name`, `k8s.pod.name`, `k8s.node.name`, and `k8s.container.name` — so you can scope queries to a workload, namespace, or node.

## Verify delivery

Once the destination is applied and your sources are instrumented:

* Traces appear in [Explore Traces](/tracing/explore-traces).
* Metrics appear in the Metric Explorer.
* Logs appear in [Search](https://app.bronto.io/search).

To confirm the exporter was generated, inspect the gateway collector's configuration:

```bash theme={"dark"}
kubectl -n odigos-system get cm odigos-gateway \
  -o jsonpath='{.data.collector-conf}' | grep -A6 bronto
```

Export failures are logged by the gateway. A `401` means the API key or the region is wrong — a region mismatch returns the same status as an invalid key.

```bash theme={"dark"}
kubectl -n odigos-system logs -l odigos.io/collector-role=CLUSTER_GATEWAY --tail=200 | grep -i "error\|failed"
```

## Further reading

* [Odigos documentation](https://docs.odigos.io) — sources, actions, and destination reference
* [Zero-code instrumentation with eBPF](/opentelemetry/ebpf) — instrument without adopting a platform
* [Connect OpenTelemetry Collector to Bronto](/agent-setup/open-telemetry) — if you already run your own Collector
* [Send Traces to Bronto](/tracing/send-traces) — including direct SDK export
* [Send Metrics to Bronto](/metrics/send-metrics) — supported metric types and public-beta limitations