Odigos replaces manual OpenTelemetry instrumentation and proprietary runtime agents like OverOps with eBPF-driven, zero-code tracing for Kubernetes.
Odigos is an observability control plane that provides distributed tracing and telemetry across cloud infrastructure without application source modifications. It pairs eBPF kernel instrumentation with native OpenTelemetry agents to detect and instrument microservices on the fly. Infrastructure teams orchestrate the entire telemetry lifecycle through declarative Kubernetes custom resources rather than maintaining per-service monitoring libraries.
OverOps relied on proprietary runtime agents injected into JVM and .NET startup flags to record in-memory variables during exceptions, requiring continuous maintenance of custom launch parameters across container images. Running that stack required specialized on-premises collector servers or routing diagnostic snapshots to a commercial platform. Odigos shifts operational overhead from application configuration to the Kubernetes control plane. An in-cluster operator and a node daemon named odiglet discover workloads, attach eBPF probes or inject standard OpenTelemetry agents dynamically, and manage auto-scaling collector gateways without modifying container manifests or build steps.
The trade-off centers on forensic depth versus architectural flexibility. OverOps delivered granular variable states at the exact line of failure, but locked teams into supported runtimes and closed tooling. Odigos outputs standard OTLP traces, metrics, and logs directly into backends such as Jaeger, Prometheus, Tempo, Datadog, or Sentry. Operations teams avoid maintaining bespoke agents for each language, but they must operate the OpenTelemetry collector layer and rely on external platforms for incident triage.
Source and Destination for GitOps workflows.odiglet DaemonSet requires hostPID, hostNetwork, and capabilities like CAP_SYS_ADMIN and CAP_BPF, which can trigger violations under restricted Pod Security Standards./var/odigos, which can cause startup failures if non-root container users encounter restrictive directory permissions.Odigos vs OverOps — which should DevOps teams choose? Choose OverOps if you need deep variable snapshots during JVM exceptions and accept proprietary agents; choose Odigos if you run polyglot workloads in Kubernetes and prefer vendor-neutral OpenTelemetry tracing without touching source code.
Does Odigos support compiled languages like Go? Yes. Odigos uses eBPF probes attached at the Linux kernel level to trace Go network calls and propagate context without code changes or recompilation.
Is Odigos free for commercial use? Yes. The core project is open source with no licensing fees or per-node agent charges for commercial deployments.
Odigos is an effective platform choice when operations teams need instant, cluster-wide distributed tracing across polyglot microservices without coordinating manual SDK upgrades across developer repositories. It is less suitable for legacy bare-metal deployments that require deep, in-memory crash dumps. With active maintenance reflected in recent releases and an Apache-2.0 license that permits internal customization and enterprise redistribution, Odigos provides a practical foundation for cloud-native telemetry management.
Go, gRPC and Protobuf done right, LLM agents in production, and the hard parts of shipping a first product.
Show that Odigos is listed as an open-source alternative. Paste into your README: