Connect Odigos to Bronto

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.

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

bronto-destination.yaml

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>"}]'

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.

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.

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.

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.

Instrumenting workloads

Odigos only instruments workloads you mark as sources:

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.
Metrics appear in the Metric Explorer.
Logs appear in Search.

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

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.

kubectl -n odigos-system logs -l odigos.io/collector-role=CLUSTER_GATEWAY --tail=200 | grep -i "error\|failed"

Overview

Ingest with agents

Ingest from AWS

Ingest from Azure

Ingest from CDN and edge

Ingest from apps and platforms

Ingest from infrastructure and databases

Ingest OpenTelemetry data

Connect Odigos to Bronto

Endpoint and authentication

Minimal configuration

Send only the signals you need

Instrumenting workloads

Verify delivery

Further reading

​Endpoint and authentication

​Minimal configuration

​Send only the signals you need

​Instrumenting workloads

​Verify delivery

​Further reading

Endpoint and authentication

Minimal configuration

Send only the signals you need

Instrumenting workloads

Verify delivery

Further reading