Odigos: OpenTelemetry tracing for Kubernetes without code changes

The problem Odigos targets: instrumenting services you cannot edit

Distributed tracing usually starts with a code change. You add an SDK, initialize a tracer provider, propagate context across HTTP and messaging boundaries, and repeat that work in every service. On a Kubernetes cluster with dozens of services in five languages, that is weeks of pull requests, and it is the reason many teams have logs and metrics but no traces.

Odigos is built for that gap. The README describes it as an open-source distributed tracing solution for Kubernetes environments and Virtual Machines that provides instant tracing without code changes. The intended users are named directly: platform engineers, DevOps professionals and SREs. This is a tool for the person who owns the cluster, not for the application developer who owns a single service.

The language list matters here. Java, Python, .NET and Node.js have long had auto-instrumentation agents that hook a runtime. Go does not, which is why the README singles it out: historically, compiled languages like Go have been difficult to instrument without code changes, and Odigos addresses that with eBPF. If your fleet is Go-heavy, that is the specific reason to read further. If it is Java-only, you likely already have options that do not require a new cluster component.

How Odigos works: eBPF instrumentation plus managed OpenTelemetry collectors

The repository layout shows the architecture more clearly than the README does. There is an operator/ directory, an odiglet/ directory, a collector/ directory, an autoscaler/, a scheduler/, a frontend/, and a set of shared Go modules (api, common, k8sutils, distros, destinations, instrumentation, instrumentationrules).

The control plane is a Kubernetes operator. It watches workloads and decides which ones to instrument, using the instrumentation and instrumentationrules modules. The odiglet is the node-level component that does the actual work: the README says Odigos uses eBPF for instrumentation, and eBPF programs attach at the kernel level per node, which is why a node agent is needed rather than a sidecar per pod.

Once instrumented, applications emit data in OpenTelemetry format. The collector/ and autoscaler/ components receive that data and forward it to a destination. The README describes automatic scaling of OpenTelemetry collectors based on observability data volume, and the Makefile's CENTRAL_BACKEND_URL variable hints at a central backend configuration path for managed setups. The destinations module and the backends-overview documentation page cover where data can go.

The design choice worth noting is the separation the README calls out under performance: data recording and processing are kept apart to minimize runtime impact. That is a real architectural constraint, not marketing. It means the node-level instrumentation path stays thin and the heavier processing (batching, sampling, routing) happens in collectors that can be scaled independently. The cost is more moving parts in the cluster.

Installing Odigos and instrumenting a first application

The README gives a short installation path. You download the CLI from the setup/installation documentation page, then run one command. The README states installation takes less than five minutes and requires no code changes, and that the CLI is published through a release workflow (the release.yml badge) with Go module paths under cli/.

After installing the CLI, the install command deploys the Odigos components into the cluster. The Makefile sets ODIGOS_NS ?= odigos-system, which is the namespace the tooling expects by default.

odigos install

What you should see is the Odigos control plane running in the odigos-system namespace. The README does not document the full set of resources created, so check the namespace yourself before moving on.

The next step is choosing which applications to instrument and which backend receives the data. The README shows this as a web UI with two selection screens: one for applications (ui_choose_apps.png) and one for destinations (ui_choose_dest.png). The frontend/ directory in the repository is that UI. Applications are selected from the workloads Odigos can see; destinations are chosen from the supported list.

Collector behaviour is managed from the same UI. The README describes a collectors management screen (ui_overview.png) where collectors are configured and scaled. If you prefer a declarative route, the repository contains a helm/ directory, and the Makefile references helm search repo odigos, which indicates a Helm chart is published. The README itself does not document chart values, so treat the chart as something to inspect rather than something described here.

One detail that matters for Go users: the README claims Odigos supports any application written in Java, Python, .NET, Node.js and Go, and the eBPF path is what makes the Go case work. The language-specific behaviour is documented per language under docs.odigos.io/instrumentations/, not in the README.

Where Odigos gets in the way: rollback, scope and unsupported cases

The most concrete limitation is documentation, not capability. The README does not document rollback. There is no described procedure for removing instrumentation from a workload, no statement about what happens to in-flight traces when the odiglet is removed from a node, and no guidance on whether uninstrumenting restores the previous runtime behaviour exactly. For a component that attaches eBPF programs at the kernel level, that silence is the thing to resolve before a production rollout, not after.

The second constraint is scope. Odigos targets Kubernetes and Virtual Machines. If you run serverless functions, managed container platforms where you cannot install node-level agents, or a single VM without Kubernetes, the README's framing does not cover your case. The repository contains a deviceplugin/ directory, which suggests the node-level model is central rather than optional.

The third is the operating surface. Odigos adds an operator, a node agent, a collector fleet, an autoscaler, a scheduler and a UI to your cluster. The README's own framing of performance (separating recording from processing) is a design that trades cluster resources for application overhead. That is usually the right trade for platform teams, but it is a trade. On a small cluster with a handful of services, you are adding a control plane to avoid editing five files.

Finally, the eBPF approach depends on kernel capabilities and node permissions. The README does not enumerate kernel version requirements or the privileges the odiglet needs. That information exists in the docs site rather than the repository front page, and it should be checked against your node images before you commit.

Odigos compared with manual OpenTelemetry SDK instrumentation

The real alternative is not another tracing vendor. It is doing what Odigos automates: adding the OpenTelemetry SDK to each service yourself, configuring an exporter, and running your own collector deployment.

The difference in approach is where the work lives. With manual SDK instrumentation, the instrumentation is part of the application artifact. It is versioned with the service, it is testable in unit tests, it survives cluster changes, and removing it is a code change you can review and revert. It also works anywhere the application runs, including outside Kubernetes. The cost is per-service effort and per-language knowledge, and the Go case in particular requires real work because there is no runtime agent to hook.

Odigos moves that work into the cluster. Instrumentation becomes a property of the deployment rather than the artifact, which is why the README can promise no code changes. The benefit is coverage: every selected workload gets traces without a pull request, and adding a new service is a UI action. The cost is that the instrumentation is now invisible to the application's own build and test pipeline, and its correctness depends on the odiglet running correctly on every node.

A second alternative is a vendor agent that bundles collection and a proprietary backend. Odigos deliberately does not do that: it emits OpenTelemetry and the README lists vendor agnosticism and OTLP compatibility as features, with a documented list of supported destinations. If you have already standardized on an OTLP-speaking backend, Odigos fits underneath it. If you want a single vendor to own agent, pipeline and UI, Odigos is one layer more than you asked for.

Licence, maintenance and the cost of upgrading

Odigos is licensed under Apache-2.0, and the README points to the LICENSE file for full terms. For most adopters this is the permissive case: you can run it, modify it and ship it inside a commercial product. The repository contains a MIGRATION.md and a VERSIONING.md, which indicates the project has thought about upgrade paths between versions, though the README does not summarize either. If you deploy Odigos as part of a product you distribute, read those two files plus LICENSE rather than relying on the licence identifier alone. That is a documentation task, not legal advice.

On maintenance, the observable facts are the release cadence and the last push date. The most recent release listed is v1.38.0-pre4 on 2026-09-23, with v1.38.0-pre3 the day before and v1.37.1 on 2026-09-18. The last push to the default branch was on 2026-09-23. Pre-release tags appearing alongside stable ones is normal for a project that ships continuously, but it does mean you should pin to a stable tag such as v1.37.1 rather than tracking main.

Upgrade cost is where the architecture matters. The CLI has its own version (odigos version --cli appears in the Makefile) and the cluster has its own (odigos version --cluster). The Makefile resolves TAG by trying the cluster version first, then the CLI version. That ordering tells you the CLI and the in-cluster components are versioned together and are expected to match. Upgrading is therefore a cluster-wide operation: the operator, the odiglet on every node, the collectors and the UI move as a unit. On a large cluster that is a rolling change to a node-level agent, which is a heavier maintenance event than bumping a library version in one service.

Editorial conclusion

Adopt Odigos if you run Kubernetes workloads in the supported languages and need OpenTelemetry traces from services you cannot or will not edit, and if you accept running its operator, collectors and UI in the cluster. Do not adopt it if you need a documented rollback path or a non-Kubernetes deployment today, since the README documents neither. Verify first that your language runtime appears in the instrumentation docs, that your chosen backend accepts OTLP, and that the collector autoscaler behaves under your traffic shape.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. odigos-io/odigos on GitHub
3. Project website
4. README
5. Releases