Skip to main content
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: 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:

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

​
Instrumenting workloads

Odigos only instruments workloads you mark as sources:
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 and the Metric Explorer. 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: To confirm the exporter was generated, inspect the gateway collector’s configuration:
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.

​
Further reading