How to Deploy Odigos for Zero‑Code Observability on Kubernetes

Introduction

Odigos ( https://github.com/keyval-dev/odigos) is an open‑source observability control plane that lets enterprises create and maintain observability pipelines, providing tracing, metrics, and logs for applications without any code changes.

When applications run across dozens of nodes and hundreds of pods, gaining full visibility is difficult, making observability essential for performance and availability monitoring.

Effective observability tools must integrate with the languages, frameworks, and container platforms you use, but implementing, maintaining, and scaling them is an ongoing effort that often requires specialized skills in OpenTelemetry and eBPF.

Proprietary agents from large vendors lock data into vendor‑specific formats, whereas Odigos embraces open standards and reduces the complexity of combining multiple observability solutions.

Key Features of Odigos

Odigos automatically detects the programming language of each application in the cluster. For compiled languages like Go it uses eBPF; for JVM languages it leverages OpenTelemetry. It follows best practices such as persisting API keys in Kubernetes Secrets and using minimal collector images.

Overall, Odigos provides a fully automated, vendor‑agnostic solution that enables organizations of any size to adopt and extend their observability stack quickly.

Usage

Preparation

We will install the bank-of-athnos sample application ( https://github.com/keyval-dev/bank-of-athnos), a Google‑created banking demo that contains no instrumentation code, to demonstrate Odigos' automatic data collection.

First, create a Kubernetes cluster (e.g., using kind create cluster) and deploy the sample app:

kubectl apply -f https://raw.githubusercontent.com/keyval-dev/bank-of-athnos/main/release/kubernetes-manifests.yaml

Wait until all pods are running.

Install Odigos

Install Odigos using the Helm chart:

helm repo add odigos https://keyval-dev.github.io/odigos-charts/
helm install my-odigos odigos/odigos --namespace odigos-system --create-namespace

After the pods in the odigos-system namespace are ready, forward the UI port:

kubectl port-forward svc/odigos-ui 3000:3000 -n odigos-system

Open http://localhost:3000 in a browser to access the Odigos UI.

Detection Mode

Odigos offers two detection modes: Opt out (recommended): Detect all applications, with the ability to manually exclude specific ones. Opt in: Detect only manually selected applications.

We choose the Opt out mode.

Configuration

Configure Odigos to send data to your observability backend. In this example we use self‑hosted Tempo , Prometheus , and Loki services.

Add the following destinations:

Tempo

Name: tempo

URL: http://observability-tempo.observability

Prometheus

Name: prometheus

URL: http://observability-prometheus-server.observability

Loki

Name: loki

URL: http://observability-loki.observability

Wait a few seconds for Odigos to deploy collectors and detect target applications. Monitor progress with: kubectl get pods -w When all pods (especially transactionservice) are running, forward Grafana:

kubectl port-forward svc/observability-grafana -n observability 3100:80

Open http://localhost:3100, log in with user admin and retrieve the password via:

kubectl get secret -n observability observability-grafana -o jsonpath="{.data.admin-password}" | base64 --decode

Service Graph

In Grafana, navigate to the Explorer, select Tempo as the data source, choose the Service Graph panel, and run the query to view the microservice graph.

Metrics

Click a node (e.g., contacts) in the service graph and select Request rate to view the metric chart.

Additional metrics collected by Odigos can be queried from Prometheus; see the documentation at https://odigos.io/docs/telemetry-types/ for a full list.

Tracing

In the service graph, select the contacts node and choose the request histogram. Enable exemplars to link metrics with traces, then click Query With Tempo to view the trace details.

The trace shows the time spent in each request segment, and drilling into a segment reveals additional information such as database queries.

Logs

To investigate specific operations, click the file‑icon next to a node to view related logs.

Conclusion

We have demonstrated how easily an entirely open‑source stack can extract and transmit logs, traces, and metrics, generate them within minutes, and correlate the three signals. This provides the data needed to quickly detect and fix production issues in target applications.