Odigos is an Apache-2.0 open-source distributed tracing solution for Kubernetes environments and virtual machines that generates OpenTelemetry traces for Java, Python, .NET, Node.js, and Go applications without any code changes, built for platform engineers, DevOps professionals, and SREs.

What it is

Odigos is a Go-based, Apache-2.0 licensed observability project in the Infrastructure and Operations / Monitoring and Observability category. It instruments running applications and emits distributed traces in the OpenTelemetry format, using eBPF to do so without asking developers to edit source code or redeploy instrumented builds. It works across Kubernetes clusters and virtual machines, supports workloads written in Java, Python, .NET, Node.js, and Go, and sits between the applications it instruments and whatever observability backend the operator already uses. It is maintained by multiple maintainers of OpenTelemetry, and its topics span ebpf, kubernetes, opentelemetry, logs, metrics, monitoring, and observability.

The concrete problem it solves is manual instrumentation of applications that were never built for tracing. Historically, compiled languages such as Go have been difficult to instrument without code changes, and multi-language fleets make consistent tracing expensive to set up by hand. Odigos replaces that manual work with an install-time and runtime pipeline: it detects applications, applies instrumentation, separates data recording from data processing to limit runtime impact, and manages the OpenTelemetry collectors that ship the resulting data onward. It also replaces hand-tuned collector configuration by scaling collectors automatically based on observability data volume and by supplying opinionated defaults for common setups.

Key capabilities

• Code-free instrumentation that sets up distributed tracing in minutes with no manual code modifications.
• Multi-language support for Java, Python, .NET, Node.js, and Go applications.
• eBPF-powered instrumentation, the mechanism that makes compiled languages such as Go tractable without code changes.
• OpenTelemetry compatibility, producing data in the OpenTelemetry format so any OTLP-capable backend can receive it.
• Vendor-agnostic destinations, covering popular managed and open-source monitoring solutions to avoid vendor lock-in.
• Automatic scaling of OpenTelemetry collectors in response to observability data volume.
• Opinionated defaults that supply common best practices out of the box, so deep OpenTelemetry knowledge is not required.
• Collector management through a web UI, including application selection and destination selection screens.

Who uses it and how

• Platform engineers, DevOps professionals, and SREs who own observability strategy and need results quickly.
• Teams running Kubernetes clusters with polyglot application fleets that must all emit consistent traces.
• Teams running virtual machine workloads as well as containerized ones.
• Organizations that already have an OTLP-capable observability backend and want to keep it rather than migrate.
• Teams without deep OpenTelemetry expertise, who rely on the opinionated defaults and web UI instead of hand-written collector configuration.

Getting started

Download the Odigos CLI and run odigos install; the README states installation takes less than five minutes and requires no code changes. A quickstart guide and setup installation documentation are linked from the project.

How it compares

Odigos aligns with the OpenTelemetry ecosystem rather than competing with it, and it is built by multiple OpenTelemetry maintainers. Its aim is to produce standard OpenTelemetry data that any OTLP-capable tool can consume, so the choice of backend stays with the operator. The facts provided do not name any comparable alternative tool in this registry, so on the evidence given it stands alone here.

When to use it — and when not to

Choose Odigos when the environment is Kubernetes or virtual machines, when applications must be traced without code changes, and when an OTLP-capable backend is already in place. Do not choose it if there is no cluster or VM footprint to instrument, since the entire mechanism depends on running workloads it can attach to. The README is also thin on operational specifics beyond collector management: it does not describe persistent storage, database, or notification requirements, and the repository carries 158 open issues, so teams should expect to consult the linked documentation and the Slack community before committing.

odigos install