> ## 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 | Scope | Description |
| - | - | - | - |
| `x-bronto-api-key` | Required | All signals | Your [Bronto API key](/Account-Management/API-Keys#create-a-new-api-key). |
| `x-bronto-dataset` | Optional | Logs only | Overrides `service.name` as the log dataset. |
| `x-bronto-collection` | Optional | Logs only | Overrides `service.namespace` as the log 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>
  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. For Sum, Summary, and Histogram metrics, the Metric Explorer provides [per-second rate functions](/metrics/explore-metrics#aggregation-functions).
</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 and attaches it to every signal. For logs, this becomes the Bronto dataset name. Traces and metrics are not stored in datasets or collections; use `service.name` and the Kubernetes attributes as filters in [Explore Traces](/tracing/explore-traces) and the [Metric Explorer](/metrics/explore-metrics). Every span is enriched with `k8s.deployment.name`, `k8s.namespace.name`, `k8s.pod.name`, `k8s.node.name`, and `k8s.container.name`, so you can scope traces 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 limitations


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.