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:

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

Wait until all pods are running.

Install Odigos

Install Odigos using the Helm chart:

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

After the pods in the

odigos-system

namespace are ready, forward the UI port:

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

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:

<code>kubectl get pods -w</code>

When all pods (especially

transactionservice

) are running, forward Grafana:

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

Open

http://localhost:3100

, log in with user

admin

and retrieve the password via:

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

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.