Start free. Scale to production.
Run Odigos open source yourself, or start a 14-day enterprise trial with full eBPF depth, multi-cluster, security, and support. No credit card.
Open source · Exports to OpenTelemetry, zero lock-in · No code changes
Pick the path that fits your stack.
The same zero-code capture underneath. Self-host the open source project, or get production-grade depth and support with Enterprise.
Enterprise
Production grade. 14 days free, no credit card.
Everything in each plan, line by line.
Open source covers core OpenTelemetry tracing. Enterprise adds low-overhead eBPF depth, database tracing, multi-cluster administration, and 24/7 support.
Low overhead eBPF capture
Database Extended Distributed Tracing
Frequently asked questions.
The short answers teams ask before they start. Reach out to sales if you need more depth.
It does not have to guess from 40,000. Odigos already maps every service, the calls between them and the functions on the path of a request, so the agent narrows the way a person would: the failing endpoint, then the slow span, then the functions inside it. Capture is the last step, on a handful of candidates, not a fishing expedition across the fleet.
Wherever you send it. Odigos runs inside your cluster and exports as OpenTelemetry to the destinations you configure, so captured data can stay entirely within your own infrastructure. Values are shaped before they leave: PII masking, attribute deletion and sampling all run in flight, in your cluster.
Capture is a governed action, not a developer convenience. RBAC controls who can request it and on which workloads, policy controls limit what may be captured at all, and every capture is scoped to the workload it was requested for. Teams handling card or patient data typically mask at the source and allow capture only on named services.
Yes. That is the point of the platform. An agent (or an engineer) can point at a function, a query, or a service that nobody ever set up to be watched, and Odigos attaches the capture live in running production. The answer comes back in seconds, as OpenTelemetry, with no code change and no redeploy.
It runs out of process in eBPF, under 1% CPU. It never loads into your application, so a bad release of ours cannot take your application down with it. What may be captured, and by whom, is governed by RBAC and policy controls, and every capture is scoped to the workload you point it at.
Odigos runs out-of-process eBPF and starts capturing from every service the moment it comes up. You get distributed traces, metrics, and logs with no code changes and no redeploys. It detects the language of each application and picks the right approach on its own.
Not on day one. Odigos runs alongside Datadog, New Relic, Honeycomb, Grafana Cloud, and the open source stack (Jaeger, Tempo, Loki, SigNoz). It captures what they cannot reach. Most teams start there. Many end up replacing them.
Go, Java, Python, .NET, JavaScript, PHP, and Ruby, with more landing constantly, including the compiled runtimes most tools cannot trace.
No. eBPF runs in the kernel, outside your process. CPU impact stays under 1% and added latency is effectively zero, even at high throughput.
Start free today. Move to production when you are ready.
Our own eBPF · Exports to OpenTelemetry, zero lock-in · No code changes