// the find
odigos-io/odigos
Distributed tracing without code changes. 🚀 Instantly monitor any application using OpenTelemetry and eBPF
Odigos instruments Kubernetes applications for distributed tracing without touching application code, using eBPF for compiled languages like Go and OpenTelemetry agents for JVM/Python/Node/.NET. It deploys as a Kubernetes operator, auto-discovers workloads, manages OTel collector scaling, and ships to ~30+ backends. Aimed at platform engineers who need observability coverage across polyglot services without coordinating with every dev team.
- eBPF-based Go instrumentation is genuinely hard to do and fills a real gap — most auto-instrumentation solutions skip Go entirely or require build-time changes.
- The Kubernetes operator model is well thought out: custom CRDs for Sources, Destinations, InstrumentationConfig, and Sampling make the whole thing declarative and GitOps-friendly.
- CI pipeline is mature — chaos tests, cross-cloud tests, nightly runs, vulnerability scanning, RBAC verification, and Helm lint all present, which is more than most OSS projects bother with.
- OTel collector autoscaling managed automatically means you're not hand-tuning DaemonSet resource limits when traffic spikes — practical win for small platform teams.
- Everything is still v1alpha1 CRDs, meaning the API surface can break between releases; the MIGRATION.md file existing at all confirms this has already happened and will keep happening.
- eBPF instrumentation requires a recent kernel (typically 5.4+) and specific kernel headers/BTF support — this silently breaks on older node images and the error messages from odiglet in that scenario are not beginner-friendly.
- The enterprise/community split is visible in the repo (chainguard workflows, separate agent versioning) but not clearly documented — it's not obvious which features require a paid license until you hit a wall, which erodes trust in the open-source offering.
- No VM/bare-metal story despite the README claiming it; the entire installation path assumes Kubernetes, so 'Virtual Machines' in the description is aspirational at best.